For better or worse, the tech world seems to love arguing about stuff. One of the recent debates you may have heard about is the whole “Microservices vs. SOA” thing. What’s the difference between them? Is there any difference at all?
In today’s post, we’ll give our take on this debate. You’ll read definitions on both terms, and hopefully you’ll agree with us that even defining these two terms can be a daunting task.
We’ll then dive deep into both design paradigms, explaining their characteristics.
At the end of the post, you’ll be able to understand their similarities, their differences (if any), and you’ll be generally equipped to make an informed decision on which approach better fits the needs of your organization. Let’s get started.
Microservices vs. SOA
Time to offer our take on the “microservices vs. SOA” debate. What’s the difference between the two design paradigms?
They certainly have a lot in common, which makes sense when you consider that microservices are an offshoot of the SOA movement.
However, there are essential differences between the two systems. Let’s take a look at the two different approaches to architecture and highlight where they differ.
Before we dive in, it’s important to note that neither architecture has a universally accepted definition.
So, you could spend as much time debating the details of what microservices or SOA are as you could arguing their differences.
Understanding Microservices
Search for “what are microservices?” on the internet, and you’ll see many different definitions. So, let’s factor in the common attributes and look to an expert for some help with defining them.
A microservice architecture builds applications with loosely coupled services. Each service has a single responsibility. So, they focus on one task, such as authentication, billing, or inventory.
Martin Fowler’s Definition
Here’s a concise definition of the microservice architectural style from Martin Fowler and James Lewis:
In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies. – James Lewis and Martin Fowler
There’s a lot packed into that paragraph. Let’s take a look at four of the main points in this definition.
Loosely Coupled and Loosely Managed
Each service runs in its own process. Many web applications used to run as a single server. So, services running in separate processes are an important break from the past.
But the Wikipedia definition of microservices says that they can run in the same process. This illustrates how hard it is to nail these definitions down.
We build microservices around business capabilities. Whether or not a service runs in its own process seems like an academic argument. What the code does is where the rubber hits the road. We build microservices around specific business capabilities, and that’s what turns them micro.
The service focuses on a particular responsibility within the broader application. The number of lines of code and the process footprint isn’t what makes them small.
We deploy and run microservices independently. Microservices stand alone, and we can install and run by themselves.
Development teams are also independent, so they can develop applications with tools and languages that are distinct from other services in the same application. The teams also use continuous integration and automated testing.
We deploy microservices with limited centralized management. Microservices architectures have limited and decentralized governance. So, development teams have a lot of autonomy. They manage their schedules, and different parts of an application are deployed at different times.
Teams select their platforms, languages, and tools. As we’ll see, this is one of the areas it departs significantly from SOA.
Understanding Service-Oriented Architecture (SOA)
There’s no single definition of SOA. It’s been around for a long time. Several major software vendors embraced it in its heyday, so the architecture tended to have different definitions depending on where you looked.
Thirteen years ago, Fowler wrote an article titled ServiceOrientedAmbiguity where he concludes “I think SOA has turned into a semantics-free concept that can join ‘components’ and ‘architecture.”
The Open Group Definition
But there is a definition from The Open Group. This industry group defines the UNIX trademark, the TOGAF architectural standard, and SOA.
You have to create an account before you can download PDF versions of their document. So, we’ll go to the Wayback Machine and get the page where they used to share their SOA definition for free.
The SOA definition is longer than the one I used for microservices. So, I’m only going to provide a couple of excerpts here.
Service orientation is a way of thinking in terms of services and service based development and the outcomes of services.
“A service:
- Is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit, provide weather data, consolidate drilling reports)
- Is self-contained
- May be composed of other services
- Is a “black box” to consumers of the service”
So far, we can see a lot of overlap between microservices and SOA. The first two bullets work with Fowler and Lewis’ definition of microservices.
But, the third is where things start to diverge. Can you build a new service by combining two others and still call it a microservice? Probably not.
The combined services are no longer independent. So, we can see where SOA and microservices are not the same things.
Meanwhile, the last point is just good design. A service that requires knowledge of its implementation is an anti-pattern. I’m surprised that item made it past the committee.
SOA and Centralized Governance
Open Group’s architectural style list implies that it contains “must have” features. Let’s look at a few salient points.
-Service representation utilizes business descriptions to provide context (i.e., business process, goal, rule, policy, service interface, and service component) and implements services using service orchestration.
-It requires strong governance of service representation and implementation.
The standard mentions service orchestration and states that if your architecture doesn’t use it, it’s not SOA.
This requirement runs directly against how Fowler and Lewis describe microservices. Service orchestration implies the kind of synchronization and coupling between services that microservices do not have.
They also clearly state that SOA requires strong governance.
So, from just a brief look at a definition of SOA, we see clear differences with microservice architecture.
Microservices Vs. SOA: What Are the Differences?
Centralized Management
First, let’s start with the obvious difference. The SOA architecture requires strong governance, while microservices do not.
Fowler and Lewis dedicate a section of their post to decentralized governance and data management. Microservice teams work independently.
They manage their schedules and work with the tools they wish. They maintain control over how they represent business objects and make their own data storage decisions.
Fowler presents this as an advantage. When you read the description of how the teams operate, you can’t help but think of an agile program.
The Open Group requires strong governance in SOA. They have a standard for SOA governance here. (PDF here.)
Here’s a quote:
As a discipline, governance has been with us for many years, but with the advent of enterprise SOA, the need has been heightened for organizations to take governance as a discipline more seriously.
The standard implies that we need to tighten oversight for service-oriented architecture, not loosen it. A quick scan of the standard brings to mind daily status meetings, launch checklists, and quarterly software releases.
Independent Services and Service Orchestration
We think of microservices as independent entities. They are loosely coupled, if coupled at all, and employ their own messages and domain logic.
Fowler refers to this as smart endpoints and dumb pipes.
The SOA standard specifically mentions service orchestration. If you dig deeper, you find discussions of messaging. Services using a message bus to communicate with each other.
Many SOA implementations use an enterprise service bus to coordinate activities between services.
This is where the two architectures have their most significant differences. If SOA services are going to communicate across a shared bus, they need centralized governance, even if it is not necessarily as rigorous as the one spelled out by the Open Group.
They have to agree on how to represent business objects and the domain logic that manipulates them.
Microservices exist in silos and, if implemented with Fowler’s smart endpoints and dumb pipes evolve independently.
Microservices Vs. SOA: Why Should I Care?
So, it turns out there’s a difference between these two architectural patterns, and it’s a significant one. Microservices stand alone, with decentralized management.
Development teams can work independently, and with the tools they choose. Fowler at least implies a direct connection between agile methodology and microservices.
Meanwhile, an application built with SOA is composed of services that are more closely coordinated than with microservices.
This means establishing governance in advance, and often requires that development teams use the same tools.
Is one paradigm better than the other? I don’t think so.
While the decentralized management and isolation of microservices are inherently attractive, some problem domains can benefit from services that communicate with each over a backplane.
The question you really should be focused on is, do you know how is your system designed, and why?
