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.
Sign up for CIO Asia eNewsletters.