Hacker News Reader

Comment by dalke | Hacker News Reader

"Well, we handle it by Scaling Out."

Or by optimizing the code, switching to better algorithms, making better use of cache, etc.

"So, if the whole system is designed to Scale Out, one is in a relatively good position."

Not of the scale out overhead dominates the cost. A relatively recent, and widely read, article about this is at http://www.frankmcsherry.org/graph/scalability/cost/2015/01/... , titled 'Scalability! But at what COST?'. Quoting from it:

> Folks have gotten all wound-up about scalability, despite the fact that scalability is just a means to an end (performance, capacity). When we actually look at performance, the benefits the scalable systems bring start to look much more sketchy. We’d like that to change.

View on HN

I completely agree. Hence next paragraphs.

"Scaling Out means adding more Resources, and those Resources cost $$$. If the whole system can Scale Out, one would only be talking about Cost Effectiveness.

Cost Effectiveness would be a function of how fast Processing Time grows with the growth of Throughput or Data Volume.

There’s another way to Scale Out — changing the implementation. It’s not considered as Scaling Out really as it takes a lot of time. (Actually, I would call it an optimization). So, by definition, Scaling Out needs to be something done quickly, in connection with managing Resources."

It's just not the part of the definition I'm proposing. Bottom line is that systems should be scalable if they are not, one will encounter issues during rapid growth.

Scalability might lead thought to lack of cost effectiveness with given SLAs, or degradation of SLAs. That brings us to optimizations.

The title is "Speed is a feature. Introduction to performance engineering."

However, the topic covered very little about performance. It asserts that scaling out is the primary way to get performance, but never shows that is true.

This is not a-typical for 'enterprise' systems, where the primary goal seems to be to spend money on physical things, than on paying people to be clever. (Which is different than hiring more people; it's hiring the right people).

I've had several clients where they had performance problems that they were thinking of solving by throwing more hardware at it, without doing the root cause analysis to figure out where the slow-down was. I've then gone in and found order of magnitude changes.

The author elsewhere says that enterprise software "Is scalable. Scalability is the ability to support both more customers and bigger customers. Your architecture does the right things if you can throw in more boxes."

This rejects the idea that good enterprise software can fast enough without needing to scale. Which I disagree with.

Reply on news.ycombinator.com