Why traditional ESBs are a mismatch for Cloud-based Integration

Cloud ESB

The explosive adoption of cloud-based applications by modern enterprises has created an increased demand for cloud-centric integration platforms.  The cloud poses daunting architectural challenges for integration technology like: decentralization, unlimited horizontal scalability, elasticity and automated recovery from failures. The traditional ESBs were never designed to solve these issues.  Here are a few reasons why ESBs are not the best bet for cloud-based integration

Performance and Scalability
Most ESBs do simplify integration but use a hub-and-spoke model that limits scalability since the hub becomes a communication bottleneck.  To scale linearly in the cloud, one requires a more federated, distributed, peer-to-peer processing approach towards integration with automated failure recovery. Traditional ESBs lack this approach.

JSON and REST
ESBs evolved when XML was the dominant data-exchange format for inter-application communication and SOAP the standard protocol for exposing web services. The world has since moved on to JSON and today, mobile and enterprise APIs are exposed using REST protocols. ESBs that are natively based on XML and SOAP are less relevant in today’s cloud-centric architecture.

Security and Governance
These are key concerns for any enterprise that chooses to move to cloud. With multiple applications in the cloud, enterprises are not always comfortable with centralized security hubs. Security and governance need to be decentralized to exploit the elasticity of the cloud. Old-guard middleware products were typically deployed within the firewall and were never architected to address the issues of decentralized security and governance.

Latency and Network connectivity
When your ESB lives in the external cloud, latency becomes a critical challenge as end-points are increasingly distributed across multiple public and private clouds. Traversing a single hub in such an environment leads to unpredictable and significant performance problems which can only be addressed with new designs built ground-up with Cloud challenges in mind.

API Management for Everyone

API Management

Today people don’t like talking about ESBs anymore. Instead, the buzz is around cloud, big data, the application programming interface (API) economy, and digital transformation. Application integration is still a core enterprise IT competency, of course, but much of what we’re integrating and how we’re integrating it has shifted from the back office to the omnichannel digital world.

And here’s Fiorano, with one foot still in the traditional ESB space, especially in the developing world where even basic integration is a challenge – and the other foot squarely in the modern digital world. Now they’re launching an API management tool into a reasonably mature market.

On first glance, this move might seem rather foolish, as this market is already crowded, with each of the aforementioned behemoths participating, as well as CA, Axway, Intel, SOA Software, Apigee, WSO2, MuleSoft, and several others, who have all been hammering out the details for a few years now.

But there’s method to Fiorano’s madness. That critical architectural decision that enabled them to compete a dozen years ago has turned out to be extraordinarily prescient, as it separates their approach to API management from the pack as both more cloud-friendly as well as user-friendly than the rest.

Peer-to-Peer with Queues

The secret to Fiorano’s product successes is its unique queue-based, peer-to-peer architecture. Queuing technology, of course, has been with us for decades, but traditionally provided reliability only to point-to-point integrations.

The rise of ESBs in the 2000s saw many vendors building centralized queue-based buses that basically followed a star topology. To scale such architectures and avoid single points of failure required various complex (read: expensive and proprietary) machinations that limited the scalability of the approach.

By building a peer-to-peer architecture, in contrast, Fiorano never relied on a single centralized server to run their bus. Instead, the platform would spawn peers as needed that knew how to interact with each other directly, thus avoiding the central chokepoint inherent to competitors’ architectures. The queues connecting the peers to each other as well as to other endpoints provided the reliability and fault tolerance to the architecture.

The result is an approach that is inherently cloud-friendly – even though the minds at Fiorano built it before the cloud hit the marketplace. Each peer can go on premise or in a cloud instance, and thus scale elastically with the cloud.

Today, as the cloud becomes a supporting player in the digital world and user preferences drive an explosion of technology touchpoints, Fiorano has managed to put in place the underlying technology that now supports the API management needs of modern digital environments.

The API Management Story

I also covered the API Management market starting in 2002, when vendors called it the Web Services Management market. Then it transformed into SOA Management, then Runtime SOA Governance, and now API Management (although Gartner awkwardly uses the term Application Services Governance).

After all, Web Services are a type of API, and managing them is an aspect of governance. Today, we’d rather refer to services as APIs in any case, as our endpoints are more likely to be RESTful, HTTP-based interfaces than SOAP-based Web Services.

This rather convoluted evolutionary path for the API Management market explains why there are so many players – and why many of them are the old guard incumbents. But it also indicates that many of the products in the market are likely to have older technology under the covers, perhaps better suited for first-generation SOA technologies than the modern cloud/digital world.

Fiorano, however, has avoided this trap because of their cloud/digital friendly architecture, as the diagram below illustrates. At the heart of the Fiorano API Management Architecture are both the Gateway Servers, which handle the run time management tasks, as well as the Management Servers, tasked with supporting policy creation, publication, and deployment.

Both types of servers take advantage of Fiorano’s peer-to-peer architecture, allowing cloud-based elasticity and fault tolerance, the flexibility to deploy on-premise or in the cloud, as well as unlimited linear scalability.