Microservices are an architectural pattern for organizing your application according to business domains. For more information on microservices, please see https://martinfowler.com/articles/microservices.html. Classic examples that are usually provided for microservices are how customer, movies, and recommendation services are implemented. Customer service simply deals with customer details, and has no information about movies. The movies service deals with movie details and nothing more. The recommendation engine service deals with recommendations only, and, given a movie title, will return the movie that are closely related. 

One of the main selling points of microservices is strengthen independence. Services are designed to be small enough (hence the name micro) to handle the needs of a business domain. As they are small, they can be made self-contained and independently testable, and so are independently releasable. With the use of proper contract tests, each team can rollout their release on their own schedule, without the need for handoffs.

Graceful degradation is another benefit of microservices. If the recommendation engine is not functioning, the customer will still be able to log in and watch movies.

Independent scaling is another benefit that is mostly useful for systems with heavy users. In our example, if more requests are coming in for recommendations, our service can be scaled up without scaling up other services.

Each service can be built with the right language of choice. For high performance, the Rust language can be used, or the development team might even be more comfortable developing in Python. As long as they expose REST services, they can be deployed with services written in any other language.

Blue/green deployment and rolling updates are also made possible by the use of microservices. You can deploy the upgraded service and check whether or not they are working, and then push all the new requests to the upgraded service. The requests to the old service can be drained. The preceding deployment is called blue/green deployment. If something goes wrong, the upgraded service is downscaled, and the customers experience almost no downtime. Rolling updates are similar, where the old pods are slowly replaced with the new pods and the process is reversed if something goes wrong.

Since services are kept small, they can be rewritten quickly in case the initial implementation is wrong. Composable services, such as aggregator services, can be built on top of existing services to speed up development. Microservices bring back the old Unix philosophy of doing one thing, and doing it well. Composability is the method of integrating services rather than stuffing everything in one service.