> Every item on that list is "boring" tech. Approximately everyone have used load balancers, test environments and monitoring since the 90s just fine. What is it that you think make Kubernetes especially suited for this compared to every other solution during the past three decades?
You could make the same argument against using cloud at all, or against using CI. The point of Kubernetes isn't to make those things possible, it's to make them easy and consistent.
> The point of Kubernetes isn't to make those things possible, it's to make them easy and consistent.
Kubernetes definitely makes things consistent, but I do not think that it makes them easy.
There’s certainly a lot to learn from Kubernetes, but I strongly believe that a more tasteful successor is possible, and I hope that it is inevitable.
I haven't worked in k8s, but really what is being argued is that it is a cross cloud standardization API, largely because the buzzword became big enough that the cloud providers conformed to it rather than keep their API moat.
However all clouds will want API moats.
It is also true that k8s appears too complex for the low end, and there is a strong lack of a cross cloud standardization (maybe docker but that is too low) for that use case.
K8s is bad at databases. So k8s is incomplete as well. It also seems to lack good UIs, but that impression/claim may be only lack of exposure.
What is blindingly true to me is that the building blocks at a cli level for running and manipulating processes/programs/servers in a data center, what was once kind of called a "dc os" is really lacking.
Remote command exec needs ugly ssh wrapping assuming the network boundaries are free enough (k8s requires an open network between all servers iirc), and of course ssh is under attack by teleport and other enterprise fiefdom builders.
Docker was a great start. Parallel ssh is a crude tool.
I've tried multiple times to make a swarm admin tool that was cross cloud and cross framework and cross command and stdin srrout stderr transport agnostic. It's hard.
But none of those things are easy. All cloud environments are fairly complex and kubernetes is not something that you just do in an afternoon. You need to learn about how it works, which takes about the same time as using 'simpler' means to do things directly.
Sure, it means that two people that already understand k8s can easily exchange or handover a project, which might be harder to understand if done with other means. But that's about the only bonus it brings in most situations.
> All cloud environments are fairly complex and kubernetes is not something that you just do in an afternoon. You need to learn about how it works, which takes about the same time as using 'simpler' means to do things directly.
The first time you do it, sure, like any other tool. But once you're comfortable with it and have a working setup, you can bash out "one more service deployment" in a few minutes. That's the key capability.
The other bonus is most opensource software support a Kubernetes deployment. This means I can find software and have it deployed pretty quickly.