In the early 2000s, Service-Oriented Architecture (SOA) was the hot topic. Much ink was spilled in touting its potential. Effort and money was expended in attempts to secure its promised benefits. Like object-orientation and reuse before it, the reality of SOA was not able to live up to the hype. Unlike them, SOA had better penetration into the business realm and having soared higher in the corporate hierarchy, fell further into disrepute. Before the decade was done, SOA had become a dirty word (although services had become ubiquitous).
Too much attention had been paid to technological minutiae and too little had been paid to strategy. Much of what strategy existed could be characterized as “build it and they will come”. Anne Thomas Manes in her 2009 post “SOA is Dead; Long Live Services“, identified what had been neglected:
Successful SOA (i.e., application re-architecture) requires disruption to the status quo. SOA is not simply a matter of deploying new technology and building service interfaces to existing applications; it requires redesign of the application portfolio. And it requires a massive shift in the way IT operates. The small select group of organizations that has seen spectacular gains from SOA did so by treating it as an agent of transformation. In each of these success stories, SOA was just one aspect of the transformation effort. And here’s the secret to success: SOA needs to be part of something bigger. If it isn’t, then you need to ask yourself why you’ve been doing it.
“Microservices”, a post published by James Lewis and Martin Fowler this March has kindled intense interest in the microservice architectural style. While the term “microservice” dates back at least to Lewis and Fowler in 2011, the buzz around the style is new. Tagging along with this renewed interest has been the question of whether microservices are just the latest incarnation of SOA. Lewis and Fowler don’t take a definite stand either way, but for Steve Jones, microservices are just re-branded SOA.
Part of the problem may be that both SOA and microservices have aspects that transcend boundaries. Manes’ quote above makes it clear that SOA is concerned with enterprise IT architecture. Microservices are primarily an application architecture pattern. Yet Steve Jones makes his case that “Microservices is SOA, for those who know what SOA is” by comparing elements of the Lewis and Fowler definition of microservices with the OASIS SOA Reference Model.
In 2005, Martin Fowler described SOA as “a semantics-free concept that can join ‘components’ and ‘architecture'”. He attributed this to the fact that SOA had become different things to different people:
- For some SOA is about exposing software through web services. This crowd further sub-divides into those that expect the various WS-* standards and those that will accept any form of XML over http (and maybe not even XML).
- For some SOA implies an architecture where applications disappear. Instead you have core services that supply business functionality and data separated by UI aggregators that apply presentations that aggregate together the stuff that core services provide.
- For some SOA is about allowing systems to communicate over some form of standard structure (usually XML based) with other applications. In its worst form this is “CORBA with angle brackets.” In more sophisticated forms this involves coming up with some form of standard backbone for an organization and getting applications to work with this. This backbone may or may not involve http.
- For some SOA is all about using (mostly) asynchronous messaging to transfer documents between different systems. Essentially this is EAI without all the expensive EAI vendors locking you in.
Replace “SOA” above with “microservices” and many of these same descriptions will still apply. This can perhaps be explained by the fact that bullets 2-4 are merely specializations of the first point. While there are differences between the two, the heart of the matter is that both SOA and microservices deal with collaborating, distributed systems rather than isolated monoliths. Distribution requires communication which requires exposure and a measure of standardization. You must be able to find what you depend on and you must be able to work with what it gives you. In order to meet these requirements, an appropriate level of governance is needed.
The application-centric focus of microservices may be the factor that allows it to succeed where SOA initiatives did not. Rather than an enterprise-wide effort, microservices bring discrete physical service applications together as one logical application (e.g. Netflix). This narrowing of focus should simplify the governance needed. What must be avoided, however, is the level of hype that attended SOA in its heyday. As with all architectural decisions, there is a cost to go along with the benefits. Distributed applications in general and microservices in particular, come with costs: increased development complexity, increased operational complexity, and increased need for governance. Martin Fowler recently published a post tempering the optimism with a discussion of the prerequisites necessary for success with a microservice architecture.
Applied to the appropriate context, this architectural style can provide significant benefits. Applied to the wrong context, it merely delivers additional costs and challenges. This would lead to the same death blow that Manes noted:
SOA was supposed to reduce costs and increase agility on a massive scale. Except in rare situations, SOA has failed to deliver its promised benefits. After investing millions, IT systems are no better than before. In many organizations, things are worse: costs are higher, projects take longer, and systems are more fragile than ever. The people holding the purse strings have had enough.
Gene is a software architect from Richmond, Virginia. He has been designing and developing software professionally since 1996, specializing in distributed systems and systems of systems. He is active in the Richmond Chapter of the Association of IT Professionals, serving as president during 2013 and 2014. Since 2011, he has maintained the blog Form Follows Function (http://genehughson.wordpress.com), where he writes about software architecture, IT management, and process.
