Microservices vs Service Oriented Architecture (SOA)

At first glance, Microservice architectures appear suspiciously similar to software developers who are familiar with Service-Oriented Architecture or SOA. In general, they both provide solutions to avoiding the creation of inefficient, unwieldy monolithic or layered applications that are difficult to develop, modify and deploy. However, each has distinctly different approaches in terms of scalability, messaging and how services are coordinated. These differences govern the areas where each approach is most applicable.

SOA Today

The SOA architectural pattern evolved over decades. It is an approach to organizing complex amalgamations of enterprise-level software into collections of interdependent services. Most commonly, it uses Web Services technologies for service communication such as SOAP or REST. JSON is also a popular choice in service communication protocols.

SOA commonly relies on a shared data model with multiple hierarchies and complex relationships between dozens or hundreds of data structures and services. It uses a tiered organizational architecture that contains a centralized messaging middleware for service coordination plus additional messaging functionality.


Microservices are a service-oriented architectural pattern as well for defining distributed software architectures. The pattern aims for better scalability, decoupling and control throughout the application development, testing and deployment cycle. It also relies on an inter-service communication protocol, which could be SOAP, REST, JSON, MSMG or a number of other technologies. Beyond these similar characteristics, the differences between SOA and Microservices become more apparent.

Decoupling of Services

Because SOA is based on a philosophy of sharing as much as possible between services, e.g. databases, it tends to create tight data coupling between services and other system components, which increases its resistance to changes. If, for example, the schema of data stored in a database shared by multiple services changes, any service built upon that schema, even if it does not access the modified data, must be re-tested to ensure the change has not negatively affected the service.

Microservices, however, are built upon a concept known as a bounded context, which leads to a self-contained association between a single service and its data. Although the sharing of services cannot be completely eliminated using Microservices, it is meaningfully minimized. Where sharing is required, it might be avoided by the replication of common functions across services rather than using data sharing. This inherent data decoupling facilitates more frequent deployments and reduces testing scope.

Coordination of Services

SOA typically employs a central hub controller to maintain an orderly execution of services. Microservices, on the other hand, rely solely on inter-service communication. Each microservice calls another microservice as required to complete its function. Furthermore, called microservices may call other services as needed in a process known as service chaining. Too much chaining, however, implies a non-beneficial degree of functional coupling, which should be avoided.

Messaging Middleware vs. API Layer

These distinct execution/coordination models result from fundamental macro-architecture differences between SOA and Microservices. SOA relies on a central messaging middleware layer in a 4-tier model, whereas Microservices use a non-coordinating API layer over the services composing an application.

Although SOA’s use of a centralized messaging layer enables additional capabilities such as message transformation, mediation and routing, it leads to increased complexity plus elevated data and functional coupling, which raises maintenance and deployment costs.

Microservices utilizing a relatively simpler API layer leverage it as an abstraction layer to the services consumer. The granularity of services or their internal data representations, for instance, can be easily changed without any modifications required of the requesting application on the other side of the API layer.


There are further distinctions between SOA and Microservices with additional implications in terms of their suitability for different kinds of applications and runtime environments. SOA was created to address the integration of an array of heterogeneous applications in sizeable, complex, enterprise systems where services are shared across applications and functions. It still serves well in this capacity.

Microservices are more appropriate than SOA for smaller, web-based applications that do not require explicit service coordination and have a minimum of shared components. They permit “goldilocks” adjustment of granularity and highly independent services. This model integrates well with continuous deployment models of software development.

Of course, the two approaches are not mutually exclusive. A Microservice approach enables an organization to quickly deliver an agile application, which, as needs require, can morph into an SOA-style architecture. Likewise, an SOA-based system may benefit in terms of maintenance and performance when applying Microservices principles to a re-factorization of its services or architecture.