September 4, 2026 Stories worth reading. Perspectives worth sharing.
From Virtual Machines to Microservices: Understanding Containers in Modern Software Infrastructure
Containers

From Virtual Machines to Microservices: Understanding Containers in Modern Software Infrastructure

Alex Carter
Alex Carter September 4, 2026 11 min read

I still remember provisioning my first production virtual machine before containers completely changed how we build and deploy software. It was a Friday afternoon, and the change request had been sitting in a queue for two weeks. Spinning up the actual server took less time than the paperwork that got me there. That was the world most of us worked in for the better part of two decades: heavy, general-purpose machines running one guest operating system each, babysat by a small army of infrastructure engineers who knew every quirk of every box by name.

The widespread adoption of containers changed that world, and it didn’t do it quietly. Anyone working in cloud computing today is dealing with the aftermath, whether they call it that or not. This piece walks through what actually shifted, from the virtual machine era to where we are now, why containerization became the foundation of scalable platforms, and what I’ve learned advising teams through that transition over nearly a decade in this field.

Where We Started: The Virtual Machine Era

Virtual machines solved a real problem. Before hypervisors became mainstream, a single physical server typically ran a single application. That server sat idle a good portion of the time. Virtualization let one physical box pretend to be several. Each got its own full operating system, its own kernel, its own memory allocation, walled off from its neighbors. For a long stretch of enterprise computing history, this was the best answer we had to server sprawl and underused hardware.

The catch was weight. Every virtual machine carries a complete operating system with it. That means gigabytes of disk space and minutes of boot time. It also means a meaningful chunk of the host’s memory and CPU spent just keeping that guest OS alive, before your actual application does anything useful. Scaling out meant cloning entire machines. Patching meant patching every one of those operating systems separately. It worked, but it was expensive in a way that became harder to justify as applications grew more distributed and release cycles sped up.

What Actually Changed When Containers Arrived

A container takes a different approach. Instead of virtualizing an entire computer, it virtualizes the operating system itself. Every container running on a host shares that host’s kernel. Each one gets an isolated slice of processes, filesystem, and networking that behaves as if it were the only thing running. The application, its libraries, and its configuration travel together as a single package. The thing that ran correctly on an engineer’s laptop behaves the same way in staging and in production.

The practical difference shows up immediately. A container typically starts in a second or two, rather than minutes. Images measure in megabytes rather than gigabytes. A single host that once comfortably ran a handful of virtual machines can now run dozens of containers, with room to spare. None of this makes virtual machines obsolete. I’d push back on anyone who tells a client to rip out every VM tomorrow. Strong isolation still matters for certain regulated workloads. Plenty of legacy applications were never built with containerization in mind. But for the problem most teams actually have today, shipping application changes quickly and reliably, containers are the better tool for the job.

Containers and Microservices: A Natural Partnership

Containers didn’t invent microservices, but they made microservices practical at scale. Breaking a large application into smaller, independently deployable services sounds appealing on a whiteboard. It turns painful fast if every one of those services needs its own virtual machine, its own patch cycle, its own capacity planning exercise. Containers collapse that overhead. Each service gets packaged with exactly what it needs, nothing more. It can be deployed, scaled, or replaced without touching its neighbors.

This is where orchestration tools enter the picture. Kubernetes, and to a lesser extent a handful of alternatives, took on the job of scheduling containers across a cluster of machines. It restarts the ones that fail, and scales services up or down based on demand. I won’t pretend Kubernetes is simple. It has a genuine learning curve, and I’ve watched teams underestimate that curve badly. But once a team gets past the initial hump, something changes. The combination of containers for packaging and an orchestrator for management gives you infrastructure that responds to load automatically. It deploys in minutes instead of hours, and treats a failed instance as a routine event rather than a page at two in the morning.

What the Adoption Numbers Actually Show

Skeptics sometimes assume this is still a bleeding-edge approach, reserved for Silicon Valley engineering teams. The data says otherwise. Recent survey work from the organization that stewards Kubernetes found something striking. The overwhelming majority of organizations, north of ninety percent by most current measures, have adopted cloud native techniques in some form. A clear majority now run Kubernetes in production, rather than just experimenting with it. That’s a meaningful jump from where the same survey stood just a couple of years earlier.

It’s not just container orchestration for its own sake, either. A growing share of organizations running machine learning and generative AI workloads now do so on Kubernetes-managed container infrastructure. The logic is simple: the same scaling behavior that helps a web application handle a traffic spike helps an inference workload handle a burst of requests. Cloud computing and infrastructure teams that were slow to adopt containers for conventional applications are now adopting them for a new reason. Their AI initiatives demand it.

The Trade-offs Nobody Puts on the Slide

I’d be doing readers a disservice if I made this sound frictionless. Let me be direct about where containers get hard. Security is the first place teams stumble. Containers on a single host share a kernel. A poorly configured container can, in the worst case, expose more of the host than anyone intended. That’s manageable with proper image scanning, minimal base images, and sensible runtime restrictions. But it requires discipline that a lot of organizations don’t build in from day one.

The second friction point is cultural, not technical, and in my experience it’s the bigger one. Moving to containers and microservices usually means a real shift in how work gets divided. Teams move away from a small number of people who understand the whole system. They move toward many people who each understand one service deeply. That’s a genuine organizational change. Survey data consistently ranks cultural change, not tooling, as the top challenge teams report when adopting cloud native infrastructure. I’ve sat in enough postmortems to say this plainly: the technology rarely fails first. The team’s readiness to operate it does.

The third is plain complexity. A monolith deployed as a couple of virtual machines is conceptually simple, even when the code inside it is a mess. A microservices architecture running across dozens of containers introduces new problems. Networking between services, distributed tracing, and failure modes that didn’t exist before all show up at once. Teams that skip investing in observability tooling early tend to pay for it later. That usually happens during an incident, and usually at a bad time.

Portability and the Multi-Cloud Reality

One benefit of containers doesn’t get enough attention outside engineering circles: portability. A container packages an application with everything it needs to run. That package behaves the same way on a laptop, in an on-premises data center, or across several public cloud providers. That matters more than it used to. Very few organizations I work with these days run on a single cloud provider by choice. Most end up multi-cloud through acquisitions, regulatory requirements, or simple risk management. Containers give them a common unit of deployment, regardless of which cloud sits underneath.

This is also where the line between infrastructure and platform starts to blur. A team running containers on Kubernetes isn’t just choosing a deployment mechanism. It’s choosing a platform that most major cloud providers now support natively. That means the cost of moving a workload from one provider to another drops substantially, compared to the virtual machine era, when moving meant re-provisioning everything from scratch. That portability doesn’t eliminate cloud lock-in entirely; plenty of managed services still tie you to a specific vendor. But it narrows the blast radius considerably.

How I Actually Approach This With Clients

In my nine years advising infrastructure teams through this kind of transition, one pattern works far better than the rest. It’s rarely a big-bang rewrite. It’s identifying the handful of services where containerization pays off fastest, usually anything stateless, anything that scales unevenly with demand, anything that gets deployed often, and starting there. I’ve watched a client cut a deployment process that used to take the better part of a day down to a task their engineers barely think about. The reason was simple: the unit of change shrank from an entire application to one small, well-defined service.

A few habits separate the migrations that go well from the ones that don’t. Keep container images small, and rebuild them from a minimal, well-maintained base, rather than a general-purpose operating system image bloated with tools nobody uses. Treat infrastructure as code from the start, rather than retrofitting it once things sprawl. Build observability, logging, metrics, and tracing, into the platform early, before the number of services grows past what one engineer can reason about from memory. And resist the temptation to adopt every piece of the cloud native ecosystem at once. A service mesh, a dozen operators, and a fully automated GitOps pipeline are all genuinely useful tools. Stacking them all in month one is how teams end up managing more complexity than the containers themselves ever created.

Where This Is Heading

The direction of travel in cloud computing and infrastructure right now points toward platform engineering. Internal teams are building golden paths, so application developers can deploy containers without needing to understand every layer of Kubernetes underneath them. It also points toward tighter integration between containers and AI infrastructure. Training and inference workloads are increasingly packaged and scheduled the same way conventional applications are. None of this erases the virtual machine. It still has a place for workloads that genuinely need full isolation, or that simply haven’t been rebuilt yet. But the center of gravity in software infrastructure has clearly moved. It’s shifted from provisioning whole machines to packaging and orchestrating containers, and every signal I’m seeing from clients and from industry data says that shift is still accelerating.

There’s also a talent dimension to this shift that doesn’t get discussed enough. Engineers coming up in the industry now are far more likely to have learned containers first and virtual machines second, if they’ve touched VM management directly at all. That changes hiring. It changes onboarding. It changes how quickly a new engineer becomes productive on a team’s infrastructure. Organizations still running everything on traditional virtual machines are increasingly training new hires on a model those hires didn’t grow up with. That’s its own quiet cost, and it rarely shows up on a budget line.

If there’s one thing I’d want a team just starting this journey to take away, it’s this: containers are not primarily a performance optimization. They’re an operating model. Adopt the model, invest in the cultural and observability groundwork it requires, and the performance gains tend to follow on their own.

Frequently Asked Questions

What is the main difference between a virtual machine and a container?

A virtual machine virtualizes an entire computer, including a full guest operating system. A container virtualizes the operating system itself and shares the host’s kernel with other containers.

Do containers replace virtual machines completely?

No. Virtual machines still make sense for workloads that need strong isolation, run older operating systems, or haven’t been rebuilt for a containerized environment.

Why are containers considered a good fit for microservices?

Each service can be packaged, scaled, and deployed independently, without the overhead of a dedicated virtual machine per service.

What role does Kubernetes play in a container-based infrastructure?

Kubernetes schedules containers across a cluster, restarts failed instances, and scales services based on demand. It takes over much of the manual work that infrastructure teams used to handle by hand.

Is container adoption still growing, or has it plateaued?

It’s still growing, and growing quickly in areas like AI and machine learning infrastructure. The Cloud Native Computing Foundation’s latest survey data shows continued increases in production Kubernetes use year over year.

What’s the biggest challenge organizations face when adopting containers?

Based on current industry survey data, it’s cultural rather than technical. Teams need to adapt how they organize, deploy, and take ownership of smaller services. The IBM Think team has written about the broader hybrid cloud benefits and trade-offs.

References

Tags: