Kubernetes knowledge is becoming an important job skill, and if your current employer does not use Kubernetes, you'll need to learn it on your own.
> Which IMO, most businesses don't even have a compelling reason to switch from the old 3 tier monolith architecture.
Compelling reasons include self-healing, autoscaling, and official support from all major cloud providers. In my experience, it's actually easier to adopt Kubernetes at a smaller company than a larger one.
It's also becoming harder to hire developers who are willing to work on monolithic codebases. It's been a while since those were the state of the art, and a lot of people with 5+ years in the industry have never seen them before.
We adopted Kubernetes at our startup, it solved most ci/cd and devops issues for the team. We didn't need the scaling either, we have at max maybe 2 containers of a service but we know we are ready.
There are plenty of companies ou there that have old COTS lying around and require some sort of IT infrastructure. Being able to setup and manage a working cluster of COTS hardware is a great way to add computational resources to a company without spending au additional cash or having to rubber stamp permits.
I personally have done this in a previous job, and a small POC with minikube turned into a 3-node kubeadm cluster that deployed and managed two company-wide intranet services like a breeze. Zero cash was spent, the only resource used was a few hours of my time, everyone benefitted, and managers were very happy with the result.
I also baked a 25+service AI platform onto 4 virtual machines, running kubernetes, for deployment in an air-gapped system without a knowladgable operator. It was an excellent choice for that project because of the auto-healing capabilities.
I have also run it at a small startup where we had a combination of static nginx sites, ruby on rails sites, elixer sights, node.js app, and even a c++ app. (it was at a crypto company if you are wondering why so many disparate languages). Having a single deploy pipeline for 5+ different languages and architectures was awesome. I would have killed myself if I needed to support all of those in their native environments at the same time.
There are lots of good use cases for k8s, and honestly it's not that hard if you already have system admin skills because you understand the problems it solves and how it works. Most of the folks I have seen struggle with it are developers (and likewise, I struggle with OOP sometimes - i don't mean to diminish developers skills).
b) IMO, self-hosting and less centralization of the digital services we rely on is highly desirable for society. (If k8s is the right solution for any particular individual to orchestrate their stuff is a different story). I think for most people who do this, it's a hobby and something they enjoy. Why would you have a vegetable patch when there's food in the store and your employer has a complementary lunch cafeteria?
Hackers gonna hack, you know.
I don't need to spend my time developing skills for the job I've already got, I need to develop skills for the next job I'll have
> most businesses don't even have a compelling reason to switch from the old 3 tier monolith architecture.
...thus showing I can't rely on my employer to keep my skills up to date for me.
Not that there's no market for specialists in older technology - back in 1999 I heard rumours that COBOL experts were commanding huge salaries to work on millennium bug mitigation in banks. But people following that career path should be choosing it consciously, not by accident :)
Being in demand means close to nothing. Once I was contacted to work on a tool that was developed in Delphi and I would hardly suggest anyone should pivot from their career to jump on that gravy train.
You should build up the skills required for your next job, not your current offers.
If the price of a stock or house or investment have been rising for two years, it's risen in cost to get into, and you might never see the gains people have seen in the past; I doubt you'll ever get a bitcoin for a dollar again!
But if job adverts for a new tech have been rising for two years, it doesn't cost any more to learn than on the day it was released. Maybe less, in fact, as there will be more tutorials and more experts to learn from.
Kubernetes is pretty lean. It does require a significant mental load to get up and running, but that's mostly due to how it forces developers to venture into the old and largely unfamiliar sysadmin territory, where you need to pay attention to more stuff other than the compiler finishing a build job.
I'm kind of in this weird position where I understand the benefits and use of k8s, but I:
a) Can't think of any cutesy distributed systems/microservices type thing that I could or would want to run on a low power machine locally (lack of processing power or ISP getting pissed off @ massive amount of traffic if you're e.g. scraping a ton of data and doing stream processing on it in your little cluster)
b) Don't really understand the point in investing time in it, as it feels like one of those things you learn on the job as it comes up. And for a lot of people (the majority, probably?) it'll probably never even come up unless they just are hunting for new tech to introduce at work regardless of if the business actually needs it. Which IMO, most businesses don't even have a compelling reason to switch from the old 3 tier monolith architecture.