Hacker News Reader

Comment by pammf | Hacker News Reader

I don’t understand all the blame that k8s get as well. Using the defaults, it can be as simple as you’ve made it; a reverse proxy load balancing multiple instances of a containerized application. I wonder what other simpler tools/solutions could be used to address scalability and high availability requirements.

View on HN

The “old fashioned” way of doing that would be to just have some base images and init scripts running on vms with a load balancer.

That will scale a small number of containerized services just as readily as kubernetes and will have a lot less moving parts.

Where a more robust container orchestration system shines is when you have many disparate teams deploying disparate workloads and need to encode conventions around things like networking, service discovery and security policies.

Or use a PAAS (Fly.io, Render, maybe even Heroku I guess) if you just want to get your MVP out there while you focus on your product and business.

I think that the level of complexity to set it up is not far below and you would miss some features that you get out of the box with k8s: - Proper monitoring of the health of the instances (simple load balancer health probes rely only on ports listening, which is quite brittle) - Dynamic resource management I.e. does this vm have enough cores/memory to host this number of application instances - Centralized/automatic port mapping. If your app listens on port 5678 for example, to be able to run more than one instance in a single vm you need to map it to different host ports and keep your load balancer configuration up to date with that.

You will definitely add complexity if you want to run multiple app instances per node. I do not view that as particularly compelling for any runtime that supports concurrency out of the box in a virtualization environment.

As for health probes, I worked with load balancers in the late 90s that could use endpoint health checks so I’m not sure what you mean.

I think it’s compelling from a scalability perspective given that deploying one OS for each app instance you want is quite wasteful and increase entropy: deploying from a single image doesn’t guarantee the os won’t change over time, and if you have 100 instances, keeping all of them consistent will require solutions that will inherently increase the overall complexity, which is the main argument against k8s.

Regarding the endpoint health probes, I agree that’s possible if you have an app with a call that’s lightweight and representative enough to be used for that. But again, we are already deviating from the “pretty simple” solution here as well.

And we didn’t even start talking about how to make the Load Balancer highly available…

That said. I agree that the solution you’ve mentioned is a feasible one, I just don’t think that it’s way simpler than k8s if you truly have more demanding scalability and availability requirements.

Because managers read about k8s and then mandate it for much more complex apps than "a self contained CRUD website / dockerized 3 microservices behind a load balancer"

Reply on news.ycombinator.com