BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
The concept of microservices has garnered significant attention recently, so, inevitably, the question has arisen: What's the difference between an SOA and a microservices architecture? If you've tried searching the Web on that subject, you'll find comments like:
- "Microservices are SOA done correctly."
- "SOA is a lame enterprise approach, whereas microservices are a cool hacker approach."
- "Microservices architecture is a specialization of SOA."
- "The SOA paradigm left quite a bit open for interpretation."
There are elements of truth in all of this, even the "nothing" comment, depending on your viewpoint. The problem is that just about everyone has a different viewpoint on SOA, based on what they had in their enterprise, which vendor's technology they used, which consultants they worked with, which bloggers they followed, etc. OASIS established a reference model to create a consistent definition that everyone could use, but by the time that was completed, the hype had waned and people's attention had moved on to other topics.
Based on my experience, what I think most organizations wound up with after the SOA hype was not service-oriented architecture -- which I define simply as an architecture where the core concept is a service -- but service-enabled architecture. A service-enabled architecture is an architecture of something else (like monolithic applications) where integration is enabled by service interfaces. It's because of this that the term microservices has renewed interest.
If you simply slapped service interfaces on top of your existing systems, but none of your development or operational processes changed to manage things at a finer-grained level, then the impact of a change is still probably greater than you'd like. Martin Fowler's article on microservices delved into these development and operational processes to make it very clear that the microservice is the core unit of change. With all of the advancements in DevOps and cloud-based services since the early SOA days, it's now far easier for the typical organization to realize the importance of this aspect than it was 10 to 15 years ago. Were some people emphasizing the same concepts 10 to 15 years ago? Yes. Were most enterprises listening? No. Now they are.
From a technology stack perspective, the three key differences worth calling out between an SOA and a microservices architecture are:
- You are unlikely to find anyone advocating the use of a service-enablement platform in a microservices architecture.
- You are less likely to find the use of heavyweight application servers in a microservices architecture.
- Microservices will likely involve significant (relentless) automation of infrastructure processes.
Please note that I used the words "unlikely," "less likely" and "likely." There are no absolute rules around any particular tech stack. In fact, Fowler's article emphasizes the freedom of technology choice that exists.
The use of a service-enablement platform, however, is an indicator that you may be more focused on achieving integration benefits rather than operational management benefits. You'll note I didn't use the term enterprise service bus, because ESBs are like Swiss army knives. Where an ESB is used as a pure intermediary for operational flexibility (e.g., managing routing to an ever-changing number of deployments) or perimeter security, it may continue to have a role in a microservices architecture. If you're using an ESB to slap services in front of some legacy or monolithic application with poor integration capabilities, that's another story.
As for application servers, frankly, these are leftovers from the days of large servers, no virtualization, slow infrastructure provisioning, and the only technology choices being Java EE or .NET. With small commodity servers, ubiquitous use of virtual machines, fully automated provisioning, scripting-based server side development and advanced open source libraries, the need to have an application server capable of running a lot of applications just isn't there anymore. Add in the need to scale up particular operations over other operations, and everything points toward a much finer-grained unit of management. If you're running only one thing, you don't need much over the operating system other than a solid set of libraries for communicating with other systems. Throw Docker into the mix and you can achieve a level of decoupling from the physical infrastructure that allows for incredible amounts of flexibility in deployment.
In the end, my advice is not to obsess over whether you have an SOA or a microservices architecture or a hybrid of the two. Unless you're building on a complete greenfield, you'll choose to apply today's best practices where it makes business sense. Look at your existing systems, the utilization patterns of the functionality provided and the changes that occur to the functionality over time. If it makes sense to split things apart because some portions of your application are utilized significantly more than others or changed more significantly than others, then do so using the principles of microservices. If your systems tend to change as a whole, with utilization spread across all functionality, breaking it apart may add more complexity because of the increased moving parts. In that scenario, a service-enablement platform, like an ESB, may be the right use of technology for your integration needs. For things brand new, I advocate a microservices architecture approach because it is the best architecture for flexibility at this point in time. Building flexibility in at the beginning is far easier than retrofitting it after the fact.
Overcoming microservices challenges
Brace for a microservices approach
When to consider microservice architecture
How will SOA keep up with the connected-everything trend?