Why Kubernetes Is Probably Wrong for Your Mid-Sized Company

Tap, tap, tap. Is this thing on? Welcome back to Engineering Evolved. I know I've had a week off. Um, bit of travel for work and then a bit of vacation.

So good to have you all back. I'm gonna say something that might get me a few... Well, get me uninvited from a few DevOps meetups. For most mid-size companies, Kubernetes is probably the wrong choice. Not because it's bad technology.

It's generally genuinely impressive engineering that came out of Google's Borg system. But here's the thing, you're not Google, and neither am I, and when we pretend otherwise, we create maintenance m- nightmares, burn out our teams, and spend money solving problems we don't actually have. And so today, I'm gonna help you figure out if you actually need Kubernetes, and spoiler alert, the answer is probably no. [upbeat music] Welcome to Engineering Evolved, where business meets innovation and technology drives transformation. Each episode, your host, Tom Barber, explores the challenges and opportunities facing the organizations in the middle, the forgotten ground where startup rules no longer apply and enterprise playbooks are far too large.

From scaling systems and leading teams to aligning engineering with business goals, this is where practical insight meets real-world experience. Engineering Evolved, guiding today's leaders through the evolution of engineering. So like I said, welcome to Engineering Evolved, the podcast for engineering leaders at mid-size companies who are tired of getting the advice that only works for startups or enterprises. I'm your host, Tom Barber, and this is episode number 12. If you caught the previous episode on platform engineering for mid-size companies, you'll know that I'm pretty opinionated about the build versus buy decision for infrastructure.

Today, we're drilling into one specific technology, and I, I think has become the default answer to questions nobody's asking, which is Kubernetes. I saw a LinkedIn post recently where someone was genuinely... Why can't I say that word tonight? Genuinely arguing that SSH-ing into a VM to deploy your application was outdated, and you should use more modern tooling, air quotes. And look, the argument that you should adopt technology because it's shiny and new has been raging since the dawn of computing.

But when I read this, when I read through the comments and realized this person wasn't joking, that's when I knew we needed to have this conversation. So today, I'm gonna give you an honest assessment, not a vendor pitch, not the resume-driven hype, just practical look at when Kubernetes makes sense and when it absolutely doesn't for companies your size. But first, a word from our sponsors. Why hire when you can partner? Concept Cloud's leading engineers build your startup's prototype without the overhead.

Launch faster. conceptcloud. com. Okay. Let me tell you about the time I got this wrong.

Not the only time, but the one that will fit into this story. Back when I was working at NASA, I was part of a team building a data platform. We were processing flight data that had a hard requirement. Scientists needed that data in their hands within thirty minutes of it reaching Earth. Not a nice to have, a hard SLA.

Now, this was a small team, and somewhere along the way, we decided to deploy this thing into Kubernetes. Production Kubernetes cluster. All the YAML, all the complexity, the full experience. Was it resume-driven development? No, actually.

It wasn't that cynical. We generally liked working with the shiny new technology, and Kubernetes at the time was interesting. It was challenging. It gave us problems to solve that felt satisfying. But here's the question we never asked ourselves.

Did we actually need it? We had a small team. We had a specific well-defined workload. We had a clear SLA. And we chose the most complex cluster container organizat- orchestration platform available because we enjoyed it.

Now that's, I admit in hindsight, not a good reason. The maintenance burden of running a production Kubernetes cluster, the upgrades, security patches, config drift, the YAML management, none of that was serving our mission. It was overhead. And when team dynamics shifted, when people moved to other projects, the overhead became a real problem. If I could go back, I'd run that workload on a VM with a Docker container, maybe two VMs for redundancy.

Simple deployment script. All done. So when I talk about Kubernetes being overkill, I'm not speaking from theory. I've lived this mistake more than once, and I've spent time since then helping other teams avoid making the same one. All right.

Let's start with some context because I think understanding where Kuberneti- Kubernetes came from helps explain why it might not be right for you. So Kubernetes spun out of Google. Specifically, it was inspired by Borg, of all names, Google's in- internal cluster management system that was de- that was dealing with, well, Google's scale deployments. We're talking about a system designed to manage containers across tens of thousands of machines handling workloads for billions of users. If that context doesn't tell you what Kubernetes is good at, nothing will.

At its core, Kubernetes takes Docker images and a lot of YAML descriptors to deploy your applications into a cluster of machines- The cluster then manages your containers, your networking, ingress, egress, permissions, the work. And in the right context, this is genuinely powerful. It can provide fault tolerance, auto-scaling, auto-healing, declarative infrastructure where you describe the state you want and Kubernetes works to maintain it. Self-healing, rollbacks on failure, consistency across environments. And that sounds absolutely amazeballs, right?

The problem is most of these benefits require significant investment to actually realize. And for midsize companies, the two hundred to one thousand employee range, that investment rarely pays off. And I'm talking about working at NASA with like, you know, tens of thousands of staff distributed across different sites and people from around the globe interacting with this platform. I'm still telling you the investment didn't pay off. Here's a question I want to s- to s- I want you to sit with.

What problem are you actually trying to solve, and can you solve it by doing less? If the answer is yes, I can solve this with lex- less complexity, then you should do less every time. Let's talk about the downsides because this is where the vendor pitches get quiet. First, complexity. Kubernetes is genuinely, legitimately complex.

Sure, every cloud vendor has their hosted solution, EKS, GKE, AKS, and there are vendors offering support for their Kubernetes variants if you'd rather deploy elsewhere. But that doesn't mean it's easy to wrap your head around. Azure has tried to wrap Kubernetes in Azure App Service to make it easier to deploy apps. AWS just launched EKS Auto Mode to reduce the management burden. They all know it's hard work.

Even the vendors, the vendors are building products to hide Kubernetes from you. That should tell you something. Cluster security, cluster upgrades, managing your pods, and if you're self-hosting, your VM also needs patching and remediation. It all requires planning and forethought on top of your actual application work. Second reason, YAML everything.

The majority of Kubernetes is driven by YAML in some form. Sometimes simple, often not. But here's the real issue. How do you deal with the change requests, the version control, the config drift, different people applying policies? All of this requires careful management, and honestly, it's not really a technical problem.

It's a people and process problem. Do you have the bandwidth to manage it? For most midsize companies, the answer is likely no. Third, cost at smaller scales. This manifests itself in multiple ways.

The additional complexity means more engineering hours. You've got more nodes, a control plane. Sure, it may be free from your cloud vendor, but you're paying for it somewhere. More infrastructure for ingress. It all adds up.

And I'm not just talking about hosting costs. People jump straight to that number. But when you've got a platform as complex as Kubernetes, what's the human cost, both in money, raw time that could be spent building features, but also just developers and infrastructure staff mental health? Fourth, developer experience. You can, if you're particularly masoch- masochistic, run Kubernetes on a local machine.

But this still requires the same YAML setup, the same config tweaking, the same maintenance burden. It can be useful for debugging cluster issues, but in practice, it's not developer friendly. It's not fast. It's not easy. You know, there's, there's a high barrier to entry there.

Your developers want fast feedback loops. They want to write code, run it, see the results. And Kubernetes one hundred percent adds friction to that loop. Fifth is the portability mirage. And this one gets me because Kubernetes is supposed to offer universal configuration across cloud providers.

In practice, it often doesn't work out this way. You still need deep understanding of your vendor's networking ingress options, available storage types. When you deploy storage, do you need slow disks, cheap disks, high performance IO? Maybe both. Maybe all of the things.

How do you pick them? And how do you configure your setup to use them correctly? Each cloud provider has its own opinions, its of... its own defaults, its own quirks. The promised portability often requires significant work to actually achieve.

Now, I've been pretty negative, so let me be fair. There are genuine upsides to Kubernetes, and there are situations where it makes sense. 'Cause whilst I've just said negative things about it, the portability is real, just not as seamless as advertised. You can deploy Docker containers into almost any environment, on-prem, any cloud, Raspberry Pis. Like you can run it anywhere.

The core product probably doesn't need changes, and developers can run the same containers locally with Docker Desktop or Podman, and so that flexibility has real value. The declarative infrastructure, the thing that makes Kubernetes hard to manage from a process perspective, is also a positive. Once you've described the state you want, Kubernetes works to maintain it. Self-healing, rollbacks on failure, consistency across environments. When it works, it works well.

The ecosystem, of course, there's a rich collection of additional services and tools. Argo for application management. Flux CD I think has like been resurrected from the dead. Prometheus for monitoring out of the box. The, the ecosystem can both help and hinder, but there's genuine, genuine value there if you need it.

Resource isolation. Kubernetes provides multi-tenancy patterns, RBAC roles, network boundaries. These can be hard to configure and maintain, but they do exist. Extensibility, of course, is there if Kubernetes can't do what you want. The operator flame framework and various other API extensions have been standardized for years and allow you to extend it to your heart's content.

Deployment patterns, rolling updates, canary releases, blue-green deployment, these are all doable, though I'd ask, do you actually need blue-green releases or did you just read about them and think they sounded cool? Most organizations don't need blue-green releases. They just need to schedule the release at a sensible time. Observability hooks. One of the biggest problems with containers is knowing what's happening inside.

Kubernetes provides hooks for logs, metrics, traces. Standards like OpenZipkin have really grown this ecosystem. So when does this all add up to yes, use Kubernetes? It's when you have genuine scale requirements, when you're running dozens or hundreds of services across multiple teams, when you have dedicated platform engineering capacity to manage it, when the complexity serves a real business need. For most mid-sized companies, that's not where you are, and pretending otherwise doesn't help anyone.

And now a word from our sponsors. The same minds that worked on the last Mars rover now work on yours. Concept to Cloud builds startup MVPs that perform. Concept2cloud. com.

Okay, we're back. Let's roll on to the alternatives. So if not Kubernetes, then what? And this is the million-dollar question. Sometimes quite literally.

Start with the simplest thing that could work. If you can solve your problem by spinning up a VM and running a process on it, even if that processor-- process sits inside of a Docker container for convenience, and I'm not suggesting you don't use Docker containers, then you probably should. VMs are boring. Boring is good. Boring is maintainable.

Boring lets you ship features instead of fighting the infrastructure. You got managed container services. AWS has ECS and Fargate. Google has Cloud Run. Azure has App Service and Container Apps.

These give you container benefits without the cluster management overhead. You describe what you want to run, they figure out where to run it. And of course, there's serverless for appropriate workloads as well. Lambda, Cloud Functions, Azure Functions. For event-driven bursty workloads, serverless can be dramatically simpler than managing containers yourself.

Docker on VMs, and this is my default recommendation for most mid-sized companies. You're getting the container portability, reproducible builds, easy local development, but you deploy to a VM you can SSH into, update, and understand. Write simple deployment script, use Ansible or Terraform if you want infrastructure as code. It is done. So here's a thought experiment.

What would it cost more to package your app as a Docker container and then write a separate deployment script for each cloud provider's basic application deployment than to manage a Kubernetes cluster? Because in most cases, the answer to that question is no. The deployment scripts are simpler, the maintainan- maintenance burden is lower, and you can always migrate to Kubernetes later if you genuinely need it. You're not locked in. You're not cutting off options.

You're just choosing appropriate complexity for your current scale. So how do you decide? How do you actually make this decision for your organization? I've put together a checklist that I'm calling the Do You Actually Need Kubernetes checklist, and you can download it from the show notes. But let me walk you through the key questions.

First, what problem are you actually solving? Not what technology do you want to use? What actual business problem? If you can't articulate a specific problem that Kubernetes solves better than simpler alternatives, you have your answer. Second, do you have the team?

Kubernetes requires ongoing care, upgrades, security patches, configuration management. If you don't have at least one person who can dedicate significant time to cluster operations, you're setting yourself up for trouble. Third, what's your scale? If you're running fewer than ten services, if you have a single team managing deployments, if your traffic patterns are predictable, you probably don't need Kubernetes. Fourth, what's your deployment frequency?

If you're deploying once a week or less, the phys-- the sophisticated deployment patterns Kubernetes enables aren't buying you much. Fifth, have you exhausted simpler options? Can you use managed services? Can you run on VMs? Can you use your cloud provider's container platform without managing the orchestration layer yourself?

If the answer is no to most of these and you're still considering Kubernetes, I'd ask you to honestly examine why. Is it solving a real problem or do, does it just feel like what a real engineering team should be using? So look, I know there's a lot to process and every organization is different. The right infrastructure choice, choice depends on your specific context, your team, your scale, your constraints, and your goals. If you're wrestling with this decision whether to adopt Kubernetes, how to simplify your existing infrastructure, or how to modernize without creating new maintenance nightmares, this is exactly what I help companies figure out with through my consultancy, Concept to Cloud.

I work with engineering leaders at mid-size companies to cut through the hype and make pragmatic infrastructure decisions. No vendor agenda, no resume-driven recommendations, just practical guidance based on what actually works. If that sounds valuable, head over to www. conceptocloud. com and let's have that conversation about your specific situation.

And don't forget to download the Do You Actually Need Kubernetes checklist from the show notes. It's a simple decision framework you can use with your team to have an honest conversation about whether Kubernetes is right for you. So there we go. If you found this episode valuable, I'd really appreciate it if you'd share it with another engineering leader who might be facing the same decision. And if you have a Kubernetes story, whether it's a success or a cautionary tale, I'd love to hear it.

Find me on LinkedIn or send me an email, tom@conceptocloud. com. Your experiences help shape future episodes. Next week on Engineering Evolved, we're shifting gears to talk about something every engineering leader struggles with, why your engineers and product managers still don't talk to each other and how to actually fix it. It's episode thirteen, and I've got some strong opinions about the rituals that work and the ones that don't.

Thanks for tuning in. I'll see you then. [upbeat music] Thanks for listening to Engineering Evolved with Tom Barber, where ideas meet innovation and leadership drives change. If you enjoyed today's episode, please leave a rating and review wherever you listen. It helps more leaders discover the show and keeps the evolution moving forward.

From idea to investor demo in weeks, not months. Concept to Cloud, world-class engineers accelerating startup success. Concepttocloud. com.