September 23rd, 2019. The world has just shifted in a way I hadn’t expected. Kubernetes is everywhere—every team wants to run their apps on it, but the complexity is starting to show its teeth. I’ve been grappling with this myself over the past few months as our platform engineering team tackles the challenge of making Kubernetes work for everyone.

Let’s start with some context: back in 2019, we were just beginning to see the signs that Kubernetes was becoming a tool so complex that it required specialized knowledge to use effectively. It wasn’t a simple “just install and run” kind of deal anymore. The learning curve was steep, and the configuration options seemed endless.

One day, I found myself knee-deep in an argument about the best way to handle secrets management in our platform. We had a few different approaches, but none of them felt quite right. Should we use Kubernetes Secrets? Helm charts with encrypted values? A homegrown solution using HashiCorp Vault?

After much debate, I decided to stick with native Kubernetes Secrets for simplicity’s sake. But the complexity didn’t end there. Our team was already facing challenges around managing stateful applications, persistent storage, and networking policies. Adding secrets management on top of that made our lives more complicated.

It hit me: this wasn’t just about implementing Kubernetes; it was about building a sustainable platform where everyone could focus on their actual work—writing code, not wrestling with infrastructure.

This realization led to a series of conversations within the team. We started talking about ways to simplify things, reduce overhead, and make sure that deploying applications didn’t become a Kafkaesque ordeal. Enter internal developer portals like Backstage: our way to centralize documentation, provide easy access to tools, and give teams the information they need without overwhelming them.

But then came the unexpected: remote work was about to take over our lives. With the specter of a global pandemic looming, companies started making the shift to fully remote infrastructures almost overnight. As we prepared for this change, it became clear that our platform needed to support not just distributed teams but also the challenges they brought—networking issues, slower internet connections, and the like.

In response, we leaned more heavily into eBPF. The ability to instrument and debug at the lowest levels of the stack looked promising, especially for network and storage performance monitoring. We started experimenting with it, and while it wasn’t a panacea, it gave us new tools to tackle some tough problems.

At the same time, I found myself grappling with ArgoCD and Flux GitOps. Both were gaining traction as ways to automate application deployment and keep our clusters in sync. As much as we wanted these tools, integrating them into our existing infrastructure was no small feat. We had to carefully weigh their benefits against the complexity they added.

Looking back at that month, it’s clear how much technology can change in just a few weeks. What seemed like an endless debate over secrets management now feels quaint compared to the broader challenges we face today. But amidst all the chaos, there was this underlying theme: as infrastructure becomes more complex, our job is to find ways to simplify things for the people who need them.

That’s what I’ve been thinking about as September 23rd draws to a close. How can we make Kubernetes work better? How do we balance the benefits of automation with the realities of human complexity? And most importantly, how do we ensure that everyone on our team—whether they’re writing code or deploying applications—is focused on what matters?

These are the questions I’ll be asking myself as we move forward. The era of Kubernetes complexity fatigue has arrived, and it’s up to us to figure out how to navigate it.

---

That’s where my reflection left off that day. Looking back, I still find myself thinking about these challenges and the journey our team continues on today.