INTEGRATION ; API STANDARD MAKES ESB OBSOLETE?

No self respecting developer delivers a new product with support for the RestAPI standard. Does this mean that there is no longer a need for other integration solutions like an Enterprise Service Bus (ESB)?

For decades, ESB technology was the solution of choice for every Enterprise Integration initiative. This centralized integration solution was platform independent and offered support for legacy applications as well as more modern applications. Now that new technologies like API’s and microservices are available, is an ESB still required or is this old technology that should be replaces as soon as possible?

API Gateway and Enterprise Service Bus (ESB); what they share

Since both technologies offer the same service (exchanging data between systems and applications) they obviously share a lot of the same functions:

Architecture

Both an API Gateway and an ESB are software solutions or applications running on a server either as a cloud solution or on-premise.
The API Gateway acts as a front-end for API’s, it receives API requests, supports throttling and security policies and passes requests between a back-end service and requester. API Gateways offer developers a consistent interface to the many different ways API’s are implemented by their creators. As the name suggest, an ESB is a centralized software solution that connects services using a variety of protocols, data transformation technologies and routing of messages.  

Security

API gateways and ESB solutions both offer extensive support for authorization and authentication. This is to make sure:

• Only authorized staff can add or change new policies or APIs
• APIs and ESB activities can authenticate themselves to make sure they can only touch data and/ or applications to which they have the correct rights.

Only with the right authorization and authentication techniques will you be able to comply with the very strict audits and regulatory compliance controls when dealing with sensitive data.

Transformation & Validation

No system or application is the same and even something simple as a contract number or a date can have many different formats. Just as some applications will “speak” XML while the receiving end expects JSON. API Gateways and ESB solutions both offer extensive support to automatically transform the format of requests and parameters.
Both solutions will also offer support to validate the data from a request (I expect a parameter in date format YY/MM/DD) as well as the possibility to enrich data (add information) when transferring something back to the requestor.

API Gateway and Enterprise Service Bus (ESB); The Differences

Both technologies are from different generations but this doesn’t mean that the older technology (ESB) is superseded by the more modern technology (API Gateway).

Legacy support

Let’s assume that you still have legacy systems and applications and that you have implemented many services in your ESB already. Unless you have too much budget and too many developers who have nothing better to do, upgrading to the latest version of your ESB or changing the way you use your ESB (from on-premise to a cloud based iPaaS solution) is possible the smartest thing you can do. After all, you will continue to add new systems and applications which will in turn need access to your legacy data so an ESB is simply the best solution for this unless your legacy application supports the API standard of course.

Digital Transformation

This is really a tough one because integration with API’s can be created quite fast. But API Gateways have limited support to enrich data that moves through the gateway and offer no support for legacy applications. ESB’s on the other hand will allow you to add business logic and enrich data much easier and this can dramatically increase the value of integrations when developing new business initiatives.

Management effort

API Gateways are very scalable and there are plenty of examples where organizations have implemented dozens in an architecture that is flexible, offers ultrafast performance and has no single point of failure. ESB’s are not scalable and unfortunately will always be a single point of failure. While this can be overcome by implementing multiple ESB’s, this causes al lot of complexity and can be very labor intensive.

The Solution

No legacy : If your organization doesn’t have any legacy applications or you have never used an ESB, the solution is simple, you will use an API Gateway for your integration efforts and will run this solution as either an on-premise solution of as a service from the cloud.

Legacy or legacy investments: If your organization does have legacy systems and an existing ESB with hundreds of integrations and data-exchange routines, you will want to keep running these as efficient as possible. After all, you will be asked for many more years to develop integrations with these legacy systems. You do have more options that you had in the past however. As stated earlier, hosting, maintaining and running one or more ESB’s AND an API Gateway architecture may be a lot of work despite that fact that you will need both solutions in the years ahead.

DIY or..?

Another solution could be to run both technologies as a Managed Service with a trusted integration partner, where the partner will take care of hosting, maintaining and running both the ESB and API Gateway(s).

You can also choose to trust a partner and let them take care of all or a specific sub-area of your integrations (for example all integrations with the world outside your company walls). You decide which systems of applications you want to connect and your integration partner decides which technology to use and delivers the end-result as a Managed Integration. It’s up to you to decide how you define your integration strategy; is your limited IT staff really needed to manage an integration infrastructure or should they be working on solutions that are specific to your organization and speed up your digital transformation initiatives?