&gt;&gt; The rise of microservices, an approach to development in which you structure your software into smaller individual service-oriented units. Each microservice then runs its own process and they communicate with each other through APIs. This software development approach is known to have four primary benefits: agility, efficiency, resiliency, and revenue<p>Off-topic, but what?! I understand there is a lot of hype about &quot;microservices&quot; right now but I don&#x27;t think the upsides of the propagated approach are as clear-cut or uncontroversial as the post makes them out to be.<p>The article defines &quot;microservices&quot; as the act of splitting up an application into many small, individual programms that talk to each other via RPCs.<p>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 &quot;microservices&quot; consultants?<p>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.<p>And who&#x27;s saying that &quot;a microservices architecture&quot; improves a dev teams &quot;agility&quot;? How does one even measure agility? The article is stating this like it&#x27;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.<p>&gt;&gt; With such tangible business benefits, it is no wonder why Google, Amazon, and Facebook have been using microservice development practices for over a decade.<p>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 &quot;services&quot; automatically makes it better somehow.<p>Don&#x27;t get me wrong. I&#x27;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 &quot;let&#x27;s split our codebase up into 20 different binaries and repos, because microservices&quot; fad is just bonkers.