Kubernetes.

Where Kubernetes fits on a long engagement.

Kubernetes solves a real problem once you have enough services that placing them by hand stops being reasonable. It gives every team the same deployment interface, recovers from a failed node without anyone waking up, and makes scaling a configuration change rather than a project.

It is also the clearest example of a platform adopted before it was needed. Three services on two machines do not need a cluster; they need a deploy script and a backup. Kubernetes introduces its own class of incident — misconfigured limits, evictions, networking that behaves differently in production — and those need an owner who is not also the product team.

What an assigned team does with Kubernetes.

A cluster needs an owner who is not also shipping features, because the two jobs interrupt each other and the platform always loses. Organisations that adopt Kubernetes without that person get a cluster configured once, upgraded never, and understood by whoever happens to be on call.

The work is continuous by nature — version upgrades, certificate rotation, capacity, the incident that turns out to be a memory limit set in 2023. That is assigned under DevOps managed services rather than as a migration project with an end date.

What we use Kubernetes for.

• One deployment path for several teams Teams shipping without each inventing their own release process, which is where platform engineering earns its cost.
• Making scale a setting rather than a project Capacity that follows demand, with limits set from measured behaviour rather than guessed at.
• Taking the cluster off the product team Someone owning the platform so feature engineers stop losing days to it.

How Kubernetes capacity is assigned.

Cluster work is assigned under DevOps as a service, inside your own cloud account. Where the honest answer is that you do not need Kubernetes yet, we will say that at scoping. Capacity is agreed as a committed monthly capacity rather than per skill.