Off-topic, but what?! I understand there is a lot of hype about "microservices" right now but I don't think the upsides of the propagated approach are as clear-cut or uncontroversial as the post makes them out to be.
The article defines "microservices" as the act of splitting up an application into many small, individual programms that talk to each other via RPCs.
How does structuring my code into lots of small programs improve revenue of all things? Or are you talking about the revenue of code repository hosting providers and "microservices" consultants?
Also, this approach surely does not improve resiliency and efficiency per se. It actually does the opposite in my opinion. All the additional RPCs are only adding _more_ points of failure (unreliable IPC) and overhead as compared to straight in-process method calls.
And who's saying that "a microservices architecture" improves a dev teams "agility"? How does one even measure agility? The article is stating this like it's an established fact. In my [anecdotal] experience, spreading an application out over lots of individual repositories and binaries makes it harder to work with, not easier.
>> With such tangible business benefits, it is no wonder why Google, Amazon, and Facebook have been using microservice development practices for over a decade.
The fact is that these are a massive software companies with thousands of engineers. Naturally they run an incredible amount of internal software and services. I think this is often conflated with the idea that splitting up a given application into smaller and smaller parts to produce more individual "services" automatically makes it better somehow.
Don't get me wrong. I'm all for having a clear seperation of concerns and well defined interfaces between individual modules. Doing that has been best practice since I started to code. But the latest "let's split our codebase up into 20 different binaries and repos, because microservices" fad is just bonkers.