Hacker News Reader

Comment by movedx | Hacker News Reader

> Kubernetes is meant for enterprises

Actually it's meant for virtually no one, because very few people have the problems it solves. Like AutoScaling Groups, Serverless, and Cloud its self, it's a tool that solves a pain point in a specific domain. About 0.001% of the business world have that problem.

> We're happy with the move and the pressure relief is tremendous.

I'll bet it was. I've convinced businesses to go in the completely opposite direction to K8s. I've told them to developed a monolith before they start optimising into microservices. The startups that listened to me are still around and in round C. The others closed up shop ages ago (minus one of them) because they never got to market in time.

K8s is a tool. Docker is a tool. Cloud is a tool. Businesses have to utilise tools as efficiently as possible to get their solutions out the door if they're to survive. Using K8s from the ground up is a death sentence.

View on HN

The "Kubernetes is only for Google-scale companies" meme needs to die. Kubernetes is a useful tool even if you have a single node.

As a case in point: I just set up a small new app on GKE. Because I'm experienced with Kubernetes, within a few minutes I had my app (a React front-end written in TypeScript and a backend written in Go) running and receiving HTTPS traffic. I entered just a handful of shell commands to get from an empty cluster to a functional one.

It's a cluster with a single node, no resilience. But this is genuinely useful, and a perfectly appropriate use case for Kubernetes. The alternative is the old way — VMs, perhaps with a sprinkling of Terraform and/or Salt/Ansible/Chef/Puppet, dealing with Linux, installing OS packages, controlling everything over SSH — or some high-level PaaS like AppEngine or Heroku.

While it's an example that shows that Kubernetes "scales down", I'm now also free to scale up. While today it's a small app with essentially zero traffic, when/if the need should arise, I can just expand the nodepool, add a horizontal pod autoscaler, let the cluster span multiple regions/zones, and so on, and I'll have something that can handle whatever is thrown at it.

My company has a ton of apps on multiple Kubernetes clusters, none of them very big. From my perspective, it's a huge win in operational simplicity over the "old" way. Docker itself is a benefit, but the true benefits come when you can treat your entire cluster as a virtualized resource and just throw containers and load balancers and persistent disks at it.

Agree totally. One win Kubernetes provides my current team has been the fact that it is the interface on top of a cloud with agnostic primitives, allowing for multi cloud scaling. There are a lot of primitives, and a lot of things to monitor to ensure a running cluster, but the complexity of the system is IMO overblown in the popular mind. Isn't the core tenant of SRE to have the stability of the system automated?

> It's a cluster with a single node, no resilience. But this is genuinely useful Can you elaborate? Sounds like replacing one kind of server management overhead with a new kind otherwise.

It's replacing one thing with something else, but the management overhead on GKE is significantly less.

I've also managed a built-from-ground-up Kubernetes cluster. It's not rocket science. That said, I wouldn't do it in a company without a dedicated ops person.

Can't agree more. That said, Kubernetes still has way too much RAM/CPU overhead in a single node setup. It scales up, but it doesn't scale down. Hopefully, it can be solved. There is k3s, for example, that limits the overhead by replacing etcd with SQLite, removing old stuff, etc.

> controlling everything over SSH

It just takes some experience. I mostly disable SSH for example. You bake your images once, not install everything on each boot.

> My company has a ton of apps on multiple Kubernetes clusters, none of them very big. From my perspective, it's a huge win in operational simplicity over the "old" way. Docker itself is a benefit, but the true benefits come when you can treat your entire cluster as a virtualized resource and just throw containers and load balancers and persistent disks at it.

And I agree. However...

I'm referring to the companies and people who don't think like you do and instead think, "We need to build everything as a microservice and have it orchestrated on K8s". I'm thinking of the people who have a monolith that's scaling fine, solving a problem, and generating income, but an executive has been sold on K8s and now wants to refactor it.

Your use case makes perfect sense, but very few people are thinking like that, sadly.

In my opinion if you're starting out with Docker and K8s, you're going down the right path, but only provided you're not starting with microservices.

Like you said it's a tool and like with most tools there is a balance between over engineering its use.

That sounds more like a criticism of microservices, which can definitely be overdone.

You are being downvoted by the Kubernetes crowd, but you are quite right, it is the new NoSQL.

People realise their time has been wasted and their feelings are hurt as a result... oh well.

Reply on news.ycombinator.com