[LimaBearz]

Kubernetes is like sex in high school. Everyone says they’ve done it but very few have actually done it.

It’s a bit early to say anything. If anything the death of k8s will be sparked by all those who fail to implement it the right way like we all did with AWS.

I first got into AWS very early on and one of its early official selling points was ephemerality yet most of us treat everything as pets, EC2 has affectively become just a vanilla hosting/managed provider with an API on top.

K8s isn’t difficult or complex, it’s just different and once you get it you get it. What ruins it is things like not following its intended paradigm, breaking the isomorphism and determinism of the containers… insisting things ansible, chef, salt, et la.. are still required. Grabbing a shell into container to debug something non app related, effectively breaking the ephemeral nature. The only thing you’ve effectively done is added additional complexity without hacking off any of the stuff that should be dead

Before k8s goes out I think no-code and then by extension no-infra will become a lot more ubiquitous, and if anything no-code will consolidate off a good chunk of our industry

[adflux]

>K8s isn’t difficult or complex

Even engineers working on kubernetes agree that it is a very complex framework. It consists of many different layers and introduces a large amount of (unique to kubernetes) concepts and also requires extensive knowledge of docker...

[hmsimha]

Containerization, certainly, but you can run kubernetes just fine without Docker (I was under the impression most large-scale deployments now use Cri-O - https://cri-o.io/#what-is-cri-o)

[mathw]

Kubernetes absolutely doesn't require extensive knowledge of Docker. At least not if you're using a managed, hosted Kubernetes platform, maybe it's different if you're running your own. But it takes almost no knowledge of Docker to stick a .NET 5 build into a Docker container and not a lot of knowledge of Kubernetes to write a deployment manifest which sticks that container in five replicas over however many physical nodes with a service to allow other services in the cluster to call it, or an ingress controller to expose it to the outside world, even with config being injected through the container manifests (admittedly being hugely helped here by how .NET config picks stuff up from environment variables now).

I've found Kubernetes is very well structured, and allows you to ignore just about anything you aren't actively in need of using. I'm sure it gets incredibly complex if you really need all of its power, but based on what my team have done so far with it? I doubt there are many people who are actually going there.

Okay so we're building something that has been mentioned as being "too simple" for Kubernetes and "you could run that on App Service" (we're on Azure hosting), but having looked into that option... Kubernetes is easier. It's pretty open about what it's doing, there's loads of knowledge out there to draw on, and it does what you tell it to. Sure there are Kubernetes concepts you have to learn, but like I said above you don't need to learn all of them at once, and it's pretty easy to get started with deployments and replicas and services.

Kubernetes is a fantastic example, in my opinion, of a product designed to solve a set of very complex problems which actually solves those problems in a decent way rather than just changing them into different, equally complex problems, which just about everything I've used in the past seems to.

[toomuchtodo]

No code platforms run their containers on Kubernetes. They’ll be the new cloud providers (but instead of “it’s someone else’s computer” it’ll be “it’s someone else’s application”).

Turtles, all the way down.