# Your Monolith Is Split. Here Are the 3 Ways Containerization Still Goes Wrong

> **TL;DR:** "Split your monolith before you containerize" is well-trodden advice by now, and teams that follow it still run into trouble, just further down the line. Three pitfalls catch properly-decomposed systems specifically: running containers without an orchestrator (manual scaling and restarts don't hold), shipping unscanned base images straight to production, and storing state inside the container itself, which vanishes on restart. None of these are splitting mistakes. All three are common even in systems that got the architecture right.

Plenty of containerization advice stops at "decompose your services, then containerize them," as if that's the finish line. It's the prerequisite, not the finish line. A properly-split system containerized without attention to orchestration, image hygiene, or state management will still fail in production, just for different reasons than a wrapped monolith would.

## Pitfall 1: containers without an orchestrator

A handful of containers can be run and restarted by hand. That stops working somewhere around a dozen, and definitely stops working once a service needs to scale with traffic or recover from a node failure automatically. Without an orchestrator, every scaling decision and every restart after a crash is a person watching a dashboard and running a command, which doesn't hold up at 2am during an incident. Kubernetes (or a managed equivalent) is what turns "the container should restart if it dies" and "this service should scale with load" from manual operations into system behavior. Teams that split correctly but skip orchestration end up with containers that are architecturally capable of independent scaling and self-healing, and operationally still running like a fixed fleet, because nothing is actually driving those capabilities.

## Pitfall 2: image security as an afterthought

A container image built from an untrusted or outdated base carries whatever vulnerabilities that base has, straight into production, and it does this silently, a vulnerable image builds and runs exactly like a clean one until something exploits the gap. The fix has two parts: build from minimal, trusted base images rather than full-fat ones with unnecessary packages, and scan every image in the CI/CD pipeline before it ships, not as a manual, occasional audit. Because images get rebuilt on every deploy, a scanning step that runs once a quarter is checking a snapshot that's already stale by the time anyone reads the report.

## Pitfall 3: treating a container like it has memory

Containers are designed to be disposable, restarted, replaced, scaled down and back up, without anyone caring which specific instance survived. Data stored inside a container's own filesystem doesn't survive that disposability, it's gone the moment the container restarts or gets rescheduled to a different node. Teams used to VM-era thinking (where a server persisted and its disk persisted with it) sometimes carry that assumption into containers, and discover the gap exactly when an unrelated restart wipes something they assumed was safe. The fix is structural, not a configuration tweak: state lives in managed databases, object storage, or explicitly mounted persistent volumes, never in the container's own ephemeral filesystem.

## Why these three specifically catch well-architected systems

| Pitfall | What makes it sneaky |
| --- | --- |
| No orchestration | Everything looks fine at low container counts; breaks exactly when scale makes manual ops impossible |
| Unscanned images | A vulnerable image behaves identically to a clean one, until it's exploited |
| Stateful containers | Works fine until the first unrelated restart, which can be weeks or months later |

None of these three announce themselves early. A team can run correctly-split, correctly-containerized services for months before hitting any of them, which is exactly why "we already did the hard part (splitting)" is a dangerous place to stop paying attention.

## FAQ

**If we're already running Kubernetes, are we automatically safe from pitfall 1?**

Running Kubernetes isn't the same as using it correctly, under-configured resource limits, missing readiness/liveness probes, or no horizontal pod autoscaler set up mean the orchestrator is present but not actually doing the scaling and healing work it's capable of.

**How often should image scanning actually run?**

On every build, as a required CI/CD gate, not a periodic audit. The cost of scanning on every build is low; the cost of a vulnerable image reaching production between quarterly audits is not.

**Is it ever acceptable to store data in a container?**

For genuinely ephemeral, disposable data (a cache that's fine to lose, temp files for a single request's processing), yes. For anything the business would miss if it disappeared, no, that belongs in a managed store from the start.

---

*This is a condensed take on* [*the full write-up*](https://sherdilcloud.com/containerization-done-right-docker-kubernetes-and-cloud-synergy/) *(with the complete five-benefit breakdown and the food-delivery case study). For the orchestration layer in depth, see* [*Kubernetes for beginners*](https://sherdilcloud.com/kubernetes-for-beginners-guide/)*; for the pipeline that should include image scanning,* [*CI/CD from scratch*](https://sherdilcloud.com/build-cicd-pipeline-from-scratch/)*.*

**About the author:** Muhammad Usman is Head of DevOps at Sherdil Cloud, AWS DevOps Engineer Professional, Certified Kubernetes Administrator (CKA), and Alibaba Cloud Certified, building cloud and DevOps infrastructure for enterprises across Pakistan, the UAE, and the United States since 2014.