ESB & API-Led architecture = Enemies or Friends ………..
Integration is always an enterprise challenge. In this digital economy, to connect with customers, partners, create products, applications, services that businesses need to confront the digital revolution, you have to connect systems, data, and devices. A long-time back when integration started with services, enterprises started with a point to point integration.
The Inception of ESB and Its Benefit
Enterprises struggled with point to point, which created a spaghetti-like mess of code. After that SOA based architecture found an ESB as a better integration solution.ESB integration helps clear out the spaghetti mess created by masses of point-to-point integrations by providing a simple, well defined, “pluggable” system that scales well. In addition, ESB integration provides a way to leverage your existing systems and expose them to new applications.
But times change, and technology evolves, and for today’s complex enterprise technological architecture — with its hybrid infrastructure and a rapidly exploding number of endpoints — ESB integration only is no longer adequate. ESB integration presents both technical and organizational challenges, reducing organizations’ integration capabilities’ effectiveness.
Top 5 reasons why ESB is not sufficient for current market changes.
- ESB promotes monolithic architecture at a high cost.
- ESB is not best for agility and innovation.
- ESB describes the organization's challenges- ESBs face procedural and political bottlenecks as different parts of the business need to move at different speeds. ESB can be a bottleneck for defining one integration, designing and to be in the ready state, this can be bottleneck and time-consuming.
- ESB is not fully fitting with Cloud-based architecture — With the increase of cloud and Saas applications, integration with ESB, not sufficient enough. Integration with cloud adapters of differents Saas apps and APIs would be a little difficult with ESB.
- One size doesn't fit all- ESBs treat all integrations as equals, but they should be built with specific purposes in mind.
Integrations fall into three broad categories:
-> Device integrations — to support multiple channels; for example, mobile, web, and partners.
-> Process integration — these integrations provide orchestration logic to tie together integrations that span multiple back-end systems.
-> System integration — these provide connections to our applications.
All of these integration categories behave differently and have different requirements. While ESBs will often support process and system capabilities, they rarely provide direct support for device integrations. Customers must, therefore, purchase additional products (such as an API Gateway), increasing costs and complexity and, in turn, introducing monitoring, management, and security gaps as integrations flow backward and forwards between multiple products.
The Inception of API and Its Benefit
API, or the Application Programming Interface, refers to a set of tools, routines, or protocols used for building applications. It informs the software how to interact. Various methods emerged that allowed remote access to the procedural API, bypassing the typical programmer overhead through data packing and unpacking that are required for interoperation between different kinds of computers.
The benefits of Software API stretch out in more ways than one. API enables integration with heterogeneous systems and data to bring new business models, products, and services to the forefront.
It is the gateway to accessing data from a given application without using the application interface. APIs enable several services to communicate with each other and other existing business systems, thereby exposing information silos and opening up new possibilities for data integration.
This is the typical ESB based architecture. When we move with ESB and API GW architecture then the picture may look like below
The requirements of the Integration layer in the organization.
API Management and the ESB can exist alone, depending on the scenario and focus. In most scenarios, companies would benefit from both. In these cases, the architecture is even more robust, as long as we manage to enhance the strengths of each of them:
Overview of terms mentioned in the above diagram.
Benefits of API Management/API led architecture in its integration architecture
- More flexible integrations, facilitating faster deliveries and reducing costs
- Standardized interfaces, enabling multi-channel and agility in the integration with partners
- Establishment of governance and real-time monitoring of integrations
- Security and control over the use of APIs
- Mechanisms to optimize the performance of applications
- Separation of responsibilities
- Scalability
ESBs are not going away, but they are also purpose-built to enable controlled and tight integrations between components. They are a central bus to enable highly structured integration between services. This situation is by definition the antithesis of the paradigm shift to a decomposed architecture. With that said, you do ultimately want to put all of these granular pieces together, be it to build composite APIs from a large number of loosely coupled and highly cohesive components, or to orchestrate fine-grain APIs together to provide a higher level abstracted API that just looks for dynamic component for use cases like onboarding, where most attributes are already set and unchanging.
A Full Lifecycle API Management solution, allows you to put in place governance and observability around access to and communication between these decomposed components. By doing so, you can expose the components, giving developers, partners and third parties access to the functionality to use it in innovative and unexpected ways while maintaining the benefits of the loosely coupled and highly cohesive architecture paradigm.
Conclusion
Is ESBs are dead, not really. ESBs can be still important to any enterprise’s EAI strategy, but new disruptive digital and Hybrid paradigms have brought about a new need. To be agile enough to remain relevant to the market and your users, you must move away from the manual Integration Factory mindset where IT builds every connection and instead become an Integration Enabler. With so many ways to connect so many new components, self-enablement of your business analysts, developers, and third-party users is a must. API Gateways are central to this strategy, working in conjunction with ESBs to provide the full functionality needed by your enterprise to thrive and deliver the best customer experiences. But that's true with the time and evolvement of API-Led and event-driven architecture ESBs can be obsolete in the coming future but as of now ESBs and API GW/Management both complement each other.
So they are not enemies but friends, as of now.
