most people probably want the following:
- no downtime deployments
- distributed jobs
- as managed infra as possible
without k8s some things would be hard.
without k8s some things would be hard.
distributed jobs? same; nothing prevents from spawning runners with adhoc libraries and queues.
managed infra? not specific to k8s
Why piece all of that functionality together yourself into some fragile framework instead of using a industry standard?
If you only need certain parts of what k8s offers, building those parts yourself can offer you more stability, control, and insight into what your application is doing.
As with anything else it varies case-by-case.
Not that there aren't good reasons or good outcomes from having done a deep dive, but just putting it there.
Building it yourself doesn't mean building all of it. For example, it's quite easy to get zero downtime deployments with a tiny bit of systemd configuration and the SO_REUSEPORT socket option. That seems easier for a team to understand than "here is kubernetes and everything that comes with it"
You need to deliver the application to the machines somehow. You might need to configure the network to reach the application, etc. All quite common tasks.
(And honestly, systemd can bite you just as much if not worse than k8s definitions, because the API is much less cohesive and the defaults like to cut off your hands)
The problem with that logic is everyone on your team will need to do it, so you're going to be stuck picking a standard. Should it be yours, should it be mine, or should we both just learn something with a large community behind it?
Nothing is perfect of course, but k8s makes a really good target for CI/CD, which is something you want when you're developing as part of a team. If you're not quite a team yet and you don't know how to bootstrap k8s and CI/CD, then you need to figure out when those types of things are important.
Probably lots of people could stick with a monolith and a VM for longer than they did, but automated testing will save you a fair bit of time if you're not figuring out how to do it at the same time.
Quite recently developed "industry standard". Many tools mentioned have been used for tens of years, they work robustly, are well documented and there is lots of people who can use them. I personally would use the word "industry standard" a little bit differently.
k8s is based off of Borg, which has existed for far longer.
There’s really nothing like the full suite that kubernetes provides.
You know tech has made it when people offer argumentum ad Java.
'Sure, X might not be the best solution, but you can always buy someone to do it.'
k8s also adresses a very small portion of the market. If you have to scale, yes, you might need k8s. Chances are, you don't. Really.
I stopped counting the (supposedly big) customers that burnt themselves into k8s when they logistically need not to, and only brought organisational issues on them.
Setting up and taking care of k3s is much easier.