I was going to ask "why", but you already explained it in your writeup:
> The prevailing wisdom is that Kubernetes is overkill for a small Rails/Elasticsearch app, but overkill is my life philosophy.
> The prevailing wisdom is that Kubernetes is overkill for a small Rails/Elasticsearch app, but overkill is my life philosophy.
It feels like many developers these days are so spoiled by magic services that they are unwilling to even spend a few days going deep into something. Everything has to work in minutes. Next, what inevitably happens is that services shut down, pricing changes, or something stops working, and they have no way to debug it or move off it. And then we get customer support complaints and posts on HN about it. These developers look for the next shiny 3rd party service that solves the problem immediately and repeat the cycle, without ever learning anything that helps in the long term.
Quite the opposite. K8s are a big opaque ball of magical complexity to most of us devs for sure (as is heroku). However, for 100% of my use cases nothing should be more complex than the database.
I’m not opposed to learning about it, but reducing complexity wherever reasonable has paid off for me.
It's more than the learning curve, though. It also requires resources for itself (the control plane) so it's not really suitable for small projects unless you use a managed offering (which has the same downsides as you mentioned in your second paragraph).
Also you make it sound like all Kubernetes alternatives are 3rd party, paid, hosted services, which is far from the truth.
I can still run it locally for dev via Docker and I use Devspace to make it easy to bring up a dev env.
But one should not forget that you also had to build up a lot of vendor specific know how in the past. Someone had to configure your F5 BigIP and your Juniper Router and the Cisco Switch and of course the Dell or HPe boxes you bought.
I take more concerns with k8s immature ecosystem which is kind of reinventing classic unix stuff for distributed computing. And that just started and you've to lifecycle components with breaking changes every few weeks. And people took issues with updating Ubuntu LTS releases every two years. Now they have to update some component every week.
Look I can and have done all these things, but it's just not worth my time to do them for my little apps. I'd rather be talking to customers and shipping features at this point in my career.
I don't know. I had a pretty good thing going prior to k8s too, just some rsync and `ln -sfn` and it was easy, simple and very fast, but like you said, upgrading Ubuntu and PHP and other services becomes the problem there. Couldn't do that without downtime.
Trade-offs.
It barely takes a weekend to learn and play around with managed k8s from cloud providers or with minified k8s tools like k3s, k0s etc.
Because my project doesn't need the benefits that K8s offers. Why choose the more complex solution when I don't need it? And judging from experience and what others have shared, most projects will not need it.
> no way to debug it or move off it
If a managed service is down, the host company debugs it. That's the whole point of a managed service, so I don't have to do devops.
Why would there be no way to move off of it? PaaS is so easy to onboard and deploy, you can move to other services easily.
> It feels like many developers these days are so spoiled by magic services that they are unwilling to even spend a few days going deep into something
Why don't you go all the way and build your own physical servers instead of using these magic cloud machines? That way you can go deep into it, and if they have problems, you can debug yourself.
If you enjoy building and maintaining your own K8s clusters and you feel it benefits you, great for you. But don't be so condescending to people who don't feel the same and choose the simpler infra solution because they'd rather go deep into building their application rather than spending time with K8s. Calling them spoiled for that is just obnoxious.
So what? It just takes a month long time investment to be used to kubernetes(many people already have some experience from working for employers), and after that it takes one or two days extra days to make some project as easy to deploy as heroku. So basically it is a fixed learning cost. Obviously if someone is looking to get something up as soon as possible and doesn't have kubernetes experience, it is better to not use it.
But for me, the fixed learning cost clearly paid off. Kubernetes is lot better than alternatives if you want to assign fine grained securities, namespaces, complex scaling rules, using multiple clouds, multiple node types etc. Even if I don't need any of these now, I am not giving any extra time investment for new projects and it guarantees I don't need to do any migration to some other form of deployment if my project becomes big.
Ok so next time I'm laid off I will have some tech to choose learning. May I will spend that month.
Even when I wasn't a parent I don't think my life was that open that I could say well it only takes a month, I guess I will learn that. Lots of things take a month to learn. people pick and choose.
The systems evolution that led us to Kubernetes does have it merits of course: I just know I can trust the simple foundations of control loop meets immutability in order to maintain complex distributed systems, including expectations for self-healing and resilience. Though IMHO the "freedom" aspect you hinted on above is the more important one these days - yet usually cloud platform dependence unfortunately creeps in, in other ways still.
Personally though I bet that for an easy 80% of "need to deploy software" cases, Kubernetes is indeed overkill - as long as it isn't "managed" / abstracted away at least to the level of a Heroku. And of course there are many other ways and platforms to benefit from "containers" and their promise (?) of independence these days.
All power to anyone though if they have the money/time/energy to put work into that layer, in addition to whatever else they are trying to achieve. Disclaimer being that learning can definitely be its own merit (that's how I got started myself) but it's important to know when it's "just" that, when it's more and when it's simply overkill.