Dan Garfield’s Post

If you work in technology, you should have the technical knowledge of how an OS works. I'm not saying you need to be able to assemble a distro from scratch but you should know what all the pieces do and how they fit together. Saying you don't need to know how your OS works is how you will get the Windows of cloud OSes and infantilize an entire generation of devs.

💯 Developers just want to point to a GitHub repo and have it run somewhere. We should be putting tools in their hands where they don't have to care if its k8s, ECS, nomad, or whatever underneath.

It's not even like an OS... it's more like an Apple 2. When you boot it, you put in the OS floppy and load the OS. Then you start loading program floppies. K8s is like that... you ask for a "managed" version and it's got weird stuff already, and then to make it useable... well you need a lot more floppies.

Kubernetes is not an OS for the cloud. It tries to replicate a cloud in the cloud. It almost seems like an anti-pattern. Cloud providers already provide identity services, k8s adds up to it. Vpcs are the barebones of any cloud, but Kubernetes adds yet another layer on top of that. Load balancers have multiple offerings in the cloud, yet everyday we see a k8s ingress being created. Auto scalers are already part of any cloud, yet k8s adds another layer of abstraction and complexity to it. Kubernetes alone provides no immediate value unless you start piling operators, ingresses, admission controlers, autoscalers, network overlays yada yada and when you realize you are operating another cloud inside the cloud it is too late. It might make sense onprem (for the brave ones willing to operate the control plane too), but at the end of the day, k8s in the cloud just makes no sense.

I have a feeling that a lot of the K8s adoption and microservices stuff comes from a time when money was cheap and teams could fiddle around with complicated stuff for ages without consequences. So far in my experience, most startups/scaleups and SMEs don't need microservices deployed on a kubernetes cluster with all kinds of shenanigans. Most are better off with the simplest and most cost-effective system that they can get. Running k8s is expensive on so many levels, it is hard to justify.

Here’s a relevant read on the incidental complexity of Kubernetes. We shouldn't resign ourselves to accepting complexity as an inherent fact—other approaches are possible. However, the complexity in Kubernetes is an undeniable reality that demands our attention. Proactive measures can make a significant difference in managing this complexity. Link: https://www.xkyle.com/The-Incidental-Complexity-of-Kubernetes/

Kubernetes is a highly technical lego kit for running images. Of course, you need to know how to run it and where to run it. And what you want to do with it? That's literally the point of it. Seriously. There's a huge difference between dropping an image on cheap storage that cost you nothing... Versus running it on production that is double mirrored. Clustered and cost four million dollars a cluster. It's a detail, it's important and it costs money. What I really hear is. You want to pitch easier orchestration versus the merits of the underlying technology. This shit just pisses me off. Like honestly.

K8s hosted platforms on cloud are really a one time yaml configuration for the ingress, deployments, dns, certificates and other specifications. Unless you want to geek out like we did or perhaps still do on linux internals you can trust the documentation and spin a k8s cluster on cloud really quick...with trusted and verified modules your iac is already referencing a strong baseline...custom yamls need experience if you want them to "just work" :)