mkdev — DevOps and Cloud Native Consulting

Is Kubernetes an Engineering Choice or a Must | 🎙️#66

Illustration for "DevOps Accents Episode 66" with a vintage microphone tied with an orange cloth and a laptop showing "<3". Text reads "Is Kubernetes an engineering choice or a must" on an orange background.
Last updated: | Published:

In this episode of DevOps Accents, Kirill previews for Leo his speech for DevOps Pro Europe 2026. He examines the rise of Kubernetes as a near-requirement in tech—for both organizations and professionals—and why its dominance has surprisingly little to do with scaling, microservices, or capacity concerns. Also in this conversation:

  • How to become a public speaker?
  • When not to use Kubernetes?
  • Do we need to talk about GitOps?

You can listen to episode 66 of DevOps Accents on Spotify, or right now:

The End of the Kubernetes Debate

Kirill opens the discussion with a statement that may surprise some: Kubernetes is no longer a technology choice. After more than a decade since its release, Kubernetes has evolved from being an innovative container orchestration platform to a default industry standard. In Kirill’s view, every DevOps engineer now has Kubernetes experience — not because they chose it, but because it’s simply everywhere.

That ubiquity, however, creates new challenges. Many companies, especially those relying on native cloud tooling or serverless solutions, now struggle to hire engineers who don’t expect to use Kubernetes. Conversely, DevOps professionals who specialized in serverless tools like AWS Fargate, Cloud Run, or ECS often find it harder to get hired because the market assumes Kubernetes proficiency.

When Not to Use Kubernetes

Despite its dominance, Kirill cautions startups against adopting Kubernetes too early. For small teams—those with fewer than 100 employees—the complexity overhead often outweighs the benefits. Even with managed solutions like Google’s Autopilot or AWS EKS Auto Mode, Kubernetes still demands operational expertise and developer familiarity.

His advice is simple: if you’re still experimenting and iterating fast, use cloud-native PaaS tools like Cloud Run or similar services. Save Kubernetes for when your team grows large enough to handle it responsibly.

Terraform: The Real Safe Bet

If Kubernetes has become unavoidable, Terraform has become indispensable. Kirill recalls using Terraform almost since its 2014 release and now considers it the safest long-term bet for infrastructure as code. He encourages teams to rely on plain Terraform—without wrappers like Terragrunt—before introducing complexity.

Even with AI coding tools now assisting with Terraform syntax, the ecosystem’s strength lies in its maturity and community modules, which often represent best practices out of the box.

Keeping Kubernetes Simple (and Why That Matters)

Leo, speaking as DevOps Accents’ host, cites CNCF’s recent findings: teams with simpler Kubernetes setups experience fewer incidents. The difference often comes down to fundamentals—clear ownership, consistent naming, and minimal network complexity.

Kirill agrees, adding that most clusters now run in the cloud anyway. Using managed Kubernetes in “autopilot” mode lets teams avoid managing nodes and focus on applications. For smaller organizations, this is key: let AWS or Google handle scaling, provisioning, and optimization so engineers can focus on delivery.

He also likens Kubernetes to Ruby on Rails: once you’ve seen one setup, you can navigate another easily because the structure is predictable. That consistency, Kirill argues, is one of Kubernetes’ greatest strengths.

Managed vs. Self-Hosted: The Flexibility Trade-off

The main trade-off, Kirill says, is flexibility. Managed services like EKS Auto Mode or Google Autopilot remove operational burden but may not fit specialized workloads such as GPU-heavy AI systems. When hardware tuning, networking intricacies, or extreme scalability are involved, custom-managed clusters still have an edge.

Yet for the majority of teams, the managed path remains the right one — not because it’s simpler, but because it removes undifferentiated heavy lifting.

GitOps: The Reality Behind the Buzzword

Leo later turns to another popular term — GitOps. While 77% of teams claim to practice GitOps, most simply store configurations in Git and call it a day. Kirill doesn’t hide his skepticism. For him, GitOps isn’t about specific tools like ArgoCD or Flux but about automation and consistency.

“If your Terraform is in GitHub and deployed automatically via Actions,” he says, “that’s already GitOps.” He sees no need for strict definitions — the principle matters more than the label.

What New Engineers Should Know

For those new to DevOps, Kirill offers pragmatic advice: learn the basics of Kubernetes and GitOps, but don’t obsess over trends. What matters most is practical experience. Job descriptions often demand advanced Kubernetes or GitOps knowledge, but what companies actually use varies widely.

His key takeaway? DevOps remains a field where context rules. Some roles mean building CI/CD pipelines; others involve running global Kubernetes clusters. The best engineers, Kirill concludes, are those who adapt to both.

Show Notes: