Kubernetes is a staffing decision first

Technology

Kubernetes is very good at one thing: holding a declared state true across a fleet of long lived services, restarting what dies and packing the rest onto nodes you are already paying for. That is worth real money when you run dozens of services under steady load.

It is worth much less when you have a frontend and a handful of functions. Most teams meet Kubernetes already running and already governed, and the useful move then is to ship into the cluster they have rather than argue them off it.

Monogram logo

The tradeoff

What a cluster gives you, and what it asks for

  1. The reconciliation loop is the product

    You declare what should be running and the control plane keeps making it true: rescheduling pods off a dead node, scaling a deployment to match load, rolling an update without dropping requests. That loop is the actual product, and it pays off across dozens of services rather than one.

  2. The cluster is a second product to run

    Ingress controllers, certificate rotation, autoscaler tuning, version upgrades a few times a year, and CRDs from every vendor you added. Someone owns that full time, and that someone is not shipping features. The honest cost of a cluster is a person, not a line on the cloud bill.

  3. Meet the cluster that already exists

    When a client already runs Kubernetes, the useful move is a container and a chart that land inside the cluster their security team approved, reusing its network policy and its secrets. Starting from nothing, we deploy to Vercel or a managed runtime. No case study here runs on Kubernetes.