September 6, 2018 | Written by: Thoughts On Cloud Staff
Share this post:
If you work in IT, you might have heard the SOA versus 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 benefit from a certain level of decoupling.
The main distinction comes down to scope. To put it simply, service-oriented architecture (SOA) has an enterprise scope, while the microservices architecture has an application scope.
Here are some very basic definitions of each with that difference in mind:
- SOA is an enterprise-wide initiative to create reusable, synchronously available services and APIs. This helps developers create applications more quickly and more easily incorporate data from other systems.
- Microservices architecture is an option for building an individual application in a way that makes that application more agile, scalable and resilient.
Why this difference matters
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:
- Reuse. 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.
- Synchronous calls. 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.
- Data duplication. 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.
Some will point out that the SOA versus 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, you might want to read this post. It goes into much more detail. 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.