There is no software delivery without DevOps, and rightly so. But here’s something we often forget: engineers were automating deployments, managing infrastructure, and streamlining operations long before we had a name for it. These practices emerged from solving real problems with whatever tools made sense. Today, though, we often work backwards – starting with solutions and looking for problems they might solve.
“We need a DevOps team to implement Kubernetes – one architect and two engineers.”
Sound familiar? This request pops up everywhere, and at first glance, it makes sense. But this request perfectly captures how we’ve shifted from solving problems to adopting solutions.
The tech industry has gotten really good at selling solutions. Beyond the companies like HashiCorp and Red Hat pushing their tools, you’ve got the cloud giants – AWS, Azure, and Google Cloud – all with their own agenda. Their embrace of open-source technologies like Kubernetes isn’t purely altruistic. They want you in their ecosystem, using their managed services, their infrastructure, their whole platform.
What starts as “free” or “industry standard” quickly leads to real costs through related services, specialized infrastructure, and managed options. Before you know it, you’re locked into an ecosystem that’s far more complex – and expensive – than what you actually needed.
When organizations adopt sophisticated DevOps tooling, they rarely see the full picture. Let’s stick with our Kubernetes example:
The Plus-One Problem: You can’t just have Kubernetes. You need service mesh tools to manage communication between services. You need monitoring solutions to figure out what’s going on in your clusters. You need security tools to keep everything locked down. Each new tool brings its own complexity, and suddenly your “simple” container orchestration solution isn’t so simple anymore.
The Expertise Premium: Kubernetes specialists aren’t cheap, and you’ll need more than one. This knowledge tends to get stuck in small teams, creating bottlenecks that can slow down your entire operation. And good luck hiring – you’re competing with tech giants for the same pool of talent.
The Learning Curve: When you bring in these new tools, your whole team needs to change how they work. During this transition – which often drags on for months – everything slows down while people learn new concepts, new workflows, and new ways to fix things when they break.
The Complexity Tax: More sophisticated tools mean more things can go wrong in more complicated ways. What used to be a simple deployment rollback turns into a complex dance across multiple systems. Each layer of sophistication adds another layer of potential failure points.
Let’s look at this pragmatically; what do organizations actually need?
Often, these needs don’t require a full container orchestration platform. Some solid automation scripts, basic monitoring, and clear documentation might give you most of what you want without the complexity. And yes, sometimes Kubernetes is exactly what you need – but that decision should come from analyzing your actual problems, not from following the crowd or vendor marketing.
Let’s explore how this plays out in practice:
When a company says they need Kubernetes to modernize, the real conversation should start with: What’s actually painful about your current setup? Often, the core issues – slow deployments, inconsistent environments, scaling difficulties – can be solved with simpler solutions that don’t require retraining your entire team or restructuring your organization.
Sometimes the same request comes from an organization already using Kubernetes. They need help optimizing and scaling what they have. Here, the conversation shifts to making what they’ve already invested in work better. The answer might not be adding more DevOps engineers – it might be improving documentation, streamlining processes, or better tooling around their existing setup.
The most interesting scenario is when an organization is starting fresh with DevOps. No existing commitments, no technical debt – just current problems that need solving. This is where engineering thinking can really shine. Instead of defaulting to industry-standard tools, we can start with the basic questions: What problems are we solving? What’s the simplest way to solve them? What can we comfortably maintain?
This isn’t about avoiding modern tools. It’s about remembering why we automate things in the first place – to solve real problems. Before jumping into any solution, ask the basic questions: What’s actually broken? What’s the simplest way to fix it? What’s this solution really going to cost us? How will we know if it’s working?
The fanciest solution isn’t always the right one. Good engineering is about finding the simplest solution that actually solves your problem. In an industry that pushes complexity at every turn, sometimes the most radical thing you can do is keep it simple.
Remember: tools and practices don’t drive successful delivery – engineers solving real problems do. Everything else is just marketing.
