Kubernetes for a Bicycle
Text
1. The claim
Choosing an operational model is choosing a fixed monthly cost in engineer-hours. That cost is incurred on the quiet weeks as well as the busy ones, and it is paid by the same people who are supposed to be building the product.
The bicycle in the title is the load. The failure is not that the machinery is bad machinery. It is that the machinery has a minimum operating crew, and a team that cannot staff that crew ends up operating it badly, which is worse than operating something smaller well.
Both times I got this wrong I had done the arithmetic. Both times the arithmetic was about the cluster. The cluster was never the expensive part.
2. Fixed and variable, drawn honestly
effort
^
| heavy stack
| ------------------------------ fixed floor
| /
| /
| light stack /
| ____________/
+--------------------------------> load
^
break-even, which is
further right than it looks
The shape is uncontroversial. The mistake is in placing the floor, and the floor is placed by what is on the list in Section 3 rather than by the orchestrator itself.
3. What the fixed cost is actually made of
| Cost | Why it is underestimated |
|---|---|
| Upgrade cadence | The platform has a support window measured in months. Somebody owns that treadmill permanently, and it does not scale down when the product is quiet. |
| Network policy and identity | The default posture is usually open, so a real deployment needs policy, service identity and secret distribution designed rather than adopted. This is where most of the first quarter goes. |
| The build and release path | Registries, image provenance, signing, promotion between environments. All defensible, all work, none of it visible in the decision that started it. |
| Observability of the platform itself | You now have two systems to watch: the product, and the thing running it. Both page. |
| On-call knowledge | The largest and least tracked. Every engineer in the rotation needs a working model of the platform's failure modes, which is a training cost paid per person and again on every hire. |
| Bus factor on the platform | In a small team this is usually one person, and the fixed cost is invisible until that person takes leave. |
Figure 2. What I costed against what it cost, both times. Drawn from two cases in hindsight, which is not a sample.
4. The ladder, and the triggers for climbing it
The useful discipline is not choosing correctly on day one. It is naming, in advance, the observation that will move you up a rung. Without a named trigger the decision is made by whoever is most enthusiastic in the room.
| Rung | Move up when |
|---|---|
| One machine, one artifact, a service manager | A single machine's failure becomes an unacceptable outage, or deploys need to be zero-downtime. |
| Two or three machines, a load balancer, deploys by script | You are hand-placing more than about ten distinct workloads, or bin-packing has become a spreadsheet. |
| Managed container runtime | You need scheduling policy the platform cannot express: affinity, priority classes, custom autoscaling, per-tenant isolation. |
| Full orchestration | You have a platform owner. Not a volunteer. A role. |
The last trigger is the whole paper compressed into one line. If the answer to “who owns the platform” is a name plus the word “also”, the rung is too high.
5. The strongest objection
6. What this paper does not claim
Orchestration is not over-engineering. At sufficient scale it is the cheapest option available and the fixed cost is recovered without anyone noticing. Managed offerings do help; they absorb less of the list in Section 3 than their marketing implies, which is a complaint about the marketing rather than about the product. The ladder in Section 4 is one sensible ordering and not the only one.
Nor have I fully learned this. Two occurrences is a pattern, not a cure, and I would not bet against a third.
Retirement conditions
This paper MUST be retracted if any of the following is demonstrated.
| § | Condition |
|---|---|
| 1 | A team of five or fewer engineers, with no dedicated platform role, running a full orchestration stack for eighteen months while spending less total time on the platform than on the product, measured rather than recalled. |
| 2 | Managed orchestration reaching a point where the fixed costs listed in Section 3 are genuinely absorbed by the provider, including upgrade cadence, network policy and on-call knowledge, at which point the break-even in Section 4 moves far enough to invert the advice. |
| 3 | Evidence that starting simple and migrating later costs more in aggregate than starting heavy, which is the inverse of the assumption this paper rests on and the one I would most like to see tested. |
Revision history
| Date | Change |
|---|---|
| 2026-08-14 | Text written: what the fixed cost is actually made of, the ladder and its triggers, and the ecosystem objection. Retirement conditions added. Confidence unchanged. |
| 2025-03-11 | Listed in Section 5 with a title, a summary and a confidence value. No text. |