Thanks for writing this article. I feel the same way.

The irony is that Kubernetes (and Service Fabric) were never meant to be seen in the first place.

These technologies were the private substrate that ran the subscription bits and pieces we were supposed to be buying, but were too easy and boring.

This tech is worth the expense to cloud providers because its foundational to the value proposition: oven-ready, scalable, reliable cloud services.

As programmers we conspire to make things complicated for ourselves because we crave the stimulation. It’s a terrible affliction to which I’m not immune, I catch myself over-nerding all the time.

For years we wondered how Google managed to run at such scale and reliability, and then they made their technology public and we sat up, wide-eyed at this scale porn: we want to feel like we’re Google, so we found a way to indulge ourselves with million microservices and trillion developers for a room-booking app losing $$$ millions a day.

But at least we can individually scale the widget that converts miles to kilometres, or something. Think of what we’re saving.

This leads to the second irony, that Kubernetes demands an ops team while we’re proud that we’re fully DevOps, believing our own lies that DevOps actually always meant a dedicated team using tools with cool names. It helps if we call our ops team Site Reliability Engineering, like Google.

Perhaps there’s an economic explanation. Is all this complexity symptomatic of the over-supply of VC money chasing problems? A form of inflation.

Will the next downturn cause CEOs to justify the ROI? Can the customer tell that we have 2,000 containers? Would customers stop turning up if we had a well-factored monolith backed by a single Cosmos DB?