Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Learn from SOA: 5 lessons for the microservices era

Matt McLarty | June 30, 2016
The rise and fall of SOA can teach us much about making the best use of microservices

As I mentioned in my previous article, "Microservice architecture is agile software architecture," my initial reaction to microservice architecture was to question how it differed from service-oriented architecture (SOA). I was not alone in associating these two architectural styles. In their definitive blog post, James Lewis and Martin Fowler included a sidebar that contrasts microservices and SOA. In response, skeptics claimed there were no differences. And in fact, influential microservice adopters Amazon and Netflix both referred to their architectures as service-oriented before the term "microservices" was coined. More than two years later, the debate over whether microservice architecture is or is not SOA has produced a substantial library of articles.

Why are people so driven to compare microservices and SOA, and why is there so much passion? Although microservices and SOA can be differentiated on many levels -- architectural style, implementation examples, associated technologies -- they have played strikingly similar roles in the technology landscape. Both promised to be transformational, and they succeeded in attracting adherents who attracted still more adherents. In short, while both microservices and SOA began as architectures, they ultimately became movements.

Alas, today SOA is generally viewed as a failed movement within enterprise IT, and the wounds are still fresh for the many people who invested in it. This is why there is so much passionate interest in comparing microservices with SOA. People see a similar promise in microservices, and they fear a similar disappointment. In order to understand the context of the microservices-versus-SOA debate, it is important to retrace the history of the SOA movement: what fueled its momentum, and what ultimately sent it off track.

The rise and fall of SOA

Gartner analyst Roy Schulte defined service-oriented architecture in 1996 as follows:

A service-oriented architecture is a style of multitier computing that helps organizations share logic and data among multiple applications and usage modes.

In spite of this early definition, SOA didn't gain popularity in the industry until 2002, following the emergence of web services. Although SOAP/XML web services were originally intended for server-to-server web communication between disparate organizations, they were quickly co-opted by enterprise architects who were evaluating ways to exploit the web as a new channel and looking to harness its new technologies wherever possible. As an internet-friendly way of connecting applications, with large cost savings projected, web services caught like wildfire in these enterprises. The "service-oriented architecture" label was adopted for this approach, and the SOA movement was born.

As the SOA movement kicked into gear, a new integration pattern emerged to facilitate SOA's loose coupling principle: the Enterprise Service Bus (ESB). Many people now forget that the ESB pattern was intended to be lightweight and ubiquitous, in direct contrast to the hub-and-spoke Enterprise Application Integration (EAI) brokers that were common at the time. In fact, the ESB concept was itself a reaction to the issues caused by the monolithic nature of EAI brokers, such as slower software delivery, too many cross-team dependencies, and poor manageability.


1  2  3  4  Next Page 

Sign up for CIO Asia eNewsletters.