I recently read Sam Newman’s book “Building Microservices: Designing Fine-Grained Systems.”

After reading this book, phrases kept spinning in my head: “paradigm shift,” “disrupt,” “the next big thing.” Most of you are on the other side of the browser and have little interest in the development of internet technologies. And they are changing a lot. So much that in 10 years the only thing that has stayed the same is the HTTP protocol, while everything else has changed: web servers, databases, web application architectures, testing, integration, and deployment methods.
Microservice architecture is an organization of a system where each subsystem is an autonomous, independent web service responsible for one small task. The complete opposite is monolithic architecture, where there is only one web service that handles all tasks.
In a microservice architecture, each microservice is developed, deployed, and scaled in isolation from other services. This means the chosen technology stack is no longer a life sentence. For example, the LAMP stack — Linux, Apache, MySQL, PHP — was popular for ten years. Previously, all these technologies were installed as part of a single web service. And if a new feature needed to be developed, they would look for a specialist who knew these technologies. But in a microservice architecture, one microservice can be implemented in Ruby, another in Go, a third in Java. One can have MongoDB as its database, another GraphDB, and a third a blob store, for example. And that’s normal. Choose the language and database that will solve the specific task most effectively.

Previously, if a web service couldn’t handle the load, you would do horizontal scaling: launch another instance of the LAMP service and set up load balancing. In a microservice architecture, you can analyze the performance of each individual microservice and scale only the microservice that isn’t coping with the load.
Reading the book, I remembered where I, as a user, had encountered microservices. I remember once going to Facebook: the news feed was there, but I couldn’t view private messages. That means Facebook has at least two microservices (in reality, hundreds of them) — the news feed microservice and the private messages microservice. And that day the messages microservice went down. The advantage is that the other microservices kept working, because they operate autonomously. In a monolithic architecture, that is impossible: the failure of one subsystem leads to the failure of the entire system.
I strongly recommend “Building Microservices” to all CTOs and just plain developers.