I love Kubernetes

Let’s get one thing straight right off the bat: I have nothing against Kubernetes 👐

However, I can’t help but find this fascination with technology among engineers a bit suspicious. And I’m an engineer. And I love technology. But technology cannot be an end in itself.

The danger lies in doing things because we can do them, not because we must. The danger lies in technology for technology’s sake, in technological solutionism. See Evgeny Morozov’s excellent book on this subject: To Save Everything, Click Here. This is true in every field, by the way, not just software: “Hmmm, my big missile is so beautiful!” 🚀 It makes you… wonder.

Why is this a danger?

Because technology for technology’s sake leads to unnecessarily complicated solutions, things we don’t need.

Because most of the time, the problem doesn’t even exist: how many companies face enough technical pressure to justify using Kubernetes? Not everyone is Google or Netflix.

Technology for technology’s sake means having the drawbacks of a technology without reaping its benefits. This invariably leads to systems that are difficult to maintain and, ultimately, fragile. It’s better to have a well-built website in vanilla JS than one that uses React in a twisted, convoluted way.

So, why? Why this natural tendency? Don’t worry, I struggle with it too 🤣 Maybe it’s because of an educational system that’s very focused on the “how” rather than the “what” and the “why”—in France, at least.

I notice that the students I mentor (up to the master’s level) are very concerned with proving that they know how to do things. Knowing how to do things is important, but taking a step back is even more so. That step back can save you weeks of work: 5 minutes of reflection versus weeks of work.

Personally, I understand Kubernetes in theory, and I even think it’s quite beautiful. However, it would be wrong to say that I know how to use it. Is that a problem? No, because I don’t need it. Containers, yes, a bit of simple orchestration (Docker Compose), but nothing more.

So once we enter the workforce, we need to let go of our overly academic habits. How can we do that?

By remembering which industry we’re serving, which industry we aim to support with IT: investment banking? Logistics? Human resources? You name it. Every field comes with its own constraints, every use case comes with its own constraints. There’s no one-size-fits-all solution.

If that sounds like Domain-Driven Design to you, well spotted 😁 What makes the difference is domain knowledge. Without that, there’s no pragmatism.

By mastering the technology inside and out, you can be a good dev. To be a great dev, you also need an insatiable curiosity about the business and a desire to build useful things. Without this distinctive and rare mindset, you’ll hit a ceiling sooner or later.

But anyway, in the end, this fascination with technology is what leads companies to use microservices when a good modular monolith would suffice. When it all becomes unmanageable, that’s when I step in. So above all, don’t change a thing 😉