We’re giving away 1,500 more DJI Tello drones. Enter to win ›
Kim Clark | Updated January 22, 2016 - Published January 21, 2016
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.
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:
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 an application scope, with a focus on the structure and components within an application.
These definitions of SOA and microservices are too simplistic. In fact, the relationship between them is much more complex.
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.
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.
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.
Organizations vary in which of the two views is the greater challenge. For some organizations, their greatest challenge is the diversity and complexity of the integration. For others, refactoring and relandscaping to achieve the right business functionality is the primary challenge. Figure 2 shows how different the problem can look, depending on which of these two challenges is forefront in your mind.
For many, the challenge is a painful mixture of both views. It is painful because it’s difficult to merge the two views into a single course of action. Integration tools are not the right place to perform business logic. Conversely, you do not want your business applications to be cluttered with technical integration concerns.
The goal of most SOA programs is to achieve the functional aspects. They want easily accessible business-relevant services that can be used to build new applications more effectively. However, many run out of momentum, or more commonly out of budget, while still solving technical integration challenges. In large enterprises, SOAs are often perceived to have failed. This thought might be true in that they failed to deliver the final business value, although huge strides were made to improve the accessibility of systems of record. However, in smaller companies (or more contained environments within larger companies), SOAs often claim true business successes because they can quickly overcome integration issues and move on to functional benefits.
These two views of SOA make comparisons with microservices challenging.
However, the difference between SOA web services and APIs isn’t defined by protocols and data formats because they are not used consistently between the two. The difference lies in the intent behind APIs and SOA services. One key difference is in their economics.
In SOA programs, service exposure was about exposing each business function so that it could be reused as much as possible. This way, each new project didn’t have to go through the pain of performing integration to the back-end system again. The typical consumers were internal applications that attempted to put fresh user interfaces onto older systems of record. At the time, integration was difficult and took a significant portion of an IT project’s budget. If you could make all of the core functions of the company available over reusable interfaces, you could significantly cut project costs. SOA was about cost saving, not generating new revenue.
APIs had a different starting point, with the assumption that integration was already simplified. This simplification occurred either through an earlier SOA initiative or by upgrading back-end systems to provide more ready-to-use modern interfaces. The new challenge is to craft an appealing interface to potential consumers. APIs are designed for the context in which they are likely to be used. For example, they are ideally suited to provide the data that is required by a particular type of mobile application.
API popularity skyrocketed with the rise in smartphone use. Smartphones run rich client-side applications, creating a disruptive new business channel. As a result, application developers needed simple access to back-end functions and data; they needed APIs. APIs became a saleable product, with API providers competing against each other for the attention of developers. The focus of APIs isn’t on reuse and cost saving as it was in SOA. Rather, the focus is on consumability and competing in the API economy. APIs are a saleable product.
This change in dynamic altered the technical requirements for APIs compared to SOA services. APIs needed sophisticated portals so that developers could discover and experiment with the APIs. They also needed mechanisms for developers to register to use and pay for the API. API providers needed the ability to set up payment plans to accommodate the various API usage rates. Because APIs are exposed publically, the exposing gateway needed strong security capabilities. All of these features needed to be self-service, and above all, simple. This change introduced a whole new type of IT capability now known as APImanagement.
To this point, the focus has been on APIs as something to expose publically to external consumers; the dividing line between APIs and internal SOA services has been clear. With the maturing of API management technologies, APIs have brought about such benefits as ease of use and self-administration. As a result, many companies now want to also use API technologies and protocols to expose services inside the company as shown in Figure 3. The lines between SOA web services and API are now blurred and almost irrelevant. They have differences in their origin, to whom they are exposed to, and the data models they use, but many SOA “services” could also be potentially described as internal APIs.
Today, the term APIs is commonly used to refer to any interface that is exposed over REST (HTTP/JSON) or a web service (SOAP/HTTP). The APIs are typically categorized by their scope, such as a public API or enterprise API. Enterprises that sustained SOA initiatives sometimes retain the term “service” for internal, enterprise-wide APIs. For more information about the differences between SOA and API, see Integration architecture: Comparing web APIs with service-oriented architecture and enterprise application integration.
The term API represents an evolution in the “service exposure” aspect of SOA. It uses simpler protocols and provides more sophistication around the exposure itself, including developer portals, policy controls, and self-administration.
Before you look at a comparison of microservices and SOA, you need to understand what a microservices architecture means. From a fundamental point, microservices are an alternative architecture for building applications. They offer a better way to decouple components within an application boundary. In fact, if microservices were called “micro components,” their true nature would be clearer.
The boundaries of the application remain the same. As shown in Figure 4, despite being broken into separate microservice components on the inside, the application might still look the same from the outside. The number and granularity of APIs that a microservice-based application exposes should not be any different than if the API was built as a siloed application. The prefix “micro” in microservice refers to the granularity of the internal components, not the granularity of the exposed interfaces.
Logically separating components within an application is not new. A host of different technologies has been developed over the years to enable clean separation of the parts of an overall application. Application servers can run multiple application components within them for a long time as shown by the middle image in Figure 5. Microservices go one step further by making the isolation between those application components absolute. They become separately running processes on the network as shown on the right side in Figure 5. To achieve decoupling, you should also partition your data model to align with the microservices.
Fully independent microservice components enable completely autonomous ownership, resulting in the following benefits:
These examples of benefits capture some of the most common reasons that organizations are turning to microservices.
Before you decide whether to write applications as microservices, you must understand the following factors to ensure that your organization is prepared to handle them:
If you’re comfortable with these factors, you might be in a position to realize big benefits from a microservices application architecture.
If our mental model of SOA is focused on the integration aspects, microservices are completely separate. It is an alternative way of writing the applications to which the integration architecture is trying to connect as shown in Figure 1.
However, if our mental model of SOA is focused on relandscaping the applications into more business meaningful “service components,” the service components that are shown on the right side in Figure 2 can start to look more like microservice components. A microservices architecture can now be seen as an evolution of SOA. To illustrate this point, let’s compare two ends of the spectrum.
First, consider a fresh start-up company with a new idea for an entirely online product, such as social media or trading. Because it is starting with no existing architecture to work around, the company must create a suite of new applications to fulfil the unique aspects of the business. It might then choose to outsource the parts of the business that are not its core of adding value and use software-as-a-service (SaaS) applications, for example, for customer relationship management functions.
The company’s landscape might be largely created from scratch. The primary focus might be on its ability to rapidly add new functions, with minimal downtime in a constantly available environment (the idea of a green field). The company might want to scale elastically (that is, scale both up and down) in line with unpredictable customer demand. It might want to provide a round-the-clock, resilient, highly available online presence.
The microservices architecture is a logical choice for much of the company’s landscape as shown in Figure 6.
The new applications can live within a single microservices framework that provides nonfunctional capabilities, such as scalability, availability, and resource management. You can expect low-level integration concerns to be minimal because all microservice components and SaaS applications that are involved use common protocols, such as HTTP/JSON APIs for communication. One key objective of an SOA exposing valuable functionality so that it can be combined and used simply across the enterprise is largely present. In this example, the lines between a well-implemented SOA and microservices architecture are blurred. If you imagine a perfect implementation of an SOA, it might look something like this example, but only a new company can create such a homogeneous architecture.
This article does not address whether an SOA “service component” is equivalent in size to a microservice component. The granularity of microservice components and how they are grouped is another debate entirely.
Now consider an opposite example of a large enterprise that has been growing and acquiring its IT landscape over many decades. This enterprise, which might be a traditional bank or insurance company, can have hundreds or even thousands of significant applications that are built from technologies that stretch back over decades. The enterprise might have strong divisions within the company, such as between healthcare, pensions, and general insurance, or between retail and investment banking. Each business unit might have independent applications that are dedicated to their core business. The divisions might also have a suite of applications, such as for human resources, that might be shared wherever possible.
The company has likely grown by acquisition or merging with competitors. Within the landscape, you find much duplication of data across applications. Customer accounts might spread across many systems, depending on which original company they were with. Correlation of the same customer in multiple systems might not be straightforward. These back-end applications are typically difficult to change internally. In this environment, SOA has an enormous task to reimagine the back-end systems into something more useful for future business requirements.
The integration challenge is also complex. It might call for integration tools, as shown in Figure 7, to enable data and functions from back-end applications to be accessed despite the challenges with protocols, transport, and data formats. For largely historical reasons, this integration exercise is often labeled “SOA,” although it is focused on only half of the SOA challenge. It is labeled SOA because integration is the first area that most SOA initiatives tackle. In many cases, this is all that they achieve with the available funding.
However, a further aspect that companies need to achieve with SOA is reshaping the data and functions into more business-centric capabilities. They need to determine how to satisfy new channels, such as mobile, that require a radically different granularity of service to traditional applications. To achieve these aspects, companies need responsiveness, availability, and scalability that might not be available in current systems. Applications must be written to satisfy these new channels in a style that enables rapid agile change, provides for extreme scalability, and offers superior availability.
The attraction of using a microservices architecture for these new applications is easy to see. As shown in Figure 7, the initial usage of microservices in large enterprises is focused on new systems-of-engagement applications. The SOA concept might be tainted by early integration-centric efforts. Therefore, microservices are often viewed as being separate from SOA, providing greater agility, scalability, and responsiveness, but in many cases, relying on the ground work of the integration phase of SOA.
From an architectural point of view, SOA has three key elements:
These three elements are still present in future architectures, but they are necessarily distributed across the landscape as shown in in Figure 8.
Some systems still require the deep integration capabilities that are provided by integration hubs to expose their underlying functions and data as APIs. Other systems might be able to provide APIs directly when they are upgraded to newer versions. The key difference starts with where SOA tended to draw deep integration capabilities into a centralized function. The more advanced tools and techniques should enable integration to be federated more often to application owners as shown by the placement of the integration hubs in Figure 8.
Going forward, all systems need to provide APIs if they are to remain relevant. Application-level APIs need a lightweight layer of control as illustrated by the API gateways in Figure 8. This layer of control is an evolution of the service exposure concept from SOA. It has morphed into the much broader and decentralized API exposure.
The API gateway and management capability might be a common resource across the enterprise. It is “decentralized” in the sense that application teams can self-publish APIs, and equally self-subscribe to the APIs they need, without needing an extra team. You can gain the benefits of standardized mechanisms for traffic management and monitoring, logging, auditing, and security in a standardized way throughout the enterprise, while retaining the agility required by the business. These same API gateways might also be used to help govern interaction with business partners and external SaaS capabilities.
Traditional, more siloed applications are still appropriate for some implementations. However, microservices provide an alternative means for building some classes of applications, providing agility, scalability, and resilience that traditional applications cannot. Microservices applications are most common in the engagement layer, where their specific characteristics are most in need, enabling the creation of new channel-specific capabilities and Internet-facing APIs.
At least two different perspectives exist on what SOA was intended to achieve. A direct comparison between SOA and microservices architecture is likely to be fraught with difficulties. The concepts of an SOA are present in modern architectures but have evolved in several ways. Integration tools, patterns, and standards have evolved so that functions and data are more easily brought to the surface. Service exposure has evolved into APIs, simplifying exposure, consumption, management, and, in some cases, monetizing business functions. New application architectures, including the microservices architecture, enable developers to focus more closely on business logic, continuously pushing infrastructural detail to the environment in which they run. The combination of these developments enables solutions to be built in more agile styles and applications to benefit from new levels of elastic scalability and fault tolerance.
Thank you to the following people for their input and review of the material in this article: Andy Garratt, Andy Gibbs, Carlo Marcoli, and Brian Petrini.
Back to top