Kubernetes Without a Platform Team: A Leaner Path for Small Products

Every few months a small team decides to adopt Kubernetes because it is what serious companies use. Six weeks later the same team is maintaining ingress controllers, certificate renewals and a cluster upgrade calendar instead of shipping the product. The technology is not the problem. The problem is adopting a platform designed for organisational scale without the organisation.

That does not mean small teams should avoid containers. Containers are a sane packaging format, and a managed container runtime can be an excellent home for a handful of services. The useful question is narrower: which parts of Kubernetes do you actually need, and which parts can a managed service own on your behalf?

What you are really buying

Kubernetes gives you a declarative API for scheduling containers, plus a large ecosystem of controllers that extend that API. For a small product, the valuable parts are usually:

• Rolling deploys with health checks and automatic rollback.
• Horizontal scaling based on CPU or request metrics.
• Service discovery and internal load balancing.
• A consistent way to run background workers and cron jobs.

The parts that create the most operational work are the ones small teams rarely need on day one: custom operators, multi-tenant cluster isolation, fine-grained network policies, service mesh traffic shaping and self-managed control planes.

The hidden operating cost

The control plane is the visible cost. The hidden cost is attention. A self-managed cluster needs a named owner for:

• Version upgrades. Kubernetes releases roughly three minor versions a year. Falling two versions behind turns a routine upgrade into a project.
• Certificate and DNS hygiene. Expired ingress certificates are still one of the most common causes of short outages.
• Capacity and autoscaling. Node pools need headroom for spikes, and cluster autoscaler behaviour is provider-specific.
• Security patches. Base images, admission policies and secrets rotation all need a schedule.
• Observability. Logs and metrics from a cluster can cost more than the workloads themselves if retention is left at defaults.

If no one can own those five items for at least a year, a self-managed cluster is a liability. A managed control plane removes some of them, but not the application-level work.

A managed baseline that works

For a team of two to eight engineers, a workable baseline is:

1. Managed control plane. Let the provider patch the API server and etcd. You keep the workloads and the bill.
2. Two node pools. One general pool and one spot or burst pool. Keep the general pool small and predictable.
3. One ingress layer. A managed load balancer plus cert-manager or the provider's certificate service. Do not run your own ingress controller unless you need custom routing rules.
4. GitOps with a single source of truth. Argo CD or Flux, one repository, one environment per directory. Avoid hand-edited YAML in production.
5. Policy as code, lightly. A few admission rules for resource limits, image registries and required labels are enough. A full policy framework can wait.

This setup keeps the deployment model portable without turning the team into cluster administrators. It also keeps costs visible: one control plane fee, one load balancer, two node pools and a logging bill you can explain.

When not to use it

There are clear cases where a simpler runtime is the better engineering decision:

• One monolith with steady traffic. A managed app platform or a couple of VMs behind a load balancer will be cheaper and easier to reason about.
• Mostly static sites. A CDN and a build pipeline cover it. There is nothing to schedule.
• Batch jobs that run a few times a day. A scheduled container task or a serverless function is less machinery.
• No one wants to own upgrades. This is the strongest signal. Choose the runtime that matches the team's maintenance appetite, not its ambitions.

Kubernetes is also a poor fit when the workload is dominated by a managed database. If 80% of the value sits in a hosted Postgres instance, the orchestration layer is a small part of the architecture and should not dominate the operations budget.

A decision checklist

Use these questions as a filter. A "no" is not fatal, but it should be deliberate.

• Do we have at least one engineer who will own cluster upgrades for the next 12 months?
• Do we need scheduling flexibility that a managed app runtime cannot provide?
• Can we afford a managed control plane and a load balancer before we need them?
• Is our observability bill capped and owned?
• Do we have a rollback path that does not depend on a human reading a runbook at 2 a.m.?

The bottom line

Kubernetes earns its keep when a team needs a common deployment model across several services and has someone accountable for the platform. Without that owner, the honest choice is a managed container service, a PaaS or even a few well-monitored VMs. Choosing the smaller tool is not a lack of ambition; it is capacity planning for the team you actually have.