[antonvs]

I initiated and led the Kubernetes adoption at the startup I'm with currently. Handed it off to the new ops team recently. The company is dramatically better off now in terms of scaling, deployment automation, configuration management, service discovery, internal service interactions, stability, reliability... The list goes on.

If your needs are met by a VM or three then sure, you may not need Kubernetes, although as other comments have pointed out, distributions like k3s can be useful even in those environments. But as you climb the scale and complexity ladder, there soon comes a point where it's very hard to beat Kubernetes, which is why it has become so widespread.

[politelemon]

I did the same with managed services and they're in a better place than they would have been with k8s - which is where they started and had to be rescued from... It had become an inescapable gravity well of pointless busy work. It isn't about the tooling, it's knowing the business.

[antonvs]

Yes, that works if the system is simple and standard enough to be handled by a managed service provider.

> It isn't about the tooling, it's knowing the business.

The sort of statement I expect to see on LinkedIn. Once you know the business, you decide on appropriate tooling. As I said, as you climb the scale and complexity ladder, Kubernetes starts to make more sense. At that point, the tooling can become very important.

[scarface_74]

I use to believe that too until someone rightfully reminded me of all of the ugly solutions I’ve used over the years to deploy to VMs. Then I became a big believer in always containerizing.

[hbogert]

This is the insight. You'll a worse job even for something as certificate management with letsencrypt. Let alone all the other stuff. If your workload doesn't need that, and you are fine with some downtime, then and only then don't do it.