Mont-E
Operations · 2026-08-04 · Mont-E Engineering

Running enterprise apps on Kubernetes without a platform team

Running enterprise apps on Kubernetes without a platform team

Kubernetes has a reputation for demanding a platform team, and for a mid-sized business that reputation is a fair warning. But the alternative — a handful of pet servers, deployments by hand, and a recovery procedure that lives in one person's memory — has failure modes that are worse and quieter.

What makes a small cluster survivable is not more Kubernetes; it is less of it. A short, deliberately dull list of choices, applied everywhere.

Everything from Git. Every workload is a manifest in a repository, applied by a controller that reconciles continuously. Nobody edits live objects. This single rule turns 'what is running in production' from an investigation into a diff, and makes rebuilding an environment a checkout rather than an archaeology project.

Pin what you deploy. Mutable tags are the sharpest edge we see in the field: a pod evicted at 2 a.m. and rescheduled onto a newer image is a deployment nobody decided to make, running beside older replicas of the same service. Digests remove that whole class of surprise.

Stateful things get named owners. Databases are not just another workload. Decide deliberately where the data lives, how it is replicated, how a restore is tested, and who is called. A backup nobody has restored is a hypothesis, not a backup — schedule the drill.

Monitoring you would actually wake up for. A small number of alerts that mean something beats a wall of dashboards nobody reads. Disk filling, replication lagging, certificates expiring, a queue growing without bound: those are the ones that turn into outages.

One cluster, deliberately boring. Multi-cluster and multi-region are real answers to real problems most mid-sized businesses do not yet have. Until then, complexity is the risk, and the cheapest availability win is usually a tested restore and a second replica of the database.

Done this way, Kubernetes stops being a platform to staff and becomes what it should be: a deployment target that behaves the same on Tuesday as it did on Friday, and that someone else can pick up from the repository if you are unavailable. That is the property worth paying for — not the orchestration, the repeatability.