SOA versus MSA

Service-oriented architecture is a way to design software where the business services communicate through a standard communication protocol, usually Simple Object Access Protocol (SOAP), over a network. The main target of an SOA is to be independent of vendors, products, and technologies. The principal unit of an SOA is the service—a small unit of functionality that can be accessed remotely, and acted upon and updated independently.

The communication between services happens via direct exchange of data or it could involve two or more services that are coordinated by an orchestrator, Enterprise Service Bus (ESB) that is responsible for managing the execution flow.

There are two main roles in an SOA—a service provider and a service consumer. The first one is the service that's defined within the SOA while the second one is the point where consumers interact with the SOA. In addition, the data storage is shared within all services in an SOA.

The problem, however, is that an SOA is usually associated with an ESB, which is used to integrate monolithic applications—it is identified as a complex architecture, difficult to scale, and extremely coupled with proprietary vendor solutions. So it's sometimes difficult to think about SOAs in a positive manner.

After massive dissemination and utilization of SOA platforms at the beginning of the 2000s, there was a slow and progressive decline of this architecture due to the reasons we described earlier.

However, MSAs can be seen as an evolution of SOAs—many of the techniques defined in microservice specifications were born and consolidated from the experiences of developers who used them in large enterprise organizations using service-oriented architecture and patterns. For this reason, MSAs are receiving increasingly positive feedback from the community and their use is rapidly expanding among enterprise companies.