PaaS for K8s

I’m still running into the wall with developers on Kubernetes, and now I realize, I need to change tack. No matter how good I think my Terraform skills are for bootstrapping minikube, it’s a black box for many developers. K8s is scary, irritating business for users unaccustomed to it’s nuances, and developers have a lot on their plate. I learned a hard lesson, devs are not going to switch to any greater complexity than that proposed by Docker Compose. Furthermore, even experienced devs have built up their experience using Docker Compose, and do not have any desire to work with any additional layers of infrastructure abstraction. Despite what I wrote previously, Docker Compose is here to stay (Docker Swarm can still die in a fire though).

What if instead of imposing K8s on developers, we instead impose a PaaS on top of Kubernetes? This is not without merit. Coolify enjoys huge success with developers despite not having much corporate backing, and not much social discipline within the community. There’s nothing fancy about it, no sales team or organization pushing it, but it operates at the abstraction developers like. The old Heroku is something a lot of devs still pine for.

Looking for a Kubernetes based equivalent, I eventually gravitated to Kubero. There were a few alternatives, but I wanted something that was opt-in on top of the base infrastructure I already provide through Argo / Helm and OLM. Kubero is not for amateurs or people without at least intermediate Kubernetes skills, but once you understand the design paradigm, it gets the job done in a manner that uses Kubernetes capabilities instead of bolting on additional layers. I have some gripes about these PaaS systems not being as flexible as something like Nomad, or ECS, but they make deployment a snap.

The absolute killer feature for Kubero is the ability to deploy from a Dockerfile. Some might say it’s not deterministic, but that’s up to the way you want to build inside the container. That’s really the point of Kubero, an extension of single container builds into production. For the most part, this is what developers want. All I need to do is set the deployment pipeline. That keeps developers happy and away from the internals of K8s. Win win.

Building helm charts for single container deployments isn’t all that great. For other people’s code, sure, but internally developed services shouldn’t need an additional wrapper.