> Along came the Kubernetes wave. It wasn’t meant to solve any of the above problems. It was supposed to provide efficient utilization of compute resources whil

> Along came the Kubernetes wave. It wasn’t meant to solve any of the above problems. It was supposed to provide efficient utilization of compute resources while improving reliability and availability. So, both containers and Kubernetes serve different purposes. I feel like Kubernetes tried doing way more than that: it added additional abstractions like ingresses and load balancers, abstracted away storage with its drivers and PVC concept, added support for all sorts of cases when something should be run (e.g. if there's a task you'd like to schedule or even just run once), introduced namespaces and its API is pretty extensive and extensible, especially with CRDs. Just look at how many projects have propped up around it, from networking solutions (Calico, Flannel, Istio, linkerd, ...), to storage solutions (Longhorn, Rook, ...), to all sorts of additional software, like Helm, Kustomize, Skaffold etc. Of course, that's not to say that everyone needs all of that complexity, as others have rightfully pointed out in the comments. Personally, i think that the sweet spot is focusing on OCI as the standard to go for and hosting most of the software that you need inside of containers with a lightweight orchestrator, only moving to something more complicated once the need actually arises. For example, Nginx in a container on Docker Swarm is far more simpler while also being a bit more flexible than Kubernetes ingress: just this week i needed to expose a Sonatype Nexus Docker registry on server port 5000, 5001, ... whilst also wanting the reverse proxy/ingress to handle SSL/TLS termination with a wildcard cert. Kubernetes ingress doesn't support these non-standard ports, whereas NodePort would have necessitated running on the 32000-... port range and even then i'd need to setup a separate Nginx instance if i wanted to use it for certificate management, as opposed to importing the certs into Nexus itself, which kind of defeats the purpose. Also, needing to trick a Traefik ingress (the default in k3s) into using a custom default wildcard cert necessitated a HelmChartConfig, ConfigMap, Secret (TLS) and TLSStore, which seems badly documented, cryptic and also just wasn't too user friendly - and felt like a step back when compared to just needing a nginx.conf (or the Traefik equivalent) and the actual .crt and .key files. Whereas with Docker Swarm, i can just have one Nginx container and expose whatever ports i want, because i'm not pigeonholed into a particular type of abstraction - however, that comes at the expense of not having easy to configure ingress, since i need to change the Nginx config manually. Regardless, the simplicity of Docker Swarm and the likes of Hashicorp Nomad is actually a boon - in the case of the former, pair it up with Portainer and it should be pretty smooth sailing from there onwards, even easier than using Rancher with Kubernetes! Admittedly, it all probably depends on the scale that you operate at - because once you really need to think about node draining, resource rebalancing upon adding new nodes, autoscaling and other advanced concerns, then you might want to look into Kubernetes, but for the most companies and projects out there, that's hardly necessary. For most of them, regular containers with some lightweight orchestrator running on top should be more than enough. I think Docker here wins out as the runtime as well as opposed to containerd or podman, because of its historical significance and how much software has been build around it (hell, even Rancher in Docker basically takes the Kubernetes in Docker approach which is actually really nice, apart from it all breaking on newer RPM distros because of a lack of cgroups v2 support). Now, there are other container technologies out there as well (e.g. LXC or some might even suggest the BSD jails), but i think that we're not in too bad of a spot right now. Luckily alternatives to Kubernetes are still maintained and are pretty usable, sometimes even Docker Compose can be enough for prototyping or dev environments and if you ever find yourself needing to look into using Kubernetes, projects like k0s or k3s are pretty much excellent for that. Of course, i'd also suggest a modicum of supporting software, like Rancher for a nice web UI and Rancher Desktop to not have to pay for Docker Desktop, if you don't need it. In my eyes, this approach also fully eliminates vendor lock - all i need is a bunch of VPSes on any cloud host, on which i can initialize a container cluster with the likes of Ansible and migrating is similarly easy (especially with bind mounts for storage). PaaS platforms can be nice for when you don't want to deal with managing your own servers, but i much prefer to keep my apps as portable as possible. That's not to say that the PaaS approach is not valid, as it can indeed save a lot of time and effort, if you haven't invested in automating the setup and management of your own nodes!