Why do teams building a microservices system typically package each service as a container image rather than installing it directly onto a shared virtual machine?

## What a container image is A container image is a packaged, immutable filesystem snapshot containing a service's compiled code or interpreter, its language runtime, its library dependencies, and the configuration needed to start it — everything the process needs except the host's kernel, which containers share with the host operating system. When that image runs, the container engine gives the process its own isolated view of the filesystem, process tree, and (usually) network interface, using kernel features like `namespaces` and `cgroups`, without booting a separate operating system the way a virtual machine does. That isolation-without-a-full-OS is the core mechanism: - a container **starts in milliseconds to a few seconds**; - it consumes only the **memory/CPU its process actually needs** (bounded by resource limits); - it can be packed **many-to-a-host far more densely than virtual machines**, which each carry the weight of a full guest kernel and OS. ## Why microservices need it This mechanism exists because microservices architecture deliberately splits one application into many independently-buildable, independently-deployable, independently-scalable services, and that independence breaks down the moment those services must share a single machine's installed runtime and libraries. If ten services run directly on one VM, they're forced to agree on one version of Node, one version of OpenSSL, one set of system libraries — any service that needs to upgrade a dependency risks breaking a sibling service on the same host, which recreates the exact deployment coupling microservices are meant to eliminate. Packaging each service as its own container image solves this: - each image **carries its own dependency graph**; - each is **versioned and pushed to a registry as an immutable artifact**; - each can be **built, tested, and released on its own schedule** without touching any other service's image. The same image that passed CI is the exact image that runs in production, which also closes most of the 'works on my machine' gap that plagued deployments built from source on a target host. ## The trade-off The trade-off is that containers trade some isolation strength for that density and speed. Because containers share the host kernel, a kernel-level vulnerability or a container escape can, in principle, affect other containers on the same host — a boundary a hypervisor-backed VM enforces more strongly. Teams accept this because, for isolating dozens of trusted, internally-built services from each other (as opposed to isolating fully untrusted multi-tenant workloads), the practical risk is low and the operational cost of VM-per-service would be prohibitive at microservice scale — running one full VM per service multiplies infrastructure cost and slows every deploy and scale-out operation. The other cost is **process overhead**: building, scanning, versioning, and storing an image per service per release adds real CI/CD and registry infrastructure that a single monolithic deployable never needed, and every one of those images now needs its own vulnerability scanning and patching cadence. ## Failure modes In production, containerization introduces its own class of failure modes distinct from 'the code has a bug.' 1. **Image bloat** — accumulating unnecessary build tools, package caches, or debug libraries inside the image — increases startup latency and attack surface; teams counter this with minimal or distroless base images. 2. **Base-image drift** is a quieter failure mode: dozens of services each pin their own base image version, and a critical CVE patched in a newer base image doesn't automatically propagate to services that haven't rebuilt, so a fleet of 'independently deployed' services can silently carry the same unpatched vulnerability for months unless base-image updates are tracked centrally. 3. **Container startup assumptions** matter: a service that takes thirty seconds to warm a cache or JIT-compile can cause failed health checks and restart loops if the orchestrator's readiness timing wasn't tuned for that service's actual startup profile, again multiplied across however many services were containerized without individual tuning. ## Where it shows up A concrete, widely-cited real-world instance of this shift is Netflix's move from deploying services as fat, VM-baked artifacts (via tools building whole Amazon Machine Images per service release) toward containerizing services with Titus, its container management platform built on top of the same underlying cloud infrastructure — driven precisely by wanting per-service build/release speed and density without paying the VM-image-bake cost for every single microservice deploy. The general pattern — many small teams, many services, needing independent, fast, reproducible releases — is exactly the scenario containerization was built to serve, which is why it became the default packaging unit for microservices architectures industry-wide rather than a niche optimization.