Containers and the Cloud
Disclaimer: This article has been updated May 5th, 2026 from its original publication to reflect the current state of container adoption, including orchestration maturity, platform engineering practices, modern security requirements, and the growing complexity of AI workloads running inside containers.
Docker and other container services are appealing for a good reason: they are lightweight and flexible. For many organizations, they enable the next step of platform maturity by reducing the needs of a runtime to the bare essentials (at least, that’s the intent). When you dig into the benefits afforded by containers, it’s easy to see why so many companies have started projects to:
- Containerize their apps and supporting services
- Achieve isolation
- Reduce friction between environments
- Potentially improve deployment cycle times
The software development pattern of small things, loosely coupled, can go even further with an architecture built around containerization. However, I’ve discovered that there is no shortage of misunderstandings about Docker and other container technologies (no surprise given the pace of change) in terms of:
- How their benefits are realized
- The impact on infrastructure and operations
- The implications on overall SDLC and Ops processes
Containers certainly offer plenty of benefits, and it makes good sense to explore whether and how they could work for your organization. But it is also a good idea to take off the rose-colored glasses first and approach this technology realistically.
Why Containers, and Why Now?
Many organizations today are running large fleets of cloud instances to spin up new apps, services, databases, and otherwise grow their businesses. While it’s simple to scale, this often comes with various types of overhead:
- Replicated compute resources to run a host OS
- Tons of processes that aren’t relevant to your app
- More instances to manage
This can lead to sprawl, inconsistencies in core images, and process and budgetary challenges. Finance wants to understand how Ops teams are modeling growth and spend, security teams are trying to maintain visibility and control, and engineering wants the flexibility to deploy new components quickly. At the same time, the business needs to grow.
So a key question becomes: How can we optimize our processes, optimize our cloud environment, and still move quickly?
Containers, at least on the surface, appear to offer an answer. One common line of thinking is that teams can reduce the number of raw instances by increasing the size of individual nodes and running containers on top. For example, if you have 600 cloud instances that are 1 CPU and 4 to 5 GB of RAM each, maybe you’re thinking you could consolidate those down to 100 instances with 32 CPUs and 64 GB of RAM and significantly reduce overall cost.
Well, it’s not that simple.
What to Consider Before Moving to Containers
In the short term, that kind of consolidation may work for some use cases. But in the long term, as with many technology choices, you’re trading one set of complexities for another.
A New Tech Stack
As soon as you start running containers at scale, you need to invest in orchestration, scheduling, and resource management. This introduces an entire layer of platform complexity. While best practices are far more established today than they once were, applying them consistently across teams and environments remains a challenge. Getting this right requires iteration, and organizational buy-in that the platform itself is now a product that needs to be designed and maintained.
Management Obstacles
Obstacles with containers include:
- How to manage them
- How to maintain visibility into them
- How to know when containers are an appropriate solution (and when they aren’t)
As far as that third point, I continue to see a lot of “container rationalization.” Teams adopt containers because they can, and define the use cases later. This isn’t inherently wrong, but when it comes to availability, security, and cost-efficiency, it’s far better to establish clear goals and constraints upfront.
Security Considerations
While it may make sense on the surface to move workloads to containers, the devil is in the details. You need visibility into what is running, when, and from where. The security landscape has also evolved, with supply chain risks bringing image provenance and software bill of materials (SBOM) requirements into sharper focus.
As you scale, you’ll want to understand how to control the images you’re using, how they’re built, and what level of access processes should have. Questions like these should be answered early:
- Should a developer ever be allowed to log into a running container in production?
- Are we going fully immutable across all containers?
- How will we manage image size and lifecycle to avoid sprawl?
- Do we have a clear policy around image signing and verified provenance?
Clear answers here go a long way toward keeping implementations predictable and secure.
The Platform Engineering Factor
One thing that has changed considerably is the maturity of the ecosystem around containers. Kubernetes and a rich set of tooling have brought structure to what was once a largely improvised practice. But tooling maturity does not equal organizational maturity.
Teams that are successful with containers have typically invested in platform engineering as a discipline, not just a set of tools. That means dedicated ownership of an internal developer platform, clear contracts between platform and application teams, and well-defined golden paths that make the right way to deploy also the easiest way. Without that structure, the tooling often becomes just another layer of complexity.
Tooling maturity does not equal organizational maturity. The teams getting containers right have invested in platform engineering as a discipline, not just a set of tools.
Be Honest About the Challenges
Organizations continue to encounter difficult questions such as:
- What instance types and resource profiles actually fit our workloads?
- How do we adapt as workload characteristics evolve over time?
- How should we approach scaling without introducing unnecessary risk or cost?
- How do we reduce surface area without creating single points of failure?
- How do we secure not just containers, but the systems they interact with?
A newer consideration is the rise of AI and machine learning workloads running inside containers. These workloads often break traditional assumptions around sizing and scheduling. A container built around a CPU-bound service behaves very differently from one built around GPU-bound inference, and treating them the same can lead to wasted spend and unpredictable performance. Organizations moving in this direction need to account for GPU scheduling, isolation, and cost attribution early.
Having a powerful engine doesn’t get you far if you don’t have the rest of the car built to support it.
The Future Is (Still) Bright
Containers are now a foundational part of modern cloud infrastructure. But like any foundational technology, they don’t simplify things by default: they shift where the complexity lives.
Approached thoughtfully, they can enable faster delivery, better consistency, and more efficient use of resources. Approached casually, they can just as easily introduce a new class of operational challenges.
The difference comes down to how deliberately they’re adopted.
By Chris Gervais