The Microservices Fallacy | Hacker News Reader

The Microservices Fallacy

ufried.com

12 pointskiyanwang12 comments

FTA the author says some claims they insist are fallacies. Two stood out to me as being factual rather than fallacy.

>Microservices improve team autonomy. Microservices make change of technology easier.

I think for 1 to be factual, each service does need to live in it's own repo. Giant mono reporos often don't have a dedicated group of folks to help maintain the health and tooling. But individual repos allow folks to approve and merge w/o explicit reviews from other teams because they are not sharing code, they are sharing API.

And for the second, if you want to tell me it's easier to swap your entire monolith in Play framework to anything else, than it is for me to port 5 stateless endpoints to an arbitrary framework, I'm going to laugh all the way to the finish line.

I had a hard time continuing after the claim that microservices suddenly popped into existence in 2014 due to a blog post, with no mention that EJBs were the micro services of the late-90s/early-00s. I also truly appreciate Martin Fowler’s works, but he too frequently is given credit for things that he simply explained better. That isn’t to say he doesn’t deserve credit for furthering the popularization of certain practices, but people often get it confuse with being the originator of those ideas just because he was the first person they heard about them from.

The truth as always lies somewhere in the middle.

Some splitting of a big complex thing makes sense.

Think where this went wrong isn't smaller orgs copying big tech tech, but rather that they copied it with the same granularity of splits. Not every widget needs to live in a pod with a health check, a metrics sidecar a logging sidecar and horizontal, vertical, diagonal and barrelroll scaling.

Just split it front end, back end and DB or something

The main reasons for micro services (that I didn't see covered) is that it reduces cross team overhead. 10 people working on a service is fine, 100 people working on a service requires processes which slow development down (as no one can keep what is changing in their head)

    > The real case for microservices is to support going fast in highly competitive markets. Microservices support functionally highly independent teams with an architecture style that provides them with complete independence from other teams all along the IT value chain.

This was in part 7 and seems to cover your point.

In fairness to GP, the post argued for this, rather than declaring it as a fallacy.

> 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.

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.

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.

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.

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/

[1] https://highscalability.com/scaling-pinterest-from-0-to-10s-...

(2020)

Reply on news.ycombinator.com