What is scalability anyway? | Hacker News Reader

What is scalability anyway?

brooker.co.za

49 pointsr4um9 comments

> A system is scalable in the range where the cost of adding incremental work is approximately constant.

The part that nobody ever says out loud: and where the cost of removing incremental work is also approximately constant.

A solution targeting server or desktop environments doesn’t necessarily scale down to microcontroller scale. One of the things that makes both SQLite and Linux so popular is how they scale well into really small environments.

Define "small" - cost of physical dimensions, independence of operation, or cost of near-zero usage. For example, S3 and Lambda are basically free for usage with near-zero traffic, but of course you give up independence.

Arguably more important than microcontroller scale, these days, is whether it runs well on Android. The cost of manufacturing custom hardware is enormous, but piggybacking off the Android ecosystem can often eliminate most of the need for custom hardware. Of course, Android is a very different target than Linux...

> Define "small" - cost of physical dimensions, independence of operation, or cost of near-zero usage.

All three and possibly more. I think it all depends on what you're doing.

> For example, S3 and Lambda are basically free for usage with near-zero traffic

Just to build on this a little bit, even this has limits: if your operating environment has extremely lower power availability (so, low available bandwidth), maybe S3 has too much data transfer overhead!

Scaling from a PC to a MCU is not incremental work.

This is a nice treatment, but I think it omits one other option which is a variation of the first option, if you like: "vertical scaling". When the load exceeds what can be done by the single box that you already bought, just buy a bigger single box that can do more. Yes, often that won't work and it will, as the author says, require a complete rethinking of the architecture of the system, but often it will not.

Exactly.

It isn’t a dichotomy between flat step segments punctuated with spikes vs pure linear growth (where someone else has taken the spike hits for you).

It is linear growth segments punctuated with spikes, vs. raised linear growth without spikes.

In practice, spikes won’t be completely eliminated. Even with the most seamless cloud solutions, some rearchitecting is likely.

Also, I interpret the cost graphs as measuring the combined effort, time & risk costs. I.e. spikes represent both predictable & unpredicted efforts and delays.

The delays perhaps being the best reason to pay (linearly) more per capacity, since delays negatively impact (ideally super linear) business growth.

Scalability is adapting the characteristics of your instances to demand increase or decrease. You can adapt the number of instances (horizontal) or adapt the CPU, RAM, I/O characteristics of every single instance (vertical).

A basic rule of thumb I try to follow is: as long as you have at least two instances, don't immediately think about hundreds or thousands of instances for spikes that will never exist. Scaling from 1 to 2 (to remove SPOF) is much harder than scaling from 2 to 3, or 20. You have already removed some implicit "localhost" assumptions.

Of course, the two instances rule is for stateless components. For stateful systems you want at least three. But even then, you'd be surprised by how much stuff you can run on 2-3 decently sized virtual machines and a load balancer.

I want to believe the title of this post is a flcl reference.

This is the timeline I choose to live in.

Reply on news.ycombinator.com