In this article, we'll explain the basics of SOA and microservices, touch on their key differences, and look at which approach would be best for your situation.
If you work in IT or the cloud computing field, you're probably well aware of the service-oriented architecture (SOA) vs. microservices debate. After all, everyone is talking about microservices and agile applications these days.
At first glance, the two approaches sound very similar. In some ways, they are—both are different from a traditional, monolithic architecture in that every service will have its own responsibility; both are scalable, agile approaches. However, even with these key commonalities, a closer examination of the two approaches reveals important differences.
What is service-oriented architecture (SOA)?
Service-oriented architecture (SOA) is an enterprise-wide approach to software development that takes advantage of reusable software components, or services. Each service is comprised of the code and data integrations required to execute a specific business function—for example, checking a customer’s credit, signing in to a website, or processing a mortgage application.
The service interfaces provide loose coupling, which means that they can be called with little or no knowledge of how the integration is implemented underneath. Because of this loose coupling and the way the services are published, developers can save time by reusing components in other applications across the enterprise.
SOA emerged in the late 1990s and represents an important stage in the evolution of application development and integration. Before SOA was an option, connecting an application to data or functionality in another system required complex point-to-point integration that developers had to recreate for each new development project. Exposing those functions through SOA eliminates the need to recreate the deep integration every time.
What are microservices?
Like SOA, microservices architectures are made up of loosely coupled, reusable, and specialized components. However, rather than being adopted enterprise-wide, microservices are typically used to build individual applications in a way that makes them more agile, scalable, and resilient.
Microservices are a true cloud native architectural approach, and by using them, teams can update code more easily, use different stacks for different components, and scale the component independently of one another, reducing the waste and cost associated with having to scale entire applications because a single feature might be facing too much load.
Check out the following video for more info on microservices architecture:
The main difference between SOA and microservices: Scope
The main distinction between the two approaches comes down to scope. To put it simply, service-oriented architecture (SOA) has an enterprise scope, while the microservices architecture has an application scope.
Many of the core principles of each approach become incompatible when you neglect this difference. If you accept the difference in scope, you may quickly realize that the two can potentially complement each other, rather than compete.
Here are a few cases where this distinction comes into play:
In SOA, reuse of integrations is the primary goal, and at an enterprise level, striving for some level of reuse is essential.
In microservices architecture, creating a microservices component that is reused at runtime throughout an application results in dependencies that reduce agility and resilience. Microservices components generally prefer to reuse code by copy and accept data duplication to help improve decoupling.
The reusable services in SOA are available across the enterprise using predominantly synchronous protocols such as RESTful APIs.
However, within a microservice application, synchronous calls introduce real-time dependencies, resulting in a loss of resilience. It may also cause latency, which impacts performance. Within a microservices application, interaction patterns based on asynchronous communication are preferred, such as event sourcing, in which a publish/subscribe model is used to enable a microservices component to remain up to date on changes happening to the data in another component.
A clear aim of providing services in an SOA is for all applications to synchronously get hold of and make changes to data directly at its primary source, which reduces the need to maintain complex data synchronization patterns.
In microservices applications, each microservice ideally has local access to all the data it needs to ensure its independence from other microservices, and indeed from other applications, even if this means some duplication of data in other systems. Of course, this duplication adds complexity, so it must be balanced against the gains in agility and performance, but this is accepted as a reality of microservices design.
Other key differences between SOA and microservices
- Communication: In a microservices architecture, each service is developed independently, with its own communication protocol. With SOA, each service must share a common communication mechanism called an enterprise service bus (ESB). The ESB can become a single point of failure for the whole enterprise, and if a single service slows down, the entire system can be effected.
- Interoperability: In the interest of keeping things simple, microservices use lightweight messaging protocols like HTTP/REST. SOAs are more open to heterogeneous messaging protocols.
- Service granularity: Microservices architectures are made up of highly specialized services, each of which is designed to do one thing very well. The services that make up SOAs, on the other hand, can range from small, specialized services to enterprise-wide services.
- Speed: By leveraging the advantages of sharing a common architecture, SOAs simplify development and troubleshooting. However, this also tends to make SOAs operate more slowly than microservices architectures, which minimize sharing in favor of duplication.
SOA vs. microservices: Which is best for you?
Both approaches have their advantages, so how can you determine which one will work best for your purposes? In general, it depends on how large and diverse your application environment is. Larger, more diverse environments lend themselves more to service-oriented architecture (SOA), which supports integration between heterogenous applications and messaging protocols via an enterprise-service bus (ESB). Smaller environments, including web and mobile applications, don't require such a robust communication layer and are easier to develop using a microservices architecture.
Learn more about SOA and microservices
Some will point out that the SOA vs. microservices debate is much more complicated, and that’s true. There is a great deal more to it. For a more detailed technical explanation of these nuances, we encourage you to delve into the SOA and microservices Learn Hub articles, which provide a great deal of in-depth information. From a business perspective, however, scope is the crucial distinction.
To learn more about how to build agile applications, download your free copy of the Agile Applications Architecture ebook.