Article by Kim Clarke

SOA vs Microservices vs APIs vs REST

When comparing a microservices architecture and a service-oriented architecture (SOA), it is nearly impossible to gain agreement on how they are related to one another. Adding application programming interfaces (APIs) into the mix makes it even more challenging to understand the differences. Some might say that these concepts are distinct, solve their own set of problems, and have a unique scope. Others might be more generous and say that they achieve similar goals and work from the same principles. They might also say that a microservices architecture is a "fine-grained SOA" or that it is "SOA done right."

This article defines each of these concepts, explains where the varying opinions come from, and tries to find a middle ground. It also examines how these three concepts might be combined going forward.

An over-simplified view

The reason that it is difficult to compare SOA and microservices is that their definitions have a lot of room for interpretation. If you have only a surface-level knowledge of the two concepts, they can sound similar. Key aspects, such as componentization, decoupling, and standardized communication protocols, describe most software initiatives in the last few decades, so we need to dig deeper.

Consider the following simple definitions:

• Microservices Architecture is an alternative approach to structuring applications. An application is broken into smaller, completely independent components, enabling them to have greater agility, scalability, and availability.
• SOA exposes the functions of applications as more readily accessible service interfaces, making it easier to use their data and logic in the next generation of applications.

Figure 1 illustrates these definitions. An SOA appears to have an enterprise scope, where applications communicate with one another. An SOA exposes services through standardized interfaces between applications. The microservices architecture appears to have anapplication scope, with a focus on the structure and components within an application.

Figure 1. Differences between a microservices architecture and SOA

These definitions of SOA and microservices are too simplistic. In fact, the relationship between them is much more complex.

Dichotomy¹ of SOA initiatives

When you look at an SOA in more detail, you can see that its original intent was broader than exposing interfaces as SOAP web services. SOA is based on two views that address two different needs.

Integration-led technical element

The first view encompasses the need to integrate deep into existing systems over their complex and often proprietary data formats, protocols, and transports. Then, the need is to expose them by using standardized mechanisms (such as SOAP/HTTP or more recently JSON/HTTP) to make them easier to re-use in new applications. This view is shown on the left side of Figure 2. Some or all of this view is often referred to as an Enterprise Service Bus (ESB) pattern. However, this term is used indiscriminately to the point of making it meaningless.

The need to do deep integration (integration hub and adapters) and to expose these integrations as services or APIs in a standardized way (exposure gateway) is essential. This aspect has everything to do with integration challenges and little to do with application design. Consequently, therefore, it appears to have little relationship with the microservices application architecture.

Business-led functional element

The second view is from a business perspective. The concern is that the interfaces on the current systems are largely meaningless. They don't make sense to the business, and they don't provide what's needed for the next generation of applications. They might be too granular, exposing too much of the complex data models within the systems. The data that is required might be spread across multiple systems. The data models might not resemble the terminology that is used by the business.

The need entails functional refactoring to expose something that the business can tangibly build into future solutions. This refactoring requires the creation of new applications to bind together requests across the existing systems of record. In the SOA reference architecture, these applications were often referred to as service components (right side of Figure 2). This view shows a relationship to application design (and, therefore, the microservices architecture) and the functional decomposition of capabilities into separate components.

Figure 2. Technical and functional views of SOA

¹. Dichotomy = Difference, Contrast ↩