Essential Guide

SOA tutorial: Trends, governance and the microservice impact

A comprehensive collection of articles, videos and more, hand-picked by our editors
Q
Manage Learn to apply best practices and optimize your operations.

What is the difference between an SOA and a microservices architecture?

Everyone has a different viewpoint on SOA, but three key differences between SOA and microservices architectures can help you determine which is best for your enterprise.

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."
  • "Nothing."

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:

  1. You are unlikely to find anyone advocating the use of a service-enablement platform in a microservices architecture.
  2. You are less likely to find the use of heavyweight application servers in a microservices architecture.
  3. 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.

Next Steps

Overcoming microservices challenges

Brace for a microservices approach

When to consider microservice architecture

How will SOA keep up with the connected-everything trend?

This was last published in July 2015

PRO+

Content

Find more PRO+ content and other member only offers, here.

Essential Guide

SOA tutorial: Trends, governance and the microservice impact

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Join the conversation

5 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

What do you see as the difference between SOA and microservices?
Cancel
To me, the distinction is more of an evolutionary difference. Think of SOA (or service-enabled architecture) as a primitive, rudimentary implementation of an idea based on technologies available at the time, and microservices architecture as the sleeker, more evolved implementation enabled by technological progress and refinement of ideas.
Cancel
I hear people use them more or less interchangeably, so I think that it just depends on the context. Conceptually they are very similar.
Cancel
I think a lot of businesses tried to implement a service-oriented architecture but wound up with a service-enabled architecture, and are now trying to move towards a microservices architecture. It’s almost like microservices architecture is an evolutionary refinement of the service-enabled architecture. in that light, the three key differences outlined in the article make sense.
Cancel
Hey Jason, I saw your article the day after I sent mine off to the editor. There's definitely some very similar themes in what we both have to say. It's good reading for anyone interested in this subject!
Cancel

-ADS BY GOOGLE

SearchSoftwareQuality

SearchCloudApplications

SearchAWS

TheServerSide

SearchWinDevelopment

Close