[HN Gopher] What is scalability anyway?
___________________________________________________________________
What is scalability anyway?
Author : r4um
Score : 36 points
Date : 2024-01-19 05:28 UTC (17 hours ago)
(HTM) web link (brooker.co.za)
(TXT) w3m dump (brooker.co.za)
| pdpi wrote:
| > 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.
| solatic wrote:
| 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...
| scott_w wrote:
| > 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!
| morelisp wrote:
| Scaling from a PC to a MCU is not incremental work.
| dventimihasura wrote:
| 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.
| Nevermark wrote:
| 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.
| arter4 wrote:
| 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.
___________________________________________________________________
(page generated 2024-01-19 23:02 UTC)