3 ms·

> We will debunk these fallacies in the next posts one by one. The next post I will start with the first fallacy, the very widespread fallacy that you need micr

by mrkeen 2y ago

> We will debunk these fallacies in the next posts one by one. The next post I will start with the first fallacy, the very widespread fallacy that you need microservices for scalability reasons. Stay tuned … > The microservices fallacy - Part 2 > Scalability > A simple LAMP stack server [...] can serve up to 300.000 concurrent users > you can dynamically add and remove additional nodes behind a simple load balancer and with 10 LAMP stack nodes and a single load balancer you can serve up to 3.000.000 concurrent users. Brilliant. Why didn't I think of using ten MySQLs instead of one to get a 10x throughput multiplier.

CharlieDigital 2y ago
Typically, this means scaling application servers and can be done easily with platforms like Elastic BeanStalk or Cloud Run to scale your app servers based on selected metrics. Database server nodes can be swapped for larger ones if needed using a different strategy. (Many folks underestimate how well a well-designed relational DB can scale on bigger CPU/RAM/storage throughput and better indexes). The author's suggestion does not mean to increase the number of database instances since it would not make sense to remove them dynamically.
- mrkeen 2y ago
  In other words, if your world view is that you will never scale out your database beyond n=1, then microservices being part of the scaling-out journey is indeed a fallacy.
  - CharlieDigital 2y ago
    Also probably not the case. In most cases, systems can scale reads with replicas and queue writes to a write instance. You can also shard if write throughput needs to be higher. Many of the most popular services scaled this way before (if even) adopting more complex solutions. StackOverflow[0] and Pinterest[1] are examples. You can scale your database beyond n=1 in different ways without scaling fully independent, isolated instances. [0] https://highscalability.com/stack-overflow-architecture/ https://highscalability.com/stack-overflow-architecture/ [1] https://highscalability.com/scaling-pinterest-from-0-to-10s-of-billions-of-page-views-a/ https://highscalability.com/scaling-pinterest-from-0-to-10s-...
nchmy 2y ago
Forget the architecture - I take significant exception to the basic arithmetic of these posts... Here's what they say > A simple LAMP stack server on an average 5.000 EUR server can – configured correctly – easily serve up to 6.000 requests simultaneously, probably even more if you use NGINX instead of Apache, because you do not hit the thread limit. > Now let us assume that a request takes 200ms to complete at the 99th percentile and that each user interacting with your offering sends a request every 10s in average. This means that you can serve up to 300.000 concurrent users, i.e., users that interact with your offering at the same time with a single LAMP stack node (6.000 * (10s / 200ms)). The server they reference has 20 cores. Let's say 40 threads. No LAMP (or probably any) stack is serving 6000 requests simultaneously on that, unless it's just a static html file (in which case they could serve considerably more). They're implying 6000/40=150 php workers per thread. That's insanity. The cache thrashing and context switching that would happen would make it so each page would take minutes to load.

by mrkeen 2y ago

CharlieDigital 2y ago

Typically, this means scaling application servers and can be done easily with platforms like Elastic BeanStalk or Cloud Run to scale your app servers based on selected metrics. Database server nodes can be swapped for larger ones if needed using a different strategy. (Many folks underestimate how well a well-designed relational DB can scale on bigger CPU/RAM/storage throughput and better indexes). The author's suggestion does not mean to increase the number of database instances since it would not make sense to remove them dynamically.

mrkeen 2y ago
In other words, if your world view is that you will never scale out your database beyond n=1, then microservices being part of the scaling-out journey is indeed a fallacy.
- CharlieDigital 2y ago
  Also probably not the case. In most cases, systems can scale reads with replicas and queue writes to a write instance. You can also shard if write throughput needs to be higher. Many of the most popular services scaled this way before (if even) adopting more complex solutions. StackOverflow[0] and Pinterest[1] are examples. You can scale your database beyond n=1 in different ways without scaling fully independent, isolated instances. [0] https://highscalability.com/stack-overflow-architecture/ https://highscalability.com/stack-overflow-architecture/ [1] https://highscalability.com/scaling-pinterest-from-0-to-10s-of-billions-of-page-views-a/ https://highscalability.com/scaling-pinterest-from-0-to-10s-...

nchmy 2y ago

Forget the architecture - I take significant exception to the basic arithmetic of these posts... Here's what they say > A simple LAMP stack server on an average 5.000 EUR server can – configured correctly – easily serve up to 6.000 requests simultaneously, probably even more if you use NGINX instead of Apache, because you do not hit the thread limit. > Now let us assume that a request takes 200ms to complete at the 99th percentile and that each user interacting with your offering sends a request every 10s in average. This means that you can serve up to 300.000 concurrent users, i.e., users that interact with your offering at the same time with a single LAMP stack node (6.000 * (10s / 200ms)). The server they reference has 20 cores. Let's say 40 threads. No LAMP (or probably any) stack is serving 6000 requests simultaneously on that, unless it's just a static html file (in which case they could serve considerably more). They're implying 6000/40=150 php workers per thread. That's insanity. The cache thrashing and context switching that would happen would make it so each page would take minutes to load.