SOA vs Microservices: Their Contrasts, Differences, and Key Features

Bob Quillin

February 10, 2022

Most enterprise software applications built until recently were monoliths. Monoliths have a huge code base and run as a single application or service. They did the job, but then developers started running into a brick wall. Monoliths were problematic to scale. No single developer could understand the entire application. Making changes, fixing bugs, and adding new features became time-consuming, error-prone, and frustrating. 

In the late 1990s a new architectural pattern called Service-Oriented Architecture (SOA), emerged as a possible panacea for these problems. The software community did not warm up to it in a big way; hence, SOA gave way to another pattern: microservices. The SOA vs microservices debate represents evolutionary responses for building and running applications distinct from the monolithic architecture

SOA resembles microservices, but they serve different purposes. Few companies understand the distinctions between these architectures or have expertise in decomposing monolithic applications.  

Both architectural patterns are viable options for those considering moving away from traditional, monolithic architectures. They are suitable for decomposing monolithic applications into smaller components that are flexible and easier to work with. Both SOA and microservices can scale to meet the operational demands and speed of big data applications. 

This article looks at the basic concepts of SOA and microservices so that you can understand the differences between them and identify which is more appropriate for your business. We’ll look at their origins, study what makes them unique, and for what circumstances they are most suited.

SOA vs Microservices: What Are They?

The common denominator between microservices and SOA is that they were meant to remedy the issues of monolithic architectures. SOA appeared first in the late 1990s. Microservices probably premiered at a software conference in 2011. They are both service-based architectures but differ in how they rely on services.

These are some key areas of critical difference:

  • Component sharing
  • Communication
  • Data governance
  • Architecture

A lot of ambiguity surrounds SOA, even though architects conceptualized it about a decade before microservices. Some even consider microservices to be “SOA done right.” 

What Is A Service-Oriented Architecture (SOA)?

SOA is an enterprise architecture approach to software development based on reusable software components or services. Each service in SOA comprises both the code and data integrations needed to execute a specific business function.

Business functions that SOA handles as services could range from processing an order, authenticating users into a web app, or updating a customer’s mailing address. 

In an SOA application, distinct components provide services to other modules through a communication protocol over a network. SOA employs two concepts that have huge implications for development across the enterprise to do this successfully. 

The first is that the service interfaces are loosely coupled. This means that applications can call their interfaces without knowing how their functionality is implemented underneath. 

Because of how their interfaces are published, along with the services’ loose coupling, the development team can reuse these software components in other applications across the enterprise. This saves a lot of engineering time and effort. 

But this also poses a risk. Because of the shared access across the ESB (Enterprise Service Bus), problems in one service can affect the working of connected services. SOA applications have traditionally used ESB to provide a means of controlling and coordinating services. 

Unlike microservices that emerged after the introduction of cloud platforms that enabled far better-distributed computing SOA is less about designing a modular application. SOA is more focused on how to compose an application by integrating discretely maintained and distributed software components.  

Tech standards such as XML enable SOA. They make it easier for components to cooperate and communicate over networks such as TCP/IP. XML has become a key ingredient in SOA. 

So, SOA makes it easier for components over various networks to work with each other. This is in contrast to microservice containers that need a service mesh to communicate with each other. 

Web services built on SOA architecture are more independent. Moreover, SOA is implemented independently of technology, vendor, or product. 

Features Of SOA

These are some noteworthy characteristics of SOA:

  • Provides an interface to solve challenging integration problems
  • Uses the XML schema to communicate with providers and suppliers
  • More cost-efficient in the short-term for software development because of the reuse of services
  • Improves performance and security with messaging monitoring

SOA provides four different service types:

  1. Functional services: used for business-critical applications and services
  2. Enterprise services: designed to implement functionality
  3. Application services: used for developing and deploying apps
  4. Infrastructure services: used for backend processes such as security and authentication

Each SOA service comprises these three components:

  • An interface that defines and describes how a service provider executes requests from a service customer
  • A contract which defines how the service provider and the service customer interacts
  • The implementation service code

What Are Microservices?

Microservices architecture is an approach to software application development that builds functions as suites of independently deployable services. They are composed of loosely coupled, isolated components performing specialized functions. Given the ambiguity arising from SOA architecture, microservices were perhaps the next logical step in SOA’s evolution. 

Unlike SOA that communicates with ESB, microservices use simpler application programming interfaces (APIs). 

Microservices are built as small independent service units with well-defined interfaces. They were conceptualized so that each microservice could be operated and independently deployed by a small team of 5 to 10 developers. 

Microservices are organized around a business domain in an application. Because they are small and independent units, microservices can scale better than other software engineering approaches. These individual units of services eventually combine to create a powerful application. 

Microservices are often deployed in containers, providing an efficient framework of services that have independent functionality, are fine-grained, portable, and flexible. These containers are also platform-agnostic, enabling each service to maintain a private database and operating system and run independently. 

Microservices are predominantly a cloud-native architectural approach–usually built and deployed on the cloud. 

One salient difference between microservices and SOA is that microservices have a high degree of cohesion. This cohesion minimizes sharing through what is known as a bounded context. It represents the relationship between a microservice and its data, forming a standalone unit. So bounded context produces minimal dependencies by coupling a component and its data to constitute a single unit. 

Characteristics Of A Microservice Architecture

Here are common characteristics of microservices:

  • Loosely coupled modules
  • Modularization that enhances system maintenance and product management
  • High scalability potential with low cost of implementation
  • Platform agnostic, making it easy to implement and use many different technologies
  • Ideal for evolutionary systems that have to be agile and flexible to accommodate unforeseen change 

SOA vs Microservices

While microservices structure themselves as a series of distinct, single-purpose services, SOA creates a group of modular services that communicate with each other to support applications. 

We have listed below the core differences between these architectural approaches.

Scope of Exposure

At their core, SOA architectures have enterprise scope, but microservices have application scope. Understanding this difference in scope enables organizations to realize how these two might complement each other in a system. 

Size and Scope of Projects

Microservices have a much smaller size and scope of services in the development process. Also, being fine-grained dramatically reduces its size even further. The larger size and scope of SOA align better with more complicated integrations and cross-enterprise collaboration.

Reusability

The primary goal of SOA is reusability and component sharing to increase application scalability and efficiency. A microservice doesn’t place such a high premium on reuse, although reuse is welcomed if it improves decoupling through code copying and accepting data duplication. 

Data Duplication and Storage

SOA aims to give applications the ability to synchronously get and change data from their primary source. The advantage of this is that it reduces the need for the application to maintain complex data synchronization patterns. So, SOA systems share the same data storage units. 

Conversely, microservices believe in independence. A microservice typically has local access to all the data it needs to maintain its independence from other microservices. As a result, some data duplication in the system is permissible under this approach. Data duplication increases the complexity of a system, so the need for it should be balanced with the cost of performance and agility. 

Communication And Synchronous Calls

SOA uses synchronous protocols like RESTful APIs to make reusable components available throughout the system. However, inside a microservice application, such synchronous calls can introduce unwanted dependencies, thus threatening the benefit of microservice independence. Hence, this dependency may cause latency, affect performance, and create a general loss of resilience.

Therefore, in contrast to SOA architecture, asynchronous communication is preferred in microservices. It often uses a publish/subscribe model in event sourcing to keep the microservice up-to-date on changes occurring in other components.

The ESB handles communication in SOA. Although ESB provides the mechanism through which services “talk” with each other, the downside is that it slows communication. As a single point of failure, it can easily clog up the entire system with requests for a particular service.

Microservices don’t have that burden because they use simpler messaging systems like language-agnostic APIs. 

Service Granularity

Microservices are highly specialized. Each microservice does one thing only. This isn’t the case for the services that comprise SOA architectures-they can range from small, specialized services to enterprise-wide services. 

Governance

SOA believes in the principle of shared resources, so its data governance mechanisms are standard across all services. Microservices don’t allow for consistent governance policies because of their flexibility.

Interoperability

Microservices use widely used, lightweight protocols such as HTTP/REST (Representational State Transfers) and JMS (Java Messaging Service). On the other hand, SOA works with more diverse messaging protocols like SOAP (Simple Object Access Protocol), AMQP (Advanced Messaging Queuing Protocol), and MSMQ (Microsoft Messaging Queuing). 

Speed

Microservices prioritize independence and minimize sharing in favor of duplication. As a result, microservices operate at a faster pace. However, SOA speeds up development and troubleshooting because all parts of the application share a common architecture.

Tabulated Differences Between SOA vs Microservices

SOAMicroservices
Focused on increasing application service reusability More focused on decoupling
Web services share resources across servicesBuilt to host services that can operate independently
Not as much strong emphasis on DevOps and continuous integrationThe preeminence of DevOps, along with Continuous Integration/Continuous Deployment (CI/CD) pipelines
Communicates through ESBUses API protocols and less elaborate messaging systems
Uses SOAP and AMQP protocols for remote servicesLightweight protocols such as HTTP, REST, or Thrift APIs
SOA services share data storageMicroservices often have independent data storage
Concerned with business functionality reuseFocused on creating standalone units through “bounded context”
Provides common standards and governanceRelaxed governance with emphasis on collaboration, independence, and freedom
The use of containers is rare and less popularUses containers and containerization
Best suited for large-scale integrationsBest for cloud-native, web-based applications
More cumbersome, less flexible deploymentQuick and easy deployment

Is Microservices a Better SOA??

There’s much more to the SOA vs Microservices debate than we’ve presented here because it’s a highly technical and vast (and contentious) subject. However, we have tried to provide enough compelling information by highlighting the essential points to consider when deciding to adopt a microservices architecture for your project, as the logical successor to SOA.

As the first and only platform to have solved the challenge of automatically transforming monolithic Java applications into cloud-enabled versions as a reliable and repeatable process, vFunction has extensive expertise and experience in SOA and microservices architectures.

Contact vFunction today to further discuss your software architectural challenges and transformation options.

Bob Quillin

Bob Quillin is the Chief Ecosystem Officer for vFunction, responsible for developer advocacy, marketing, and cloud ecosystem engagement. Bob was previously Vice President of Developer Relations for Oracle Cloud Infrastructure (OCI). Bob joined Oracle as part of the StackEngine acquisition by Oracle in December 2015, where he was co-founder and CEO. StackEngine was an early cloud native pioneer with a platform for developers and devops teams to build, orchestrate, and scale enterprise-grade container apps. Bob is a serial entrepreneur and was previously CEO of Austin-based cloud monitoring SaaS startup CopperEgg (acquired by IDERA in 2013) and held executive and startup leadership roles at Hyper9, nLayers, EMC, and VMware.

Get started with vFunction

See how vFunction can accelerate engineering velocity and increase application resiliency and scalability at your organization.