5 ms·

> Horizonal scalability is simply a band-aid for poor engineering in most (not all) applications. Maybe if your app handles < 10k concurrent connections. Other

by yonixw 6y ago

> Horizonal scalability is simply a band-aid for poor engineering in most (not all) applications. Maybe if your app handles < 10k concurrent connections. Otherwise it is the most cost efficient solution and exists because it solves the scaling problem in the best way as of today.

pjmlp 6y ago
VMs also autoscale.
rbanffy 6y ago
When you approach the limits of what your kernel can handle, then it may be time to split your workload across boxes or to carve smaller boxes out of your metal (and probably directly attaching NICs to the VMs to the host OS doesn't have to deal with them). Making your workload horizontally scalable is always a sound engineering choice. But... Splitting a horizontally scalable workload across a dozen virtual servers that are barely larger than the smallest laptop you can get from Best Buy, you are just creating self-inflicted pain. Chances are the smallest box you can get from Dell can comfortably host your whole application. The fact remains the odds of you needing to support more than 10K simultaneous connections are vanishingly small.
- yonixw 6y ago
  > When you approach the limits of what your kernel can handle Even before. If you want low latency. And banks handle more than 10K concurrent every day. Cost example: https://pt.slideshare.net/markmyers106/vertical-vs-horizontall/5 https://pt.slideshare.net/markmyers106/vertical-vs-horizonta...
  - ThinkBeat 6y ago
    Yes some banks need it As do giants like Google Facebook etc Chances are very high that the problem domain you are working in does not. Like the author said “1%” I think maybe 5% to 7% The point being that masses of software is developer everyday on a cargo cult adoption of solution they do not require.
    - Enginerrrd 6y ago
      >The point being that masses of software is developer everyday on a cargo cult adoption of solution they do not require. This is certainly true, but there is a possible benefit: standardization. Having a standard skillset allows employees greater flexibility since they can jump employers and still expect to be rapidly useful. Similarly, if your company uses a standard toolkit, there's going to be less training overhead for new hires. Now, the devil is in the details, and I'm inclined to agree that you'd be better off hiring someone that can think outside the box and keep the tooling simpler. But using the standard toolkit will work reasonably well across several orders of magnitude in scale.
bestinterest 6y ago
Does anyone know of any raw stats at what one beefy server can handle with a typical HTTP CRUD app? <10k doesn't seem right?
- NorwegianDude 6y ago
  10k concurrent idle connections is no problem, but 10k/rps is a decent amount of traffic. What is a typical CURD app? It really depends on what software you're using too. You can do >10k/rps with DB read/write on every request with PHP on a lowend server, but if you throw a heavy framework into the mix then that would not be possible.
slt2021 6y ago
agree with you, when you say cost efficient it means - that we can scale out our poorly written slow software to more servers to handle increased traffic, instead of hiring more expensive engineers and rewriting software properly than could handle increased load from a single instance
wbl 6y ago
10k? It's not 1999 anymore. Look at Netflix to see the state of the art in saturating NICs with commodity hardware and off the shelf NGINX plus FreeBSD.

by yonixw 6y ago

pjmlp 6y ago

VMs also autoscale.

rbanffy 6y ago

When you approach the limits of what your kernel can handle, then it may be time to split your workload across boxes or to carve smaller boxes out of your metal (and probably directly attaching NICs to the VMs to the host OS doesn't have to deal with them). Making your workload horizontally scalable is always a sound engineering choice. But... Splitting a horizontally scalable workload across a dozen virtual servers that are barely larger than the smallest laptop you can get from Best Buy, you are just creating self-inflicted pain. Chances are the smallest box you can get from Dell can comfortably host your whole application. The fact remains the odds of you needing to support more than 10K simultaneous connections are vanishingly small.

yonixw 6y ago
> When you approach the limits of what your kernel can handle Even before. If you want low latency. And banks handle more than 10K concurrent every day. Cost example: https://pt.slideshare.net/markmyers106/vertical-vs-horizontall/5 https://pt.slideshare.net/markmyers106/vertical-vs-horizonta...
- ThinkBeat 6y ago
  Yes some banks need it As do giants like Google Facebook etc Chances are very high that the problem domain you are working in does not. Like the author said “1%” I think maybe 5% to 7% The point being that masses of software is developer everyday on a cargo cult adoption of solution they do not require.
  - Enginerrrd 6y ago
    >The point being that masses of software is developer everyday on a cargo cult adoption of solution they do not require. This is certainly true, but there is a possible benefit: standardization. Having a standard skillset allows employees greater flexibility since they can jump employers and still expect to be rapidly useful. Similarly, if your company uses a standard toolkit, there's going to be less training overhead for new hires. Now, the devil is in the details, and I'm inclined to agree that you'd be better off hiring someone that can think outside the box and keep the tooling simpler. But using the standard toolkit will work reasonably well across several orders of magnitude in scale.

bestinterest 6y ago

Does anyone know of any raw stats at what one beefy server can handle with a typical HTTP CRUD app? <10k doesn't seem right?

NorwegianDude 6y ago
10k concurrent idle connections is no problem, but 10k/rps is a decent amount of traffic. What is a typical CURD app? It really depends on what software you're using too. You can do >10k/rps with DB read/write on every request with PHP on a lowend server, but if you throw a heavy framework into the mix then that would not be possible.

slt2021 6y ago

agree with you, when you say cost efficient it means - that we can scale out our poorly written slow software to more servers to handle increased traffic, instead of hiring more expensive engineers and rewriting software properly than could handle increased load from a single instance

wbl 6y ago

10k? It's not 1999 anymore. Look at Netflix to see the state of the art in saturating NICs with commodity hardware and off the shelf NGINX plus FreeBSD.