Why Kubernetes Is Probably Wrong for Your Mid-Sized Company

WEBVTT
1
00:00:00.300 --> 00:00:10.560
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.
2
00:00:10.800 --> 00:00:22.260
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.
3
00:00:22.380 --> 00:00:28.040
It's generally genuinely impressive engineering that came out of Google's Borg system.
4
00:00:28.600 --> 00:00:40.920
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.
5
00:00:41.020 --> 00:00:49.300
And so today, I'm gonna help you figure out if you actually need Kubernetes, and spoiler alert, the answer is probably no.
6
00:00:51.440 --> 00:01:01.260
[upbeat music] Welcome to Engineering Evolved, where business meets innovation and technology drives transformation.
7
00:01:02.040 --> 00:01:16.640
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.
8
00:01:17.020 --> 00:01:27.060
From scaling systems and leading teams to aligning engineering with business goals, this is where practical insight meets real-world experience.
9
00:01:27.140 --> 00:01:32.460
Engineering Evolved, guiding today's leaders through the evolution of engineering.
10
00:01:34.380 --> 00:01:45.900
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.
11
00:01:45.960 --> 00:01:48.980
I'm your host, Tom Barber, and this is episode number 12.
12
00:01:50.020 --> 00:01:58.890
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.
13
00:01:59.760 --> 00:02:15.540
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...
14
00:02:15.720 --> 00:02:25.720
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.
15
00:02:26.580 --> 00:02:33.520
And look, the argument that you should adopt technology because it's shiny and new has been raging since the dawn of computing.
16
00:02:34.300 --> 00:02:43.520
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.
17
00:02:43.720 --> 00:02:56.460
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.
18
00:02:56.500 --> 00:03:12.940
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.
19
00:03:13.380 --> 00:03:24.120
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.
20
00:03:24.220 --> 00:03:36.600
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.
21
00:03:37.140 --> 00:03:48.740
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.
22
00:03:50.060 --> 00:04:01.060
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.
23
00:04:01.100 --> 00:04:14.820
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.
24
00:04:15.230 --> 00:04:28.290
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.
25
00:04:28.320 --> 00:04:39.580
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.
26
00:04:40.230 --> 00:04:53.400
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.
27
00:04:53.520 --> 00:05:01.580
Simple deployment script. All done. So when I talk about Kubernetes being overkill, I'm not speaking from theory.
28
00:05:01.720 --> 00:05:11.660
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.
29
00:05:12.100 --> 00:05:24.300
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.
30
00:05:24.420 --> 00:05:37.280
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.
31
00:05:37.560 --> 00:05:51.060
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.
32
00:05:51.820 --> 00:06:07.116
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.
33
00:06:07.216 --> 00:06:21.356
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.
34
00:06:22.156 --> 00:06:38.876
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.
35
00:06:39.056 --> 00:06:45.156
And for midsize companies, the two hundred to one thousand employee range, that investment rarely pays off.
36
00:06:45.606 --> 00:06:53.976
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.
37
00:06:54.056 --> 00:07:08.136
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?
38
00:07:09.436 --> 00:07:25.356
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.
39
00:07:26.056 --> 00:07:32.676
First, complexity. Kubernetes is genuinely, legitimately complex.
40
00:07:33.356 --> 00:07:45.236
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.
41
00:07:46.316 --> 00:08:00.096
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.
42
00:08:00.116 --> 00:08:09.435
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.
43
00:08:10.656 --> 00:08:25.046
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.
44
00:08:26.476 --> 00:08:37.016
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.
45
00:08:37.476 --> 00:08:50.036
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.
46
00:08:50.686 --> 00:09:05.736
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.
47
00:09:06.376 --> 00:09:18.436
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.
48
00:09:18.696 --> 00:09:24.176
It all adds up. And I'm not just talking about hosting costs. People jump straight to that number.
49
00:09:24.256 --> 00:09:38.345
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?
50
00:09:40.296 --> 00:09:56.136
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.
51
00:09:56.216 --> 00:10:05.616
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.
52
00:10:05.876 --> 00:10:18.776
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.
53
00:10:19.436 --> 00:10:28.926
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.
54
00:10:30.446 --> 00:10:41.916
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.
55
00:10:42.076 --> 00:10:53.536
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.
56
00:10:53.916 --> 00:11:08.296
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.
57
00:11:08.726 --> 00:11:23.416
'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.
58
00:11:23.536 --> 00:11:37.856
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.
59
00:11:39.226 --> 00:11:50.316
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.
60
00:11:50.576 --> 00:12:03.576
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.
61
00:12:03.676 --> 00:12:18.712
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.
62
00:12:19.032 --> 00:12:33.971
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.
63
00:12:34.452 --> 00:12:42.432
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.
64
00:12:44.952 --> 00:12:56.572
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?
65
00:12:57.292 --> 00:13:08.692
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.
66
00:13:09.132 --> 00:13:23.012
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?
67
00:13:25.212 --> 00:13:27.452
It's when you have genuine scale requirements,
68
00:13:28.532 --> 00:13:39.892
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.
69
00:13:40.992 --> 00:13:56.072
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.
70
00:13:56.632 --> 00:14:13.832
Concept to Cloud builds startup MVPs that perform. Concept2cloud.com. Okay, we're back.
71
00:14:14.472 --> 00:14:26.632
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.
72
00:14:26.752 --> 00:14:39.992
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.
73
00:14:40.732 --> 00:14:55.932
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.
74
00:14:56.372 --> 00:15:10.032
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.
75
00:15:11.032 --> 00:15:23.272
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.
76
00:15:25.092 --> 00:15:33.972
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,
77
00:15:35.612 --> 00:15:50.532
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.
78
00:15:50.932 --> 00:16:02.152
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?
79
00:16:03.092 --> 00:16:14.772
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.
80
00:16:15.072 --> 00:16:28.612
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?
81
00:16:28.932 --> 00:16:38.952
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,
82
00:16:40.072 --> 00:16:47.182
what problem are you actually solving? Not what technology do you want to use? What actual business problem?
83
00:16:47.812 --> 00:16:57.172
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?
84
00:16:57.712 --> 00:17:02.852
Kubernetes requires ongoing care, upgrades, security patches, configuration management.
85
00:17:02.992 --> 00:17:13.412
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?
86
00:17:14.052 --> 00:17:26.352
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?
87
00:17:26.632 --> 00:17:41.342
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?
88
00:17:41.392 --> 00:17:48.292
Can you run on VMs? Can you use your cloud provider's container platform without managing the orchestration layer yourself?
89
00:17:48.852 --> 00:18:02.692
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?
90
00:18:03.272 --> 00:18:14.552
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.
91
00:18:16.032 --> 00:18:31.272
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.
92
00:18:32.212 --> 00:18:38.712
I work with engineering leaders at mid-size companies to cut through the hype and make pragmatic infrastructure decisions.
93
00:18:38.812 --> 00:18:45.212
No vendor agenda, no resume-driven recommendations, just practical guidance based on what actually works.
94
00:18:48.352 --> 00:19:02.812
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.
95
00:19:02.832 --> 00:19:11.412
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.
96
00:19:11.512 --> 00:19:18.952
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.
97
00:19:18.992 --> 00:19:32.192
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.
98
00:19:34.712 --> 00:19:45.512
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.
99
00:19:46.252 --> 00:19:54.812
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.
100
00:19:55.012 --> 00:20:10.932
[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.
101
00:20:11.442 --> 00:20:25.812
It helps more leaders discover the show and keeps the evolution moving forward. From idea to investor demo in weeks, not months.
102
00:20:25.872 --> 00:20:34.832
Concept to Cloud, world-class engineers accelerating startup success. Concepttocloud.com. [upbeat music]