Deploying an MSA provides some important benefits:

• Single responsibility: Each microservice should cover a well-defined business domain—the domain-driven design (DDD) approach can help developers build software that adheres to this concept to obtain an autonomous and atomic system.
• Explicitly published interface: A producer service publishes an interface that is used by a consumer service. This is one of the most important points because the published interface represents the contract between the producer and the consumer—once the interface has been published, the API should not be modified. A new version of a contract must be followed by a new version of the interface to avoid unpredictable impacts to the service consumers.
• Independent deploy, update, replace, and scale (DURS): A business domain could be made by a different set of microservices. To guarantee the continuity of business services, both in the case of issues or a new release version of one of the microservices that make up the suite, each service should be independently deployed, updated, replaced, and scaled.
• Isolation: This is a prerequisite for resilience and elasticity. A microservice should share nothing with other microservices. In this way, it's easier to scale each service as well as allowing each of them to be monitored, debugged, and tested independently. It could also enable fault isolation to avoid issues with the entire business channel if only one microservice is affected by a problem. An issue, for example, an unclosed database connection or a memory leak, must impact only the faulty service and not the entire application. Using this strategy, you will be able to isolate the fault to a single service, avoiding propagating it to the rest of the suite.

• Diversified technology: As I described earlier, MSA divides a complex domain into smaller contexts that are followed by dedicated teams. These teams are completely independent of each other and, for this reason, are able to choose the best technology to implement the microservice based on their skills, the business requirements, the strategic choices made by the company, and so on.
• Smart endpoints and dumb pipes: Each microservice owns its domain logic but it should not cover a big context. The domain must be atomic but small and well-defined. Also, the communication protocol must be simple—at the moment, the de facto standard is represented by RESTful over HTTP.

• Independent scaling: Each microservice can scale independently with different strategies—horizontal scaling and vertical scaling—based on what is needed. This is a different approach than that in monolithic applications, which may have different requirements and must be deployed as a single unit (e.g., Enterprise Application Archive (EAR) and Web Application Archive (WAR)).
• Improved communication across the team: A microservice is typically built by a full-stack team that has all the necessary skills. All members work as a single team, with the same objectives, significantly improving the quality of what they build. They remain wholly responsible for a project, even in the production environment, ensuring quality in the project life cycle both in terms of technological evolution and monitoring.
• Independent upgrades: Each service should be deployed independently from other services. In this way, a developer can decide to revisit the underlying implementation of the system without the risk of impacting other parts of the suite of services. The use of continuous integration (CI)/continuous delivery (CD) can help automate the process of checking code quality and releasing new software versions with confidence.

After listing all of these positive aspects, can we say that microservices are the ideal solution in any scenario? The honest answer is no.

Microservices are not the magic potion that will solve all the architectural problems in your applications. They also require significant investment in terms of resources and skill acquisition.

In the next section, we will summarize the drawbacks so that we have all the elements to make the right choice for our project.