CLOUD & DEVOPS / KUBERNETES / AKS
Kubernetes Is Not the Architecture
A reminder to solve the system problem before choosing the platform.
Key Insight: Kubernetes answers "how do we run and orchestrate a set of services reliably." It has no opinion on the question that actually determines whether your system works: what should those services be, and how should they talk to each other?
I've reviewed more than one architecture document that lists "Kubernetes" as the answer to "what is our architecture." It isn't an answer. It's an excellent, well-engineered piece of infrastructure that sits underneath an architecture — and treating it as the architecture itself is how teams end up with a beautifully orchestrated system that solves the wrong problem.
The question Kubernetes doesn't answer
Before a single YAML manifest gets written, the actual architecture questions are still open: What are the service boundaries? What data does each service own? How do they communicate, and what happens when one of them is slow or down? What's the consistency model when a business process spans more than one service? These are domain and system-design questions. Kubernetes has nothing to say about any of them — it will happily orchestrate a badly designed distributed monolith just as efficiently as it orchestrates a well-designed one.
Teams that reach for Kubernetes first and design the system second usually discover this the hard way: they have a robust, auto-scaling, self-healing deployment of services that are tightly coupled in ways no amount of orchestration can fix.
What Kubernetes is actually good at
None of this is an argument against Kubernetes — it's one of the best tools available for what it's actually for: scheduling containerized workloads across a cluster, handling failure and restart automatically, scaling workloads based on demand, and giving you a consistent operational model across many services. If you have a genuine need for that — multiple independently deployable services, variable load, a team that needs a consistent deployment interface — it's a strong choice.
The problem isn't the tool. It's reaching for it as a default before asking whether the problem needs it.
When Kubernetes is solving a problem you don't have
A surprising number of systems that adopt Kubernetes would be simpler, cheaper, and more reliable as a well-structured monolith on a managed platform, or a handful of managed services (a container app, a managed database, a queue) with no cluster to operate at all. The operational cost of running Kubernetes well — cluster upgrades, node management, networking, RBAC, observability for the platform itself — is real and ongoing. It's worth paying when the system genuinely needs the orchestration. It's an expensive way to run three services that talk to one database.
Ask honestly: do we have enough independently scaling, independently deployable components that we need this? Or are we adopting Kubernetes because it's the default answer in this industry right now?
Design first, choose the platform second
The healthier order is: define the bounded contexts and their boundaries, define how they communicate and what happens under failure, define the data ownership model — and only then choose the platform that runs it well. Sometimes that's Kubernetes. Sometimes it's a simpler managed container platform. Sometimes the right architecture doesn't need orchestration at all.
Key takeaways
Kubernetes is infrastructure, not architecture — it has no opinion on service boundaries, data ownership, or failure handling. Design the system first: what are the components, how do they communicate, who owns what data. Choose Kubernetes because the system's actual shape needs it, not because it's the default. A well-orchestrated bad design is still a bad design.