Four Factors to Consider When Choosing Between a Built-in vs. 3rd-Party Event Broker for iPaaS

In the kickoff to this series of blog posts about event enabling your iPaaS, I addressed how pairing an event broker with an iPaaS can improve your system’s resilience, agility and real-time capabilities.

Once you embrace the idea of pairing your iPaaS with an event broker, you have more decisions to make. The first is whether to use the event broker provided by the iPaaS solution itself or use a 3^rd-party event broker. It can be a daunting choice, because built-in messaging capabilities vary widely between iPaaS solution providers –some iPaaS solutions do not include built-in messaging capabilities at all! Others, grasping the potential of event-driven architecture, have begun to beef up their built-in messaging capabilities. To help frame the discussion, I have included references to the built-in messaging capabilities of several popular iPaaS solutions.

Your choice can significantly affect your enterprise’s ability to deliver for your customers. Here are four factors to consider:

1. Importance of easy/integrated administration
2. Distribution across hybrid/multi cloud systems
3. Incorporation of IoT and mobile devices
4. Monitoring, alerting and monitoring

I’ll explain each one in detail below.

1. “Single Pane of Glass” Administration

The biggest selling point for built-in event brokers is the seamless experience they give administrators and developers. Most iPaaS solutions nicely integrate their event brokers with the UI your team knows and (hopefully) loves. Administrators can add queues and create new event brokers with a click of a button that lives alongside the rest of the iPaaS interface. And if there is an unexpected challenge along the way, there is a single company that can assist – the proverbial “one throat to choke.”

That simplicity of administration is typically support by a well-defined set of best practices. These best practices can work well for simple use cases such as allowing asynchronous interaction between a single sender and receiver flow, particularly with non-business critical data, low transaction volumes and no need for more advanced functionality like event priorities.

Adding a 3^rd-party event broker to the mix means resources need to learn and support more tooling. It also means that when issues arise, you may need to deal with both vendors. It is worth noting, however, that some iPaaS providers are forming partnerships with 3^rd party event broker vendors to create a more nicely integrated experience.

2. Distribution of Data Across Hybrid and Multi-Cloud Environments

One of the driving forces of businesses adopting event-driven architecture is the efficient distribution of information through both on-premises and cloud-based applications.

Most 3^rd party event brokers can be deployed efficiently in on-premises and multi-cloud environments, and then tied together to form a single event mesh. With that capability, a 3^rd-party event broker can enable the agile flow of information by removing routing logic from applications, making it as easy to get an order to China as it is to credit the sale to a local salesperson in Salesforce. An event mesh adapts dynamically to ensure the event-driven delivery of data anywhere in the world, via any number of brokers, without the need for changing existing applications or configurations. Third-party event brokers perform these operations with enterprise-grade messaging capabilities such as guaranteed message delivery, first-in-first-out messaging and more.

Most built-in event brokers have less robust features for data distribution. Some built-in iPaaS event brokers only allow events to pass between processes in a single runtime installation, preventing the efficient distribution of information across multiple locations in your enterprise. Other iPaaS solutions have built-in event brokers that can only be installed in the cloud[1] and cannot share events between different cloud regions within a single cloud provider–or multiple cloud providers[2]. This leaves it to enterprises to determine how best to distribute information globally through manual coding.

The inability to distribute information across regions and on-premises systems also has implications for disaster recovery. Many 3^rd party event brokers can guarantee that data replication to multiple locations, ensuring business continuity when an entire datacenter goes down or becomes disconnected. For iPaaS-native brokers that do not support that, you need to manually code disaster recovery, which is a downright frightening prospect.

3. IoT and Mobile Applications

The internet of things (IoT) and mobile applications can drive explosive growth for your enterprise, enabling innovative customer interactions. But they can also create a wave of data that your infrastructure needs to manage—a wave that can surge at unpredictable times.

Third-party event brokers can help you reliably and responsively handle rapid increases and unpredictable bursts of data flow. Modern 3^rd party event brokers speak a wide variety of communication protocols, including those commonly used by IoT and mobile applications, and can scale to millions of concurrent connections. By serving as the single point of entry for an enterprise, event brokers can also prevent overwhelming surges of data, by queuing incoming events until downstream applications can process them.

Built-in iPaaS event brokers generally have less robust capabilities. For some iPaaS solutions, external applications simply cannot communicate with the built-in event broker at all [3]. Other iPaaS solutions allow interaction with external applications, but only through an HTTP REST API. This constrains the development of innovative features using popular frameworks, potentially straining the infrastructure and tightly coupling information providers and consumers [4].

An alternative approach would be to use the capabilities available within the iPaaS itself, such as MQTT connectors. While possible, it is important to consider whether such a solution would scale to production-ready levels, particularly under heavy, unpredictable load.

4. Monitoring, Alerting and Management Capabilities

One final point to consider is your ability to understand and react to issues within your enterprise’s event-drive architecture. Given the importance of the event broker to that architecture, it is important to keep an eye on its health and to understand what events are available to applications.

Third party event brokers typically allow for granular viewing of resource usage in real-time and send alerts to administrators if memory runs low or if there are events piling up on an error queue. These proactive measures can mean the difference between a system recovering elegantly and an outage that affects customers. As more enterprises adopt event-driven architecture, providers of event brokers are adding the ability to design, discover and manage events in a single screen.

Although iPaaS solutions supply an integrated development and administration experience, this typically does not extend to monitoring and alerting of the built-in event broker. Instead, iPaaS solutions either do not supply event broker monitoring [5], or expect administrators to use external tooling for monitoring and alerting [6].

Conclusion

It can be challenging to choose between an iPaaS’s built-in event broker and a third-party event broker. The appeal and value prop of using an iPaaS’s own event broker is the ability to manage your entire system, including event distribution, with a single pane of glass. And for very simple use cases, that might be just what the doctor ordered.

If you need more sophisticated event distribution capabilities, however, a 3^rd-party event broker can be a powerful differentiator for your business, enabling innovative solutions that span both on-premises systems and the cloud to enhance your customer experience.

[1] MuleSoft Anypoint MQ FAQ: Currently, Anypoint MQ cannot be deployed on-premises.

[2] MuleSoft Anypoint MQ FAQ: [Q]ueues and message exchanges are unique to the region in which they were created and cannot share messages or queues between regions. Developers can manually create custom programs that load balance between regions, but Anypoint MQ itself does not provide multi-region support.

[3] Boomi: Message queues cannot be directly accessed from outside the Atom.

[4] MuleSoft Anypoint MQ FAQ: Enables you to easily connect to non-Mule applications using the REST API.

[5] MuleSoft Anypoint MQ FAQ: MuleSoft Anypoint MQ does not support use with CloudHub Insight or Anypoint Monitoring. Instead, you can use the Anypoint MQ usage graphs to access usage information.

[6] Boomi: In order to monitor these attributes, you need to use a systems management tool, such as Zabbix, and use a JMX hook (a standardized interface for Java programs) — see the linked topic about system monitoring with JMX.