FTA the author says some claims they insist are fallacies. Two stood out to me as being factual rather than fallacy.<p>>Microservices improve team autonomy.
Microservices make change of technology easier.<p>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.<p>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.
The truth as always lies somewhere in the middle.<p>Some splitting of a big complex thing makes sense.<p>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.<p>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)
> 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 …<p>> The microservices fallacy - Part 2<p>> Scalability<p>> A simple LAMP stack server [...] can serve up to 300.000 concurrent users<p>> 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.<p>Brilliant. Why didn't I think of using ten MySQLs instead of one to get a 10x throughput multiplier.