Every second tech article I read right now mentions Kubernetes. It's the future of infrastructure. It's how Google runs everything. It solves scaling, deployment, service discovery, and apparently makes coffee. I've been running Kubernetes in production for the past year, and my honest assessment is more nuanced than the hype suggests. Especially for the kind of enterprise teams we work with in New Zealand.
What You Need to Know
- Kubernetes is a powerful container orchestration platform that solves real problems at scale
- The operational overhead is significant and often underestimated by teams adopting it
- For most NZ enterprise teams with 5-15 developers, managed Kubernetes services or simpler alternatives may be more appropriate
- The decision should be based on operational complexity needs, not industry trends
What Kubernetes Actually Solves
At its core, Kubernetes manages containers across a cluster of machines. It handles scheduling (which container runs where), scaling (spinning up more instances under load), service discovery (how containers find each other), and self-healing (restarting containers that crash).
These are real problems. If you're running 50 microservices across 20 servers, manually managing which service runs where, how they discover each other, and what happens when a server fails is genuinely difficult. Kubernetes automates all of this.
It also provides a declarative infrastructure model. You describe the desired state ("I want three instances of this service running behind a load balancer") and Kubernetes continuously works to make reality match that description. When a container crashes, Kubernetes restarts it. When a node fails, Kubernetes reschedules the containers elsewhere. When traffic spikes, Kubernetes scales up.
40%
of enterprises using containers in production run Kubernetes
Source: Cloud Native Computing Foundation Survey, 2018
The Operational Reality
Here's what the conference talks don't emphasise enough: Kubernetes is complex. Genuinely complex. The learning curve is steep, the configuration surface area is enormous, and the failure modes can be subtle and difficult to diagnose.
A basic Kubernetes cluster requires understanding of pods, deployments, services, ingress controllers, persistent volumes, config maps, secrets, namespaces, RBAC policies, network policies, and resource quotas. That's before you add monitoring, logging, CI/CD integration, and certificate management.
The Staffing Question
Running Kubernetes well requires dedicated operational expertise. Not just someone who's read the documentation, but someone who understands networking, storage, security, and distributed systems well enough to diagnose problems when things go wrong. And things do go wrong.
For a large organisation with a dedicated platform team, this is feasible. For a typical NZ enterprise team with one or two ops people who also manage the database, the email server, and the office network, it's a significant ask.
Kubernetes doesn't reduce operational complexity. The question is whether the new complexity serves your needs better than the old one.
John Li
Chief Technology Officer
The Cost Question
Self-managed Kubernetes clusters require significant compute resources just for the control plane. Master nodes, etcd clusters, and the various Kubernetes system components consume resources before you run a single application container.
Managed services (EKS, AKS, GKE) reduce the operational burden significantly by handling the control plane for you. But they add cost and introduce their own abstractions and limitations. You're running Kubernetes, but you're running someone else's version of Kubernetes with their opinions about networking, storage, and access control.
When Kubernetes Makes Sense
Microservices at Scale
If you're genuinely running 20+ services that need independent scaling, deployment, and lifecycle management, Kubernetes is probably the right tool. The orchestration overhead is justified by the operational complexity it manages.
Multi-Team Environments
When multiple teams need to deploy independently to shared infrastructure, Kubernetes' namespace and RBAC model provides isolation and governance that's hard to achieve with simpler tools.
Variable Load Profiles
Applications with significant traffic variation benefit from Kubernetes' auto-scaling. If your system handles 100 requests per minute normally but 10,000 during peak periods, automatic scaling is valuable.
When It Probably Doesn't
Monolithic Applications
If you're running a single application with a database, Kubernetes adds complexity without corresponding benefit. A single server or a simple load-balanced pair, managed with Ansible or Terraform, is simpler, cheaper, and easier to operate.
Small Teams
A team of five developers with no dedicated operations function will spend more time managing Kubernetes than building features. The operational overhead consumes time that should be spent on the product.
Stable Load
If your traffic is predictable and consistent, auto-scaling provides no benefit. You're paying the complexity tax for a capability you don't use.
The NZ Enterprise Recommendation
For most NZ enterprise clients we work with, my recommendation is pragmatic:
Start with simpler infrastructure. Docker containers deployed to managed cloud services (AWS ECS, Azure App Service, or even straightforward virtual machines with Docker Compose) handle most enterprise workloads effectively. The deployment is automated, the scaling is manageable, and the operational overhead is proportional to the team's capacity.
Adopt Kubernetes when the complexity justifies it. If you outgrow simpler infrastructure, if your service count climbs past 10-15, if your scaling needs become genuinely dynamic, then evaluate managed Kubernetes. But evaluate it against the operational capacity of your team, not against what Google is doing.
Use managed services if you do adopt. Self-managed Kubernetes clusters are an ongoing operational commitment. Managed services (AKS is the most common choice for NZ enterprise clients on Azure) remove the heaviest operational burden while giving you the orchestration benefits.
The technology is impressive. The question isn't whether Kubernetes is good. It's whether it's right for your team, your scale, and your operational capacity. For most NZ enterprise teams in 2019, the honest answer is: not yet.