Hacker News Reader

Comment by superq | Hacker News Reader

Servers are so much faster than they were ten years ago that a typical, fully-loaded enterprise app can almost always run on a single mid-sized 10-core box with 256 GB of RAM.. from ten years ago. It's absolutely ludicrous how much power is available now on a single box if you really want to scale up instead of out.

(Databases, of course, always like to eat everything because of poorly-optimized statements, but they've never really been good fits for K8s or containers anyway.)

Some might say that this isn't webscale, but Stack Overflow runs one of the most popular tech websites in the world.. on only nine web servers: https://www.datacenterdynamics.com/en/news/stack-overflow-st... and LiChess is similar: https://lichess.org/costs

View on HN

Why is this argument commonly used to dismiss kubernetes?

K8s is a way for you to drop a large number of such pieces of software onto a small number of such boxes, and keep the configuration and lifecycle of each of those deployments independent.

Kubernetes is not primarily a scalability tool it is an availability tool.

> a typical, fully-loaded enterprise app can almost always run on a single mid-sized 10-core box with 256 GB of RAM.

If you don't care about high-availability, then yeah. One thing I've learned in my career is that delivering reliable enterprise-grade service is anything but trivial. The level of complexity of any modern stance is high enough that there will inevitably be sharp-edged corner cases which aren't simple or cheap to deal with.

Don't most outages happen because of unforeseen consequences of changes to the application/environment rather than machine failure? Is reducing the exposure to machine failure really worth exposing yourself to the vast complexity of distributed systems?

I think the point of such tools is more than just reducing exposure to machine failure. Reducing exposure to machine failure also means that you can run your hardware closer to end of life without having to worry about data outages.

The article about stack overflow mentions this little tidbit.

> That application handles around 6,000 requests per second, and around 2 billion requests per month.

To be able to handle loads of 1M requests per second, your going to need more than one server dispensing results. Especially since only so much data can be stored in memory without running into performance issues.

That said, these kinds of tools are an unique use case. Not all programs need them.

Reply on news.ycombinator.com