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.

Introduction To Microservices Architecture

The Motivation for Microservices

Separating the various components of a single application’s architecture carries a number of well-known advantages. For one, the components can be distributed among several members of a development team, which increases the ability to deliver the application more quickly. With well-defined interfaces between the components, developers and testers increase their focus and efficiency via a reduction in the scope of functionality with which they must work.

Componentization of applications also increases their robustness. Should one component fail, for instance, the remainder of the application can continue to function while the errant component is restarted. This generally has a very positive effect on the app’s user experience versus a full crash/reboot of a non-componentized application.

Another advantage is the opportunity to distribute the execution of the application’s components across multiple physical or virtual execution environments. Not only does this further increase resilience but it usually improves performance and scalability. Depending on what the app does and how the decomposition is done, it is possible to duplicate only particular components instead of the entire app to further improve efficiency.

Finally, microservices offer an opportunity that goes hand-in-hand with the goals of continuous delivery of software. They improve defect repair turnaround time and the ability to deliver rapid updates or new functionality by component replacements versus re-deploying an entire application.

Are Microservices a New Concept?

The overall concept upon which microservices are based is not fundamentally new. SOA, which shares many of the same characteristics and goals, has been in use for decades in one form or another. If you prefer, think of microservices as a refinement of SOA.

Microservices are typically produced on a smaller scale than SOA however. SOA is typically used to employ intercommunication between suites of large enterprise applications in an Enterprise Service Bus configuration, whereas microservices are more compact and utilize fast messaging for communication between themselves.

Microservices were developed to serve end users who increasingly demand that their apps and services be highly scalable, modular, responsive and adaptable than the typical SOA implementation. They are also more suited for today’s diverse mobile device environment to which wearables and IoT are quickly being added. Additionally, with microservices, new tools and techniques are being employed to deliver reduced development time and more resilient runtime operation.

Microservices Enabling Technologies

Besides a specialized approach to the fundamental concepts behind SOA, microservices projects typically utilize specific technological approaches including the preferred use of open source code and container technologies.

Small, component decompositions that enhance the ability to tweak apps on the fly makes dealing with licensed proprietary libraries impractical. Furthermore, due to the requirement that components carry their own API, sharing of components across applications becomes much easier, which would be negatively impacted within a backdrop of licensing issues.

Container technologies, such as Docker, are ideal tools for the microservices world. Containers essentially allow microservices to run as separate apps with their own allocations of CPU, memory and network resources independent of other microservices. Containers are not a requirement for microservice implementation, however, but they often improve portability across infrastructures.

More Than a Technology

It is important to bear in mind that microservices require more than just technology but a different development mindset too. The decomposition, for instance, of an application using microservices is more often based on business needs than architectural/technological concerns.

Rather than, say, dividing the app according to its UI, database and networking layers, it is a better, customer-oriented, approach to partition the app according to the functional requirements of the end user. Because of this characteristic and the small-size granularity of microservice development, their use often thrives in organizations using agile development methodologies and especially in DevOps environments.

Microservice development is not standardized, at least not yet. It is more accurate to call it an emerging architectural philosophy much as SOA was even before it acquired a name. They are changing the concept of what an application is. Microservice apps, which are more or less a framework for running the components that is built upon are a different animal than the single-block, monolithic apps of the past.

At the end of the day, the microservice concept simply makes creating robust, scalable and versatile applications easier. It also improves their resilience, testability and maintainability even post-delivery. The technique is particularly suited to continuous deployment processes that are required to compete in the fast-changing world of new devices and “things” coming online at an exponential pace.

Portfolio Items