True, but the alternative to C++ with that reasoning is Rust or Go (depending on your liking), not Ruby. And with both of these you can step around a lot of deployment issues, because a single server can be sufficient for quite high loads. Avoid distributed systems as much as you can: https://thume.ca/2020/05/17/pipes-kill-productivity/
I find that the big problems that k8s solve is the usual change management issues in production systems.
What do we want to deploy, okay, stop monitoring/alerts, okay, flip the load balancer, install/copy/replace the image/binary, restart it, flip LB, do the other node(s), keep flipping monitoring/alerts, okay, do we need to do something else? Run DB schema change scripts? Oh fuck we forgot to do the backup before that!
Also now we haven't started that dependent service, and so we have to rollback, fast, okay, screw the alerts, and the LB, just rollback all at once.
And sure, all this can be scripted, run from a laptop. But k8s is basically that.
...
And we get distributedness very fast, as soon as you have 2+ components that manage state you need to think about consistency. Even a simple cache is always problematic (as we all know how the cache invalidation joke).
Sure, going all in on microservices just because is a bad idea. Similarly k8s is not for everyone, and running DBs on k8s isn't either.
But, the state of the art is getting there. (eg the crunchydata postgresql operator for k8s.)
> I find that the big problems that k8s solve is the usual change management issues in production systems.
This.
I was in a company where devops was just a fancy marketing term, developers would shit out a new release and then it was our problem (we the system engineers / operations people) to make it work on customers' installations.
I now work as a devops engineer in a company that does devops very well. I provide all the automation that developers need to run their services.
They built it, they run it.
I am of course available for consultation and support with that automation and kubernetes and very willing to help in general, but the people running the software are now the people most right for the job: those who built it.
As I said in my other comment: it's really about fixing the abstractions and establishing a common lingo between developers and operations.
If you want to be a successful indie company, avoid cloud and distributed like the plague.
If you want to advance in the big corp career ladder, user Kubernetes with as many tiny instances and micro-services as you can.
"Oversaw deployment of 200 services on 1000 virtual servers" sounds way better than "started 1 monolithic high-performance server". But the resulting SaaS product might very well be the same.
recently talked to a non-SV software developer friend: yeah, I killed two days making a window show up on top of all others on ubuntu with QT (under KDE, so, a supported business-configuration...). After telling him that this is a standard-feature of most X windows managers and asking, whether he used Wayland (didn't know), we went into functionality. "Yeah, you can enter a command and execute it on a remote machine" - "isn't that what ssh is for and you can do with a 20 line shell-script"" - "Yeah maybe, but some management type developed it, while he was still a grunt so we have to keep it...". I bet, said management type is still bragging about how he introduced convenient remote command execution by writing a QT app and his own server (or maybe he's using telnet...).
