Benefits of Microservices Architecture

A microservices architecture is an architectural style that structures an application as a set of smaller services that are:

• Highly maintainable and testable
• Independent
• Loosely coupled
• Organized around specific business or domain capabilities
• Each one scoped to a single purpose

Each service runs in its own process and communicates with the others through a well-defined interface, typically an HTTP-based API.

The microservice architecture it's a good way to follow in case of rapid, frequent and reliable delivery of complex applications.

A microservice architecture is recommended in the following cases:

• difference in the frequency of updates: it is the case in which different components of an application need to evolve with different frequency. For example, in the case of an e-commerce, we may have to make continuous improvements on the search engine, but few improvements on the cart: it is appropriate to split the two modules into two separate microservices then, and assign the development of these two microservices to different team members, so that the two teams can operate totally independently of each other.

• independent lifecycles: lifecycle means the flow that leads from commit to production. If one module has to be brought into production faster than another, or one requires very long regression tests, then it is appropriate to split them.

• independent scalability: if different modules of the same system must support different traffic or throughput, then they must have different scalability requirements. If we put everything in a monolithic application, we would have to scale the entire application to support the most volatile component, and this would lead to an over-allocation of resources!

• failure isolation: it is the case in which there is a dependence on an external system. It may happen that this service is not available and appropriate failover mechanisms must be implemented to ensure that this unavailability does not spill over the whole system but only the related microservice. Another solution is to create an abstraction layer between the microservice and the external service (facade pattern) so that, if the external service is replaced by another in the future, there is no need to edit the whole microservice.

• independent frameworks and languages: you can use different frameworks or programming languages to write microservices and deploy them independently.