Aliaksei Shybeka, DevOps/Platform Engineer, Coherent Solutions
Kubernetes remains the dominant orchestration platform, but the ecosystem around it has matured. Cloud providers now offer simpler alternatives that cover most use cases without requiring teams to manage clusters, networking, upgrades, and operational complexity. The result is an interesting shift: Kubernetes is still the right answer for many organizations, but it is no longer the first answer. This is a shift I see firsthand, managing EKS across 40+ AWS accounts. The question isn’t whether Kubernetes can do the job, but whether it’s the right tool for this one.
Kubernetes is no longer the default choice
Depends on where you work. In the AWS ecosystem, not really. ECS with Fargate handles containers without touching servers. Elastic Beanstalk deploys Node.js applications from a git push with zero Docker knowledge. Lambda covers event-driven workloads. For most Node.js services, these tools are enough. If it’s a proof of concept or a two-person startup, plain Docker or Podman is fine early on.
No orchestration needed at all. Kubernetes starts to make sense once you have a complex multi-service architecture and need fine-grained orchestration control. Otherwise, it’s just operational overhead nobody asked for.
The real question: expertise, not size
If you’re weighing self-managed versus managed Kubernetes, it’s less about project size and more about expertise. If your team has enough people who know Kubernetes well, or you simply don’t want to pay for cloud, self-managed works fine, even something lightweight like k3s. If that expertise is missing, go with EKS or a similar managed option and let the provider handle the control plane.
Many clusters and many teams usually push you toward managed too, since you’ll need automation anyway. But it always depends on the product’s requirements: compliance, data location, cost targets. No in-house Kubernetes experts? Don’t run it yourself.
What Kubernetes got right
The most value came from the declarative model and self-healing. You describe the desired state, and the cluster maintains it. Add service discovery, ConfigMaps, Secrets, and rolling deployments, and you have the core reason people adopt Kubernetes in the first place.
In my current work at Coherent Solutions, this shows up as the difference between “a pod crashed and nobody noticed” and “a pod crashed and someone has to fix it manually.” On a large ArgoCD-managed fleet, that difference is the whole point: most failures get remediated before they ever reach a person.
Where Kubernetes became too complex
Network abstractions like CNI and network policies often get labeled unnecessary complexity. I disagree. When you have hundreds of ephemeral microservices, manual network management isn’t an option. That complexity reflects the problem, not the tool.Where complexity is genuinely excessive, even at the right scale: YAML has no typing and no real composition, so the ecosystem compensates with Helm, Kustomize, and Jsonnet. Each fixes a symptom and adds a layer. CRD and operator sprawl hits you during cluster upgrades, when operator versions conflict and each brings its own reconciliation logic, and that debt accumulates quietly. RBAC in multi-tenant setups works until it doesn’t, and when it breaks, it’s hard to trace. Running Kubernetes for a monolith makes the whole thing unnecessary. But that’s a tool selection problem, not a complexity problem.
The hard problems are still hard
The hardest one I’m dealing with right now is multi-cluster networking: one cluster in EKS, another on-prem, a third in AKS or a different AWS account, and you want a single entry point with global service discovery across all of them. Options like Consul, HAProxy, or Istio exist, but each comes with its own trade-offs. Still figuring this one out. CNI choice is also genuinely hard. Calico, Cilium, different VPC plugins: each behaves differently under load, and debugging network issues across them is painful.
Best practices that actually hold up
Limit RBAC aggressively. Not everyone needs cluster-admin. Someone with too much access can accidentally misconfigure a service and lock out the API server. Least privilege isn’t paranoia, it’s basic hygiene. GitOps over manual changes. Every resource creation, update, or deletion goes through a PR and a process. ArgoCD or Flux, doesn’t matter. The principle is what counts: cluster state lives in git, not in someone’s terminal history.
External secrets management. Don’t manage secrets manually in the cluster and never put them in git or YAML. Use something like External Secrets Operator to sync from Vault or AWS Secrets Manager. The secret still ends up as a Kubernetes Secret in etcd, but you get a single source of truth, proper rotation, and an audit trail. If you want secrets encrypted at rest in etcd, that’s a separate step you need to enable explicitly. Tag your cloud resources. Not Kubernetes labels, those are technical. Cloud-level tags tell you who owns what, why it exists, and who gets the bill.
GitOps and Platform Engineering changed the job
GitOps shifted cluster management from imperative to declarative. Every change goes through git, and ArgoCD or Flux reconciles the state. No more kubectl apply from someone’s terminal. The cluster state becomes auditable, reviewable, and reproducible.
Platform Engineering took it further. Instead of every team learning Kubernetes from scratch, a dedicated platform team builds internal tooling that hides the complexity. Developers get a “rail”: push code, get a deployed service. Kubernetes becomes an implementation detail. This space now has dedicated products: Backstage, Port, and Cortex are building internal developer portals. I haven’t worked with them deeply yet, but they’re clearly where the market is moving.
Would I choose Kubernetes again?
Yes. Not because it’s the simplest option, but because I like complex problems, and Kubernetes is where the interesting ones live.
For simple workloads, AI-assisted automation makes lighter tools good enough now: ECS, Lambda, a couple of scripts, and you’re done. But if you’re building something with real scale (multiple teams, hundreds of services, cross-cluster networking challenges), Kubernetes is still the only serious answer. The ecosystem is mature, the community is huge, and the hard problems are at least well documented.
I’d choose it again. Just not on day one of a two-person startup.
