I am going to say something that will upset a lot of people who have invested significant portions of their careers into container orchestration: Docker Compose is probably all you need.
Not Kubernetes. Not ECS. Not Nomad. Not whatever managed container platform your cloud provider is pushing this quarter. Docker Compose. The thing you used in tutorials before graduating to real infrastructure. That thing. It is enough.
Kubernetes is incredible technology you do not need
Kubernetes can do amazing things. It can manage thousands of containers across hundreds of nodes. It can self-heal, auto-scale, handle rolling deployments, manage secrets, configure networking, and orchestrate workloads across multiple data centres. It is genuinely impressive engineering.
It was also built by Google to solve Google problems. You do not have Google problems. You have a web app, maybe a background worker, probably a database. You could run all of it on a single server. Two servers if you want redundancy. You are not managing a fleet. You are running an application.
But somewhere along the way, Kubernetes became the default. New projects spin up clusters before they have users. Startups with three engineers hire platform teams. Everyone learns kubectl and writes YAML files and pretends this is normal.
It is not normal. It is overkill. You have been sold complexity you did not ask for.
What Docker Compose actually gives you
A docker-compose.yml file is a single source of truth for your application. It defines your services, their dependencies, their environment variables, their volumes, their networks. You run docker-compose up and everything starts. You run docker-compose down and everything stops.
That is it. No cluster to manage. No control plane to maintain. No networking plugins to debug. No persistent volume claims to configure. No ingress controllers to set up. No service mesh to understand. Just containers running on a machine doing what you told them to do.
For most applications, this is enough. You can run a web server, a database, a cache, a queue, a worker, all defined in one file, all running on one server. When you need to update something, you pull the new image and restart. When something breaks, you read the logs right there on the machine.
Boring? Absolutely. Effective? Also absolutely.
The complexity is not free
Every layer of abstraction has a cost. Kubernetes has enormous costs.
You need to learn Kubernetes. Not a weekend project. A significant investment in understanding concepts, commands, patterns, and failure modes. Your whole team needs this knowledge, or you need a dedicated platform person, which is another salary.
You need to maintain Kubernetes. Upgrades, security patches, configuration drift, certificate rotation. Managed Kubernetes helps but does not eliminate this. Someone still needs to understand what is happening.
You need to debug Kubernetes. When something goes wrong, and something will go wrong, you are not just debugging your application. You are debugging your application plus the orchestration layer plus the networking layer plus whatever else is between your code and the user.
All of this complexity exists so that you can handle scale you probably do not have. If you are under ten thousand requests per minute, a single well-configured server is fine. If you are under a hundred thousand, two servers behind a load balancer is fine. You do not need Kubernetes until you do, and most companies never get there.
But what about high availability
Fair question. You want redundancy. You want failover. You want to survive a server dying.
Here is a secret: you can do that without Kubernetes. Run your app on two servers. Put a load balancer in front. Use managed database services that handle replication for you. If one server dies, the other keeps running. This is high availability. It has existed for decades.
Kubernetes makes this easier at scale. When you have fifty services across twenty servers, manual orchestration becomes painful. But you do not have fifty services. You have one service, maybe five if you have been busy. You can manage that with shell scripts and cron jobs and a deployment that takes thirty seconds.
The Kubernetes crowd will say this does not scale. They are right. It does not scale to Google size. It scales perfectly well to the size of your actual business.
The YAML industrial complex
I have seen Kubernetes configurations that span thousands of lines across dozens of files. Deployments, services, configmaps, secrets, ingresses, persistent volume claims, network policies, resource quotas, horizontal pod autoscalers. Each one is another thing to maintain, another thing to get wrong, another thing to debug at 3am.
Compare this to a fifty-line docker-compose.yml that does everything you need. Which one would you rather hand to a new developer? Which one would you rather debug when something breaks? Which one would you rather maintain for the next five years?
The Kubernetes ecosystem has created an entire industry of tools to manage Kubernetes complexity. Helm charts. Kustomize. ArgoCD. Flux. Terraform modules. Pulumi stacks. Each tool adds value, and each tool adds complexity. You end up maintaining tooling to maintain tooling.
Docker Compose needs nothing. It is the tool. There is no meta-layer.
Try the simple thing first
I am not saying Kubernetes is always wrong. If you genuinely have the scale, the team, and the requirements, it can be the right choice. Some workloads genuinely need sophisticated orchestration.
But try Docker Compose first. See how far it takes you. I bet it is further than you think. I have seen applications serve millions of requests running on Docker Compose. I have seen startups reach profitability without ever touching Kubernetes. It is possible. It is even common among companies that are not trying to impress anyone.
The best infrastructure is the simplest infrastructure that meets your needs. For most of us, that is a compose file and a server.
Stop overcomplicating things. Your application is not that special. Neither is mine. Docker Compose is enough.