Docker has become ubiquitous in new projects since around 2016, with teams reaping immediate benefits from reproducible environments, lightweight dependencies, and a clear path from development to production. Environment setup time was reduced by an order of magnitude for teams that adopted Docker, even for development only.
Docker Compose is the right tool for local multi-service development, defining services, network connections, and volume mounts in a docker-compose.yml file. However, the pattern breaks down for production, lacking health-based scheduling, automatic restarts, or horizontal scaling.
Organisations with large-scale container workloads initially drove Kubernetes adoption, as manual placement and Docker Compose orchestration were insufficient. Managed Kubernetes services (AKS, EKS, GKE) made Kubernetes accessible to organisations without dedicated platform engineering teams.
For example, at one organisation I worked with, we started with around 20 containers and a simple Docker Compose setup. As the team grew and the workload increased, we found that Docker Compose was unable to handle the complexity, with containers often becoming unresponsive or failing to restart after a crash. We migrated to Kubernetes and saw an immediate improvement in uptime and responsiveness, with a significant reduction in manual intervention required to keep the system running.
By 2020, the question is no longer whether Kubernetes is the right production container orchestrator, but how much operational investment is necessary for the scale of the workload. The answer depends on the organisation's specific needs and goals. In my experience, the operational investment required for Kubernetes can be substantial, with a team of at least 2-3 engineers required to manage a cluster of 100 nodes or more, depending on the complexity of the workload and the level of automation required.
Helm templating and chart packaging became the standard Kubernetes application packaging format through 2019-2020. The Helm chart provides a parameterised, versioned Kubernetes application package, with ArtifactHub (the CNCF chart repository) offering public charts for common infrastructure components. I have seen firsthand the benefits of using Helm charts, with one team reducing their deployment time from several hours to just 30 minutes by using a well-structured Helm chart to manage their application configuration.
One operational concern with Helm is the risk of chart upgrades changing resources unexpectedly. Helm 3 (released November 2019) addressed most of the Helm 2 operational concerns, removing Tiller and improving the overall package management experience. In practice, this means that teams can now upgrade their applications with much greater confidence, using tools like Helm to manage the rollout of new versions and minimize downtime.
The container journey for many organisations begins with Docker adoption, followed by Docker Compose for local development, and then the question of production orchestration. Kubernetes has become the de facto choice for production orchestration in 2020. As an example, a small team I worked with was able to get started with Docker and Kubernetes using a managed service like GKE, with a total investment of around $5,000 per month for a cluster of 10 nodes, which was a fraction of the cost of building and maintaining their own cluster.
However, the choice of Kubernetes is not without its trade-offs. For smaller workloads, the overhead of managing a Kubernetes cluster can be significant, with teams requiring a substantial investment in tooling and automation to manage the cluster effectively. In these cases, other tools like Docker Swarm or Apache Mesos may be more suitable, offering a simpler and more lightweight approach to container orchestration.
Docker's adoption curve shows a clear pattern: development teams first adopt Docker for its benefits, and then organisations move to production with Docker Compose. However, this approach has its limitations, leading many to Kubernetes for production orchestration. I have seen this pattern play out in numerous organisations, with teams often underestimating the complexity of managing a large-scale container workload and the need for a more robust orchestration platform like Kubernetes.
Managed Kubernetes services (AKS, EKS, GKE) have made Kubernetes more accessible to organisations without dedicated platform engineering teams, allowing them to take advantage of the benefits of Kubernetes without the operational overhead. For instance, a team I worked with was able to use a managed service to deploy a complex application with over 50 microservices, with the managed service handling the underlying infrastructure and allowing the team to focus on developing the application.
The choice between Kubernetes and other container orchestration tools ultimately depends on the organisation's specific needs and goals. While Kubernetes has become a popular choice, other tools may be more suitable for smaller or less complex workloads. As an engineer with many years of experience in this space, I can attest that there is no one-size-fits-all solution, and the choice of tooling will depend on a careful evaluation of the trade-offs and requirements of the specific use case.