Kubernetes Won't Fix Your Architecture

Every few years, a technology emerges that teams adopt with the expectation that it will solve their fundamental engineering problems. Microservices was one. Kubernetes is another.

Kubernetes is genuinely excellent at what it does: container orchestration, workload scheduling, declarative infrastructure, and the operational primitives needed to run distributed systems at scale. It is one of the most important infrastructure technologies of the last decade.

But it is not an architecture. And when teams adopt Kubernetes expecting it to fix architectural problems, they often end up with the same problems they had before, plus the operational complexity of running a Kubernetes cluster.

What Kubernetes actually solves

Kubernetes provides:

Declarative workload management — You describe the desired state (replicas, resources, health checks) and Kubernetes reconciles reality to match.
Service discovery and networking — Services can find each other, load balance, and communicate without hardcoded addresses.
Horizontal scaling — Scale workloads up and down based on demand.
Self-healing — Restart failed containers, reschedule workloads from unhealthy nodes.
Rollout management — Rolling updates, rollbacks, and deployment strategies.
Resource isolation — CPU and memory limits, namespaces, and network policies.

These are powerful capabilities, and for the right problems, Kubernetes is the right answer.

What Kubernetes does not solve

Service boundaries

Kubernetes can run any container. It does not care whether the service inside that container has well-defined boundaries, a clear API contract, or appropriate scope.

If your monolith was poorly structured, breaking it into microservices and running them on Kubernetes does not fix the structural problems. It distributes them. Now instead of tangled code within one process, you have tangled dependencies across a network, with latency, partial failure, and distributed state consistency to manage.

I have seen teams migrate to Kubernetes with services that call each other in a tight loop, share databases, or have circular dependencies. Kubernetes runs these services reliably, but the architecture is still fragile.

The lesson: Define clear service boundaries based on domain modeling before containerizing. Kubernetes orchestrates services. It does not design them.

Operational standards

Kubernetes provides the infrastructure for running workloads, but it does not enforce how those workloads behave.

Without operational standards, your Kubernetes cluster will contain:

services with no health checks
deployments with no resource limits
containers with no structured logging
workloads with no monitoring or alerting
services that crash silently and restart indefinitely

Kubernetes will keep them running, but running is not the same as operating.

I help teams define and enforce operational standards for Kubernetes workloads:

readiness and liveness probes — every service must define health checks
resource requests and limits — every container must declare its resource needs
structured logging — all services emit logs in a consistent, structured format
labeling conventions — every resource is tagged with team ownership, environment, and cost center
network policies — services can only communicate with their declared dependencies
pod disruption budgets — availability guarantees during node maintenance

These standards can be enforced through admission controllers, OPA/Gatekeeper policies, or platform tooling. The key is that they are automated, not aspirational.

Deployment safety

Kubernetes supports rolling updates and rollbacks, but the default deployment strategy is minimal:

replace old pods with new pods
check readiness probes
done

This is better than no automation, but it is not a delivery system.

Production-grade deployment on Kubernetes requires:

canary deployments — route a percentage of traffic to the new version and monitor before proceeding
automated rollback on metric degradation — if error rates or latency increase after deployment, roll back automatically
deployment pipelines — multi-stage promotion from staging to canary to production
GitOps — the desired state of the cluster is stored in Git, with automated reconciliation

Tools like Argo Rollouts, Flagger, and Flux provide these capabilities, but they require intentional setup and integration with your monitoring stack.

Database and state management

Kubernetes was designed for stateless workloads. Running stateful workloads (databases, message queues, caches) on Kubernetes is possible but requires careful consideration.

The common mistake I see is teams moving everything to Kubernetes, including their databases, without understanding the operational implications:

persistent volume management and backup
node affinity and topology constraints
handling of node failures and pod rescheduling
performance implications of storage drivers
backup and restore procedures

For most teams, I recommend running stateful services (databases, queues) as managed services outside Kubernetes and running stateless application workloads inside Kubernetes. This gives you the orchestration benefits without the operational complexity of managing state on Kubernetes.

Debuggability

Kubernetes adds layers of abstraction between you and your running code: pods, containers, services, ingresses, config maps, secrets, network policies. Each layer is a potential source of problems.

When something goes wrong, the debugging process involves:

is the pod running?
are the health checks passing?
is the service routing traffic correctly?
are the config maps and secrets mounted?
is the network policy allowing traffic?
is the ingress configured correctly?
is there enough resource on the node?
is the persistent volume attached?

This is solvable with good tooling and documentation, but it is additional complexity that teams must be prepared for.

The platform engineering angle

The most successful Kubernetes adopters I work with treat Kubernetes as an implementation detail of their internal platform, not as the platform itself.

Developers should not need to write Kubernetes YAML. They should interact with an abstraction that captures their intent:

"I want to deploy this service with 3 replicas and a health check"
"I want to expose this service on this domain"
"I want to run this job on a schedule"

The platform team translates these intents into Kubernetes resources, enforces standards, and handles the operational complexity.

This is the golden path approach applied to infrastructure:

service templates that generate Kubernetes manifests with all required standards (health checks, resource limits, monitoring, logging)
deployment workflows that handle canary rollouts, approval gates, and rollback
self-service tooling that lets teams provision databases, caches, and queues without writing infrastructure code
guardrails that prevent common mistakes (no resource limits, no health checks, exposed secrets)

When Kubernetes is the right choice

Kubernetes is genuinely the right choice when:

you are running many services that need independent scaling and deployment
your traffic patterns require horizontal scaling
you need to support multiple teams with isolation and resource management
you are investing in a platform team that can manage the Kubernetes infrastructure
your services are genuinely stateless or can be designed that way
you have the observability and operational tooling to diagnose problems in a distributed environment

When Kubernetes is not the right choice

Kubernetes is not the right choice when:

you are running a small number of services that could be deployed simply
you do not have the team capacity to manage Kubernetes operations
your primary problem is architectural (unclear boundaries, tight coupling, shared state) rather than operational
the managed services from your cloud provider give you everything you need at lower operational cost
you are adopting Kubernetes because it is what everyone else does, without a clear problem it solves for your organization

Recommendations

If you are considering Kubernetes or already running it, here is my advice:

Fix your architecture first. Define clear service boundaries, API contracts, and dependency relationships before containerizing.
Establish operational standards. Health checks, resource limits, structured logging, and labeling should be enforced through policy, not documentation.
Invest in deployment safety. Rolling updates are a starting point, not a destination. Implement canary deployments and automated rollback.
Build abstractions for developers. Developers should not write Kubernetes YAML. Give them a platform that translates intent into infrastructure.
Run stateful services externally. Use managed databases and queues. Let Kubernetes handle what it is best at: stateless workload orchestration.
Invest in observability. Kubernetes adds complexity. That complexity requires better monitoring, logging, and tracing to remain manageable.

Closing thought

Kubernetes is a powerful tool. But powerful tools require a solid foundation.

That foundation is architecture: clear service boundaries, well-defined contracts, operational standards, and deployment practices that make the system safe to change.

Without that foundation, Kubernetes gives you faster container orchestration on top of the same problems you were trying to solve. With it, Kubernetes becomes a genuine force multiplier.

Architecture first. Orchestration second.