Title: Kubernetes Complexity Fatigue and the Art of Minimalism

---

August 10, 2020. It’s been a while since I’ve sat down to write this, but today feels like as good any day to share some thoughts on something that’s been on my mind.

Over the past few months, I’ve noticed a growing trend among developers and engineers: Kubernetes complexity fatigue. The more we layer on features and tools in our Kubernetes setups, the harder it gets to maintain them. It’s like adding more furniture to your already cluttered living room—every new piece makes everything else harder to find and use.

The Backlash

Kubernetes is undeniably powerful, but its initial simplicity has been replaced by a complex ecosystem of controllers, operators, and add-ons. Tools like ArgoCD, Flux GitOps, and eBPF are wonderful in their own right, but they introduce another layer of complexity that can be overwhelming for teams already struggling with the basics.

The Developer Portal

Just as Backstage is trying to solve, we need better ways to manage our infrastructure and services. At my current company, we’ve been exploring how to build an internal developer portal that aggregates all these tools into a single interface. But it’s not just about putting everything in one place; it’s also about ensuring that the portal itself doesn’t become a monolith of its own.

eBPF and the SRE Role

eBPF is gaining traction, but I’ve found myself questioning whether we should be pushing too hard for every service to have an eBPF program. It’s powerful, yes, but it adds another layer of complexity that might not always be necessary. The same goes for SRE roles. While they can bring a new perspective, sometimes the benefits are outweighed by the overhead.

The Zoom Calls and Virtual Lunches

COVID-19 has driven us to scale remote infrastructure like never before. We’ve had to get really good at managing distributed teams, but the downside is that every meeting or virtual lunch seems to require another tool. Slack, Teams, Zoom—there’s a reason why people sometimes just send an email instead.

Factorio: A Metaphor for Kubernetes

In my free time, I’ve been playing Factorio. For those unfamiliar, it’s a game where you build and manage a factory. Initially, the complexity can be overwhelming as you start by building simple machines and then layer on more advanced ones. But as you progress, you realize that simplicity is often better than over-engineering.

The Ask HN Thread

The other day, I read through an Ask HN thread about why Reddit’s mobile app was so obsessed with making people use it instead of the web version. It made me think: are we doing the same thing with our Kubernetes setups? Are we building overly complex solutions because that’s what everyone else is doing?

The Learning Experience

This month, I’ve been refactoring a particularly hairy deployment script. It started out simple but over time had grown to 200 lines of code, filled with conditionals and exceptions. After much debate with myself, I decided to boil it down to its core: just enough logic to get the job done. The result was a 15-line bash script that’s easier to maintain and less prone to bugs.

Embracing Minimalism

In conclusion, as we continue to navigate the complexities of modern infrastructure, let’s not lose sight of the simple solutions. Sometimes, it’s better to do one thing really well than to try and do everything. As an engineer, I’m learning that embracing minimalism can often lead to cleaner, more maintainable systems.

---

That’s my take for now. What are your thoughts on Kubernetes complexity fatigue? Feel free to leave a comment below or hit me up on Twitter. Let’s keep this conversation going!