Kubernetes

Kubernetes runs containerised applications across a set of machines: it decides where each service executes, restarts it when it falls over, adds instances as load rises, and replaces old versions with new ones without downtime. It has become the industry's de facto standard, and it's also the tool most often adopted for the wrong reasons — because it's on every job posting, not because the project called for it.

• →Docker and container compositionThe same reproducibility benefit with no orchestrator to operate: the right level for most projectsView page
• →Application hosting platformsWhen the goal is to operate no infrastructure at allView page
• →NomadMarkedly simpler orchestration to operate, when scheduling across machines really is needed
• →TerraformTo describe and replay the underlying infrastructure, cluster or no clusterView page

1. 01

   Ask whether it's needed before asking how to build it, and accept that the answer may be no

2. 02

   Managed cluster with a provider rather than self-managed: maintaining the control plane adds no business value

3. 03

   One way to deploy, described in the repository, rather than commands typed by hand

4. 04

   Persistent state outside the cluster wherever possible: managed database and object storage

5. 05

   Resource limits and health probes from the first service, not after the first incident

• At what point does Kubernetes become justified?

  When several teams independently deploy several services, when load varies enough that elasticity changes the bill, or when the same platform must be replayed identically across several environments. Below that, the ratio between what it brings and what it demands works against you. The threshold isn't a company size, it's a number of separately deployed services.
• Is Docker enough instead?

  For many projects, yes. Containers solve the main problem — the application runs identically everywhere — and a compose file on one or two machines covers a common need. Kubernetes solves a different problem: running many containers across many machines without human intervention. If you don't have that second problem, you don't need its solution.
• What does it cost to run?

  Two distinct lines. Infrastructure: the cluster's machines, sometimes plus a monthly fee for the managed control plane, billed even at zero load. And operations: cluster upgrades come round several times a year and aren't optional. It's that second line, invisible at decision time, that really sets the bill.
• What does migrating to Kubernetes cost?

  What drives it is the number of services to port, how containerised they already are, how persistent state is handled, the number of environments and the rework of the deployment pipeline. But before pricing a migration, I'd rather price the alternative: in half the cases it meets the same need for far less. The amount is set in the quote, after a free initial scoping session that puts the scope in writing before any commitment.
• Does a managed cluster remove the complexity?

  It removes the most thankless part — keeping the control plane available — and that alone is reason enough to prefer it over self-managed. It removes neither networking, nor persistent storage, nor permissions, nor upgrades of the components you installed inside it. Which is most of what makes it hard day to day.