Why SOA was killed while Microservices are thriving?

Yesterday, I was in the Microsoft Azure Boot camp event in Toronto. And one of the things that came for discussion was the Microservice architecture. Later, over the discussion when we were discussing legacy architecture patterns, one of the participants asked me how SOA is different from the MIcroservices. This is not the first time when this question came to me, a big fan of SOA in my architect days.

However, today I also asked myself another question - why SOA, the hot topic of last decade, got vanished as fast as it came into the limelight. As I dug deeper I realized there were several reasons that contributed to the SOA’s downfall. These reasons ranged from the unavailability of the right ecosystem, SOA’s inherent technological flaws, to not having the right proponents.

I’ll explain each of these later, but before that, let me briefly explain the differences between SOA & Microservices, as many of us, early adopters of SOA but not in Architects role anymore, may still be looking for the answers.

There are four major differences between SOA and Microservices –

1. Messaging Protocol: Although SOA was technology-neutral, it was largely implemented with SOAP/HTTP while WSDL being the service contract between Service Provider and Service Consumer. Microservices use REST/HTTP as communication and transport protocol
2. Database inclusion: In SOA, the database was still kept one, though business services were refactored to realize the principle of Separation of concern. In Microservices, even database tables are supposed to be refactored to ensure all the vertical components of services are self-contained without any dependency on the components of one or another.
3. Orchestration Layer: SOA prescribed to have an orchestration layer, which mostly got implemented in BPEL, though there was no technology prescription in terms of technology. BPEL was great for Long-running processes but extremely slow in executing online transactions. At times the same logic implemented in BPEL was 100 times slower than the one written Java.
4. Service Discovery: For Service Registry and Discovery, SOA brought the concept of UDDI (Universal Directory and Discovery interface), while Microservices are managed through API Gateway – concepts are similar but there are implementation differences

• the response has to come in microseconds while Microservices remote calls over HTTP add substantial distribution tax on the end-to-end performance
• business changes are rare and scalability is not required as happens in standard processing of batch files
• SDLC methodology followed is still Waterfall with no or limited adoption of DevOps best practices.

Now taking it from here, let’s understand what went wrong with SOA that caused its phenomenal crash from being the darling of many enterprise architects in the last decade.

The first reason was the availability of the right ecosystem. Although SOA was an architecture for distributed applications, the infrastructure available was mostly on-premise with its own capability & scalability limitations. The Cloud computing and advanced DevOps ecosystem were still coming up. The impact of this was that Services conceptualized in SOA architecture got implemented and deployed through a traditional monolithic deployment mechanism and the experience was not great.

The second reason was that as SOA was publicized as being synonymous to web services, mistakenly though in the same way the Blockchain was assumed to be the Bitcoin platform, most of the implementation got done through SOAP/HTTP messaging and communication protocol. Running over traditional infrastructure, these services experienced substantial latency, making them unviable for high-performance applications.

The third reason was its perceived conflict with Object-Oriented Architecture & Design (OOAD) in which Data & Methods were encapsulated together in one class/object, while SOA recommended keeping services segregated from data. To a large influential community of Java professional, it was the iconoclastic behavior from new technology. Many of these Java developers and architects couldn’t accept the SOA as an alternative and it became extremely difficult for SOA proponents, who mainly came from integration programming background like webMethods, Tibco, WebSphere integration, etc. to influence the decision-makers to adopt the SOA.

With other nails in the coffin as explained above, SOA couldn’t realize its full potential, and ultimately paved the way for its light-weight offspring – Microservices. By this time Cloud computing is at the forefront across the globe, Advanced DevOps tools & Processes are in place at most of the organizations, and having REST protocol over HTTP helped eliminate the verbosity and performance issues up to a large extent.

Although Microservices architecture inherited many of the SOA problems like distributed logging & debugging, distribution /latency tax, managing hundreds of smaller services, it weaved itself very well in the existing technology stack and it was complemented with scalable cloud architecture, agile DevOps tools & practices, and Log aggregators - three items extremely critical for its success.

However, now as it happened in the case of SOA, Microservices are also being touted as the panacea of all global IT problems. So, it is extremely crucial to understand cases where a typical Microservices would not be the right architectural solution. These include, but not limited to, business use cases where

• the response has to come in microseconds while Microservices remote calls over HTTP add substantial distribution tax on the end-to-end performance
• business changes are rare and scalability is not required as happens in standard processing of batch files
• SDLC methodology followed is still Waterfall with no or limited adoption of DevOps best practices.

In nutshells, although Microservices architecture pattern got the benefit of the ecosystem and organization readiness, potential uninformed decisions by lazy thinkers will push it on the path of SOA. So Architects need to be extremely thoughtful when accepting or adopting Microservices as an alternative to their existing architecture.

#SOA, #Microservices, #Architecture, #AzureBootcamp, #AzureBootcampTO