Containers and Kubernetes: Do You Actually Need Them?
Key takeaway
Containers are worth adopting almost immediately — they make environments reproducible. Kubernetes is a different decision: it solves orchestration problems that appear with many services and multiple teams, and below that threshold a managed container service delivers most of the benefit with a fraction of the operational burden.
These two technologies get discussed as one choice. They aren't. Containers are packaging; Kubernetes is a platform for running a lot of them, and it comes with a platform's worth of responsibility.
Containers: adopt these early
- The same image runs on a laptop, in CI, and in production — which eliminates an entire category of environment bug.
- Dependencies are declared in a file rather than installed by hand on a server.
- New engineers get a running environment in minutes.
- Deployment becomes "run this image", which every hosting platform now understands.
What Kubernetes adds
- Scheduling containers across many machines, with self-healing when one dies.
- Declarative rollouts, service discovery, and autoscaling.
- A consistent abstraction across clouds and on-premise.
- A common platform many teams can deploy to independently.
What it costs
Kubernetes brings its own networking model, storage model, access control, upgrade cycle, and failure modes. Somebody has to understand all of that at 3am. For a team running three services, that expertise is a full-time responsibility being paid for out of feature time.
The honest decision points
- Fewer than about ten services and one team: a managed container platform (ECS, Cloud Run, App Service, or similar) is almost certainly the better answer.
- Many services, multiple teams deploying independently, or a genuine multi-cloud requirement: Kubernetes starts to justify itself.
- A regulatory or contractual need to run the same platform on-premise and in the cloud: a strong case.
- "We might need to scale": not a reason. Managed platforms autoscale too.
If you do adopt it
- Use a managed control plane; running your own is a specialist undertaking with no business value.
- Treat cluster configuration as code, reviewed like application code.
- Set resource requests and limits from the start — omitted limits are the most common cause of cluster instability.
- Budget for upgrades: clusters need regular version maintenance, and deferring it compounds quickly.