This article is based on analysis originally published on sdtimes.com in mid-2017. It is presented here as a useful historical reference point for understanding how container adoption evolved, with editorial context added for today’s DevOps audience.
Container Adoption: Early Days and Bold Predictions
In mid-2017, containers were still considered a relatively new tool in mainstream software development — yet they were already being deployed in demanding, real-world environments. Financial services firms used containers to power credit scoring and financial recommendation systems. Government agencies used them to model complex simulations. Healthcare companies used them to process and visualize radiology data at scale.
Container usage was clearly growing, but widespread questions remained: Would containers become the default deployment target for every application? How quickly would enterprises follow developer-level grassroots adoption? Three predictions from that period help frame how the industry’s thinking evolved.
Prediction 1: Cloud-Native Development Would Become the Norm
By 2017, developers were increasingly writing code in a “cloud-native” fashion — meaning applications designed around continuous integration (CI), continuous delivery (CD), microservices architectures, and containerization from the ground up, rather than being adapted from monolithic predecessors.
The prediction at the time was that more than 50% of new applications developed by the end of 2017 would be cloud-native. Whether that exact figure materialized is difficult to verify, but the directional trend was accurate. Today, cloud-native is a foundational expectation rather than a differentiator.
The core argument holds: containers allow organizations to accelerate development cycles while improving security posture and scalability. By separating application runtime from the underlying infrastructure, teams can ship faster, roll back safely, and scale individual components independently.
What This Means in Practice
- CI/CD pipelines become more reproducible when each stage runs in a defined container image.
- Microservices align naturally with containers — one service per container is a common pattern.
- Developer environments can be standardized using container definitions, reducing “works on my machine” issues.
Prediction 2: Containers Would Become the Default Deployment Choice
The analogy offered in 2017 was instructive: containers were at roughly the same inflection point that virtualization occupied around 2002, and where cloud computing sat around 2010. In both of those cases, early skepticism — around security, performance, and operational complexity — gave way to mainstream adoption as tooling matured and providers invested heavily in the underlying infrastructure.
The same pattern played out with containers. Early objections centered on:
- Security: Shared kernel concerns and image supply-chain risks were real but addressable through scanning, runtime policies, and namespace isolation improvements.
- Orchestration complexity: Running a handful of containers manually is simple; running thousands across a cluster requires tooling like Kubernetes, which by 2017 was already gaining significant traction.
- Stateful workloads: Persistent storage, databases, and stateful services required additional patterns (e.g., persistent volumes, StatefulSets) before containers were viable for every workload type.
The question posed in 2017 — whether mainstream adoption would take six months or three years — was ultimately answered closer to the three-year end of that range for enterprise-wide adoption, though developer-led adoption moved faster.
Prediction 3: Container Adoption Would Pull Organizations Toward Cloud-Native Architecture
Perhaps the most structurally interesting prediction was that containers wouldn’t remain isolated tools — they would act as a forcing function for broader organizational change.
The argument: container adoption typically begins at the developer or operations level, driven by concrete productivity gains. As those teams demonstrate value, IT leadership seeks to extend that value organization-wide. But to extract the full benefit, containers need to be part of a broader shift:
- Adopting DevOps practices — breaking down silos between development and operations.
- Shifting toward automation-first thinking — treating manual toil as a defect, not a workflow.
- Designing for resiliency and rapid iteration, rather than optimizing for infrequent, high-risk releases.
- Running enterprise applications with the same operational model used by SaaS companies — continuous deployment, feature flags, automated rollback.
This prediction proved accurate. Organizations that adopted containers as isolated tools without accompanying process change saw limited returns. Those that used container adoption as the catalyst for broader DevOps transformation — rethinking CI/CD pipelines, on-call culture, deployment frequency, and incident response — saw compounding benefits.
The Underlying Principle: Technology Enables, People and Process Decide
The most durable insight from these 2017 predictions isn’t about containers specifically — it’s about how transformative infrastructure technologies actually propagate through organizations.
The specific tool matters less than the strategic shift it enables. Containers are an enabling technology for continuous improvement as a default operating model. That model requires:
- Optimizing for frequent, small deployments over large, infrequent releases.
- Investing in automation at every layer — build, test, deploy, monitor, and remediate.
- Building organizational capability alongside technical capability — talent, training, and coordination matter as much as the toolchain.
Organizations that adopted containers as part of this broader mindset shift realized the most durable benefits. Those that treated containers as a drop-in replacement for VMs, without changing how they shipped and operated software, found that the promised benefits were much harder to capture.
Looking Back From Today
Reviewed from the vantage point of several years later, these 2017 predictions aged well in direction if not always in exact timing. Cloud-native development is now a baseline expectation. Kubernetes has become the dominant container orchestration standard. Enterprises across financial services, healthcare, government, and retail have moved significant workloads to container-based architectures.
The remaining frontier — legacy application modernization, stateful workload containerization, and security at scale — continues to be worked through. But the trajectory is clear: containers moved from grassroots developer tool to mainstream enterprise infrastructure in roughly the timeframe these predictions anticipated.
For DevOps teams evaluating their own container maturity today, the relevant question is no longer whether to adopt containers, but how deeply the accompanying process and cultural changes have taken hold alongside the technology.