

Integration pitfalls in SOA

A few years ago, SOA was very popular in the industry – it allowed developers to build APIs around core business logic so that it could be swapped in and out with relative ease. Most components developed in the traditional SOA methodology exposed their functionality using SOAP Webservices and typically communicate together synchronously through the very same services or asynchronously through queuing mechanisms. Communication issues led to integration pitfalls being exposed and this led to the rise of ESBs.

The concept of “Microservices”

Over recent years, some companies have found SOA to be too cumbersome, and the concept of ‘microservices’ has been on the rise ever since. On the face of it, microservices aren’t too far away from SOA – the typical definition for microservices is that your system architecture is composed of individual components that can be independently scaled and deployed that communicate together via REST endpoints. In fact, other companies have come right out and stated that the way they do SOA is exactly the same as the proposed microservices architecture.

What are the real differences between SOA and microservices?

Microservices and SOA services have the same requirements and nearly the same limitations; both make use of transport protocols to exchange data, typically HTTP and a queuing protocol (AMQP, MSMQ, JMS, etc). However, the integration problem is still there and companies should ensure they are fully aware of the challenges before diving head deep into microservices.

There are quite a few benefits to using microservices:

  • self-contained, understandable code that can easily be modified independently of your other apps or services
  • much easier to scale individually rather than as a single monolith
  • ease of deployment

What is the ESB-equivalent to microservices?

The integration of these two forms of services is also very similar. In SOA, the ESB typically sits at the core, exchanging data between services as needed. With microservices, the ESB has taken a more front-facing role in the form of an API Gateway. This API gateway acts as a single entry point for clients to consume your multiple APIs that are hosted as microservices. The API gateway looks like this, and immediately one can see the similarities between the API gateway and the ESB (image from http://microservices.io):

API gateway

Comparison of ESB and API Gateway

One might consider the API gateway a derivative, or perhaps a devolution of an ESB – it uses the same protocols to send and receive data and it uses identical enterprise integration patterns to achieve its intended behaviour. The main difference between an API gateway and an ESB is that the former applies several protection layers to your APIs (SLA tiers, throttling, rate limiting, client ID protection, and so on). The point I want to bring across is that even though some are saying that ESBs are yesterday’s technology, it really is not the case. On the contrary, ESBs are now at the forefront of our APIs – they are the tools that gather data from individual systems, collate it together and deliver the value promised by the whole system architecture.
