Why would you make a Microservice
It is definitely worth it for companies like Google to go with microservice architecture. They have very mature tooling; they have been at this for longer than anybody. But you can't take what happens at Google and assume it is something you might want to do.
The scale is wildly different. Why would you take your monolithic application, a single deployable artifact in which modules talk to each other by making function calls, and decide to start making gRPC calls (network calls) instead of function calls?
As the company grows, scaling traffic is usually not an issue. There are very high-scale monoliths out there. What usually happens is that you have a lot of people working on the same code, and they eventually start stepping on each other's toes, not while writing the code, but while rolling it out.
In a situation where nothing ever turns off, things are going to change slowly. A developer writes code, and it rolls out slowly. If you have a few developers, this is manageable; but with 100 or more developers, someone wants to make a change and sees that there's already a deployment ongoing. To solve this, one can plan a Release Train.
Everybody makes their changes over the day, and all these changes together are deployed in a single release.
Now, what happens if one of those changes was bad? If you ship a bug, you have to roll back everybody's change. And this is a strong reason to use microservices:
[You have a large engineering team, and people are stepping on each other since they are making a lot of changes.]
Microservices are a Techincal Debt
They do help you move faster at first. You don't have to get involved in other teams' release processes and development. I wrote my code and got it working; now, just call me over RPC.
The problem is, now that this thing is running, it is part of a call graph, and it has to be up. A lot of microservices theory talks about loose coupling and fallbacks, and if everything has to be up, then maybe it should be a monolith, which may be true.
Everyone, to a certain extent, makes a distributed monolith, whether they realize it or not, unless they really aggressively do fault injection; like all the things have to be up.
It is not black and white. It does help you develop faster, but you have basically borrowed against someone else's productivity in the future. It has a way of making certain kinds of changes more expensive because you need to do multiple deployments across various microservices to make one change.
If we had a way of letting a thousand people make continuous changes while being sure that they are not breaking anything, then we would just simply let them do that, but that is the heart of the problem.
Developer Productivity
Google Cloud's frontend is just one really big single page.
With dozens of services on Google Cloud, thousands of developers work on it, and they encountered the same problem.
If you are going to be deploying a change, one team is going to break something for the other team, and you are going to have to wait days, even weeks.
So they did something very interesting; they made that single page application deployable in independent units, and it was all a matter of developer productivity—it had nothing to do with scale.
It is a single-page application; it will be served in the same way regardless.
Programming principles
One has to be curious about their craft, and as good as the guiding principles are for the uninitiated, for building something, we have to understand where those principles come from and not just that. We also need a good understanding of what we want to build and why.
This helps us be flexible and creative, making decisions best suited for our specific circumstances.
If an application is not able to align with the principles of a true microservice, which most might not, then we need to carefully understand and have the flexibility to bend all the necessary rules. It is not essential that the rules be bent, but that has to be a consideration.