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.
Fittingly, the original ESB deployment vision was an integrated network of collaborating service nodes, reminiscent of the “smart endpoints and dumb pipes” principle that has been adopted by the microservices movement. However, as the notion of the ESB gained popularity, it developed a new meaning. Following a 2002 prediction by Gartner that the ESB pattern would be implemented in the majority of enterprises by 2005, the hub-and-spoke EAI middleware vendors were able to convince many in the industry that an ESB was not a pattern, but rather a middleware product to be used for enterprise application integration. They rebranded their EAI broker products as ESBs and customers ate them up.
As Gartner had predicted, implementing an ESB became almost an imperative in 2005. Enterprise IT organizations formed centralized delivery groups to manage the ESB infrastructure and become involved in integration projects across their companies. The ESB gave the SOA championing enterprise architects a foothold in the application environments they were tasked with transforming. They used this foothold for two new purposes: control and consistency.
SOA program leaders justified their need for control in order to ensure the development and usage of services that supported the organization’s business objectives. This led to the SOA governance submovement that gave birth to its own category of software products. Efforts to establish consistency included attempts at defining canonical enterprise data models and an ever expanding set of vendor-driven standards (collectively WS-*) intended to ease interoperability between web service platforms. With the technological template, the prescriptive standards, and the centralized culture of command and control, the would-be lightweight alternative to EAI had become heavier and heavier. SOA had lost its way.
The original promise of SOA was to speed up project delivery, increase IT agility, and reduce integration costs. However, SOA adopters -- i.e., adopters of what SOA had become by this point -- found that it actually increased complexity and introduced bottlenecks, and the costs of implementing an SOA infrastructure (based on the ESB, registry, and service platform template) were excessive.
By 2009, people were not merely questioning the SOA approach but marking its death. RESTful Web APIs -- a style of interconnecting applications that had evolved organically on the Web -- arose as a lighter-weight alternative to SOAP services. The distributed nature of cloud infrastructure challenged the placement of the centralized ESB topology. Organizationally and culturally, the agile movement was driving decentralization and team autonomy. The combination of factors among others took the SOA movement out of the mainstream.
Learn from SOA
Asking whether microservices and SOA are different or the same is the wrong question. Why would it matter? The right question is to ask what the microservices movement can learn from the SOA movement. What went wrong? What endured? Here are five important lessons.
1. Stay true to the goals. The SOA movement went off track when it strayed from its original goals of increasing agility and reducing costs. Implementers focused too much on the technologies of SOA and too little on the business problems they were trying to solve. When the SOA manifesto was published in 2009, it was in reaction to the mainstream SOA movement rather than an embodiment of its principles. Although business alignment is a stated characteristic, the microservices movement runs a risk of going off course. There are already examples of technologists concluding that if they simply containerize their applications, then they are “doing microservices.” In order to be successful with microservices, we must focus on the goals, intended benefits and principles before considering the enabling technologies.
2. Start with success. Despite the incredible uptake of SOA in its heyday, there were few public case studies demonstrating its promise. Tellingly, SOA began as a purely conceptual pattern defined by an industry analyst. In contrast, microservice architecture was derived from real software development patterns observed within numerous organizations. Amazon and Netflix are but two flag bearers of the style. Furthermore, the scope of microservice architecture is deliberately broad, covering the patterns, principles, culture, and organizational traits in addition to technologies. This is healthy, as it favors reality over an idealistic model. As the reference microservice implementations change, the model should evolve.
3. Perspectives matter. There are a number of examples in the SOA movement of conflicting intentions leading it astray. Technology executives built centralized empires rather than instilling a cultural change. Enterprise architects insisted on standardization without clear goals. Vendors changed the definition of ESB to fit their products, rather than the other way around. From the architects who are still sore about the original SOA definition being lost, to the vendors looking to rebrand their products yet again, to the enterprise IT shops heavily invested in SOA middleware, those with an ax to grind against the SOA movement are understandably wary of microservices. However, don’t convict microservices on the evidence against SOA. Be open-minded and listen to all, but make sure you check your sources. Question everyone’s motives, including your own.
4. Seek harmony, not absolutes. SOA started off with balanced goals, such as speeding time to market while reducing integration costs. Stemming from its centralized roots, the SOA movement abandoned both of those goals in practice, instead seeking to control and standardize application integration. This was an extreme and unbalanced position. The essence of the microservices movement is to improve software delivery speed and increase system safety as scale increases. These are harmonious goals. However, given the decentralized heritage of microservices and its agile roots, there is a risk that implementers may stray toward too much team autonomy and compromise the safety side of the coin. There are already examples of this in the industry. The important task is to ensure there are counterbalances in place that support the goals and abide by the movement’s core principles.
5. Patterns and principles last, technologies don’t. In the microservices-versus-SOA debates, there is one point of consensus: Microservice architecture matches that original SOA vision of a software system decomposed into loosely coupled services. That is a pattern. Furthermore, original SOA principles such as business alignment, dependency minimization, and service contracts are microservice principles as well. The vast differences lie in the technologies. This is both blessing and curse. Technology evolves at a rapid pace. To a large extent, technology movements come down to proven principles enabled by new technologies. For the microservices movement, this means that the shiny new technologies of today will be gone tomorrow. Every Docker will have its day, but microservice adopters should embrace the patterns and principles, and prepare for technology obsolescence.
The microservices movement is exciting. In synthesizing proven principles with new technologies and cultural practices, it is legitimately new. Whether it is SOA done well, an evolution of SOA, or the anti-SOA is beside the point. Microservices will come, leave its mark, and be replaced by the next movement, then the next, and so on. In the present, it is up to the members of the microservices movement to determine what that mark looks like. Heeding these lessons from the SOA movement will hopefully maintain the harmony that can help organizations achieve speed and safety at scale.
This is the second post in a two part series from Matt McLarty, co-author of the upcoming book "Microservice Architecture" from O’Reilly Media. This series shares applicable lessons from the evolution of microservices. To learn directly from the early adopters of microservices and to receive a free digital copy of the new book, attend the API360 Microservices Summit in New York on June 16, 2016.
Matt McLarty is an experienced software architect who leads the API Academy at CA Technologies.
New Tech Forum provides a venue to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to newtechforum@infoworld.com.