Apps

SOA versus microservices: What’s the difference?

Share this post:

SOA versus microservicesIf 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:

  1. 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.
  2. 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.
  3. 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.

More Apps stories

Simplifying complex modernization strategies with the right tools

A few years ago, NASA found water on Mars and mountains on Pluto. The first ever self-driving cars hit the road across the country. And organizations were still building compute workloads with monolithic applications in their local, dedicated data centers with predefined support and upgrade cycles. How far we’ve come since then. Companies are realizing […]

Continue reading

IBM and Volkswagen team for urban Mobility Advisor app

Traveling across town is getting easier. SEAT, a Spain-based member of the Volkswagen Group, and IBM are collaborating to develop Mobility Advisor, an app that uses Watson artificial intelligence (AI) to help city residents more effectively navigate city congestion and make smarter transportation decisions. “With its advanced cloud and AI technologies, IBM is helping us […]

Continue reading

ThKeeper uses Watson to help reduce risk and enable identity verification across borders

We live in an increasingly globalized world, where it is becoming common for people to live in multiple countries. People coming from abroad bring new skills and experiences, enriching workplaces. However, lives spent across borders can pose a challenge when it comes to identity verification, including credit history and criminal records checks. Even in today’s […]

Continue reading