I think the larger issue is how Kubernetes often is implemented in organizations - as part of internal developer platforms owned by central teams which on purpose or by accident can end up dictating how development teams should work. I think it's easy for such central teams to fall into the trap of trying to build smart, custom abstractions on top of Kubernetes to simplify things, but over time I believe these types of abstractions run a high risk of slowing down the rest of the org (good abstractions are really hard to come by!) and creating fuzzy responsibility boundaries between central and development teams. As an example, this can affect an organizational structure by (re-)introducing functional silos between development and operations. Can a development team really be fully responsible for what they build if they rely on high-level, custom abstractions that only someone else in the org really understands?

Furthermore, if everything in an org is containerized and runs on Kubernetes, it's really easy to have a strong bias towards containerized workloads, which in turn can affect the kind of systems you build and their architecture.

Can you name any systems which are possible by being non-containerized? What do you see as the advantage here?

It seems like a legacy view of the world that containers are at all worse. Today they seem to offer minimal overhead & access to all the same hardware capabilities as native apps.

>>> This seems a bit absurd on a number of fronts. It doesn't shape architecture that much, in my view; it runs your stuff.

I mean, let's be candid.

There are plenty of times where "containers" are bags of shit software that were pushing into production and throwing hardware at them to keep things going. There are containers out there with out of date libraries that aren't getting updated cause the "work" and no one gives a shit.

If you can get away with that, what is the incentive to do highly integrated engineering that produces diagonal scalability? Why be WhatsApp when you can just throw money at bad software?

Containers can be a crutch for poor software maintenance, oh sure! Lots and lots of companies skate by with shoddy container infrastructure (often to relatively little ill impact imo). But I don't see much opportunity that is opened up by getting away from containers. One can do "highly integrated engineering that produces diagonal scalability" just as easily on containers as not, in my view. Containers don't inhibit much.

WhatsApp remains the glorious one example of ultra-efficient software. Way to go taking ejabberd+erlang and going far!! But does that path exclude Kubernetes? I doubt it. That architecture would have ran fine as containers or+and on Kubernetes. It wouldn't have made a material difference to what they were doing. It just would have been a different way to manage the underlying platform. Who knows, maybe it would have provided some patterns/templates/apiserver-ing that the team would have found useful to develop atop, to build forward on, that they instead had to build themselves?