Kubernetes is so easy that you only need two or three dedicated full-time employees to keep the mountains of YAML from collapsing in on themselves before cutting costs and outsourcing your cluster management to someone else.
Sure, it can be easy, just pick one of the many cloud providers that fix all the complicated parts for you. Though, when you do that, expect to pay extra for the privilege, and maybe take a look at the much easier proprietary alternatives. In theory the entire thing is portable enough that you can just switch hosting providers, in practice you're never going to be able to do that without seriously rewriting part of your stack anyway.
The worst part is that the mountains of YAML were never supposed to be written by humans anyway, they're readable configuration your tooling is supposed to generate for you. You still need your bash scripts and your complicated deployment strategies, but rather than using them directly you're supposed to compile them into YAML first.
Kubernetes is nice and all but it's not worth the effort for the vast majority of websites and services. WordPress works just fine without automatic replication and end-to-end microservice TLS encryption.
I went down the Kubernetes path. The product I picked 4 years ago is no longer maintained :(
The biggest breaking change to docker compose since it was introduced was that the docker-compose command stopped working and I had to switch to «docker compose» with a space. Had I stuck with docker and docker-compose I could have trivially kept everything up to date and running smoothly.
I ran small bootstrapped startup , I used GKE. Everything was templated.
each app has it's own template e.g. nodejs-worker, and you don't change the template unless you really needed.
i spent ~2% of my manger+eng leader+hiring manger+ god knows what else people do at startup on managing 100+ microservices because they were templates.
We may have a different understanding of "small" if you say 100+ services.
Did each employee have 2 to 3 services to maintain? If so, that sounds like an architectural mistake to me.
That works great until you want to change something low-level and have to apply it to all those templates.
That's when you go a level deeper and have every template use another template (e.g. a Helm subchart or Helm library) only to realize scoping and templating is completely fucked in Helm.
Nonono you.missed the part where you add Infra as Code, with requires another 2-3 fulltime yaml engineers to be really vendor agnostic.
> to be really vendor agnostic.
This is an anti-pattern in my opinion. If you're on cloud provider A, might as well just write code for cloud provider A. If and when you'll be asked to switch to B you'll change the code to work on both A and B.