3 ms·

Do you mean horizontal scaling? Throwing more machines and cores at your system and distributing work across additional nodes?

ricketycricket 4y ago
Both vertical and horizontal are pretty simple with Elixir and are done in essentially the same way.
- Jtsummers 4y ago
  Almost every system scales simply vertically, vertical scaling is (to a first approximation) throwing faster hardware at the problem. If you're IO bound you get a faster IO bus (this is not necessarily easy to do, but if you do it the system scales to the limit of it). If you're CPU bound you get a faster CPU. And so on. Horizontal scaling is what's hard for a lot of systems, but simple with Erlang and Elixir since they are, by design, meant to support concurrent and distributed workloads. That's why I was asking if they meant horizontal and not vertical. Erlang and Elixir are not uniquely easy to scale horizontally, but they are (if you don't fight their nature and produce programs that consist of one giant execution thread) ridiculously easy to scale horizontally by tacking on additional CPU cores or physical CPUs.
  - evadne 4y ago
    WhatsApp did a lot of work in this area, and I would encourage folks who are interested to seek out information related to that. 2014 - https://www.infoq.com/presentations/whatsapp-scalability/ https://www.infoq.com/presentations/whatsapp-scalability/ There is also Lasp, which is very interesting: https://lasp-lang.readme.io/docs https://lasp-lang.readme.io/docs
  - killthebuddha 4y ago
    I think it makes a lot of sense in theory to consider adding CPUs as horizontal scaling, but in practice I'm not sure it makes sense. Moving your app to a machine with twice as many CPUs is more like moving it to a machine with twice as much RAM than it is like doubling the number of machines your app is deployed to.
  - ricketycricket 4y ago
    > Almost every system scales simply vertically, vertical scaling is (to a first approximation) throwing faster hardware at the problem. If you're IO bound you get a faster IO bus (this is not necessarily easy to do, but if you do it the system scales to the limit of it). If you're CPU bound you get a faster CPU. And so on. My interpretation was vertical scaling is within a single node and adding cores or CPUs to a single node is vertical. Multi-core and multi-node really present similar problems, so adding more cores or adding more nodes isn't terribly different from a design perspective. > ...easy to scale horizontally by tacking on additional CPU cores or physical CPUs. If you define adding more cores to a single machine is actually horizontal scaling, then we agree in principle, just not in the definition of scaling.
  - sph 4y ago
    > Almost every system scales simply vertically Not true in practice. You can scale hardware easily to hundreds of cores, if your app is able to spread the load, but the performance ceiling is very low if your app is single-threaded. The BEAM with its design is very parallel, and the more cores, the happier it is.
killthebuddha 4y ago
I meant vertical scaling, but it sounds like our understanding of vertical scaling is different. My framing is "horizontal scaling = more machines, vertical scaling = more powerful machines". I guess one way to think about it is that Elixir makes scaling the number of cores a strictly vertical kind of scaling.
- Jtsummers 4y ago
  Yeah, additional cores is a fuzzy area. That's why I asked. Elixir takes advantage of additional cores trivially, so upgrading a CPU (how many people see vertical scaling) to have additional cores helps your Elixir workload. But it's doing that by distribution (more typically falls under horizontal scaling) across those additional cores. Again, it's fuzzy. When the world consisted of mostly 1-4 core CPUs it was easier to separate the two concepts because we didn't have the option of throwing 128 cores into a single server, we had to buy 32 to 128 servers to get that many CPUs.
  - namaria 4y ago
    I've always assumed horizontal scaling implies a network interface between new sets of cores. That in my view would provide a very sharp definition.
    - deleted 4y ago
      [deleted]

ricketycricket 4y ago

Both vertical and horizontal are pretty simple with Elixir and are done in essentially the same way.

Jtsummers 4y ago
Almost every system scales simply vertically, vertical scaling is (to a first approximation) throwing faster hardware at the problem. If you're IO bound you get a faster IO bus (this is not necessarily easy to do, but if you do it the system scales to the limit of it). If you're CPU bound you get a faster CPU. And so on. Horizontal scaling is what's hard for a lot of systems, but simple with Erlang and Elixir since they are, by design, meant to support concurrent and distributed workloads. That's why I was asking if they meant horizontal and not vertical. Erlang and Elixir are not uniquely easy to scale horizontally, but they are (if you don't fight their nature and produce programs that consist of one giant execution thread) ridiculously easy to scale horizontally by tacking on additional CPU cores or physical CPUs.
- evadne 4y ago
  WhatsApp did a lot of work in this area, and I would encourage folks who are interested to seek out information related to that. 2014 - https://www.infoq.com/presentations/whatsapp-scalability/ https://www.infoq.com/presentations/whatsapp-scalability/ There is also Lasp, which is very interesting: https://lasp-lang.readme.io/docs https://lasp-lang.readme.io/docs
- killthebuddha 4y ago
  I think it makes a lot of sense in theory to consider adding CPUs as horizontal scaling, but in practice I'm not sure it makes sense. Moving your app to a machine with twice as many CPUs is more like moving it to a machine with twice as much RAM than it is like doubling the number of machines your app is deployed to.
- ricketycricket 4y ago
  > Almost every system scales simply vertically, vertical scaling is (to a first approximation) throwing faster hardware at the problem. If you're IO bound you get a faster IO bus (this is not necessarily easy to do, but if you do it the system scales to the limit of it). If you're CPU bound you get a faster CPU. And so on. My interpretation was vertical scaling is within a single node and adding cores or CPUs to a single node is vertical. Multi-core and multi-node really present similar problems, so adding more cores or adding more nodes isn't terribly different from a design perspective. > ...easy to scale horizontally by tacking on additional CPU cores or physical CPUs. If you define adding more cores to a single machine is actually horizontal scaling, then we agree in principle, just not in the definition of scaling.
- sph 4y ago
  > Almost every system scales simply vertically Not true in practice. You can scale hardware easily to hundreds of cores, if your app is able to spread the load, but the performance ceiling is very low if your app is single-threaded. The BEAM with its design is very parallel, and the more cores, the happier it is.

killthebuddha 4y ago

I meant vertical scaling, but it sounds like our understanding of vertical scaling is different. My framing is "horizontal scaling = more machines, vertical scaling = more powerful machines". I guess one way to think about it is that Elixir makes scaling the number of cores a strictly vertical kind of scaling.

Jtsummers 4y ago
Yeah, additional cores is a fuzzy area. That's why I asked. Elixir takes advantage of additional cores trivially, so upgrading a CPU (how many people see vertical scaling) to have additional cores helps your Elixir workload. But it's doing that by distribution (more typically falls under horizontal scaling) across those additional cores. Again, it's fuzzy. When the world consisted of mostly 1-4 core CPUs it was easier to separate the two concepts because we didn't have the option of throwing 128 cores into a single server, we had to buy 32 to 128 servers to get that many CPUs.
- namaria 4y ago
  I've always assumed horizontal scaling implies a network interface between new sets of cores. That in my view would provide a very sharp definition.
  - deleted 4y ago
    [deleted]