PubSub+ for Developers

Event Mesh

An event mesh is to your event-driven applications what a service mesh is to your RESTful applications: an architectural layer that allows events from one application to be dynamically routed and received by other applications, across diverse systems, clouds and protocols. This layer is composed of a network of advanced event brokers. The capabilities of the brokers that compose the mesh determine the capabilities and quality of the mesh.

Building an event mesh with PubSub+

An event mesh built with PubSub+ Event Brokers is:

• Dynamic: events and other messages are self-routing, self-learning, self-healing, and built for automated and efficient event streaming between event producing and event consuming apps, wherever they run.
• Open: natively supports multiple open standard protocols and APIs, for an open ecosystem.
• Simple: the mesh can be created, managed and monitored through a single console.
• Everywhere: can be deployed natively on premises, in private clouds and in public clouds (AWS, GCP, Azure), as an appliance, software and as a service.

Internet of Things

IP-addressed applications typically send and receive data to devices through an intermediary node like an IoT gateway, and the default communication pattern is request-reply over REST/HTTP (Figure 1).

For simple IoT projects and pilots that tend to be very focused and small scale, this will be the path of least resistance, and it will probably work just fine. But as you move from pilot to production in an enterprise environment, and as your application requirements grow more complex, the benefits of an event-driven approach enabled by event brokers and messaging patterns like publish-subscribe increase.

Build IoT apps that are flexible and scale

PubSub+ Event Brokers can sit between your applications, IoT Gateways, back-end systems and cloud services, enabling a variety of communication patterns between them (publish-subscribe, streaming, queuing and request-reply), and over a variety of open standard protocols and APIs (MQTT, AMQP, JMS, WebSockets, REST/HTTP). This carries a number of advantages:

It enables event-driven communication between diverse endpoints and networks (devices, gateways, legacy applications, cloud-based microservices, data lakes, analytics engines) without requiring you to build complex protocol translations into your applications (protocol translation is done by the broker).

• It makes for a highly scalable system: brokers can be vertically and horizontally scaled to handle exponential increases in load and connection counts.
• It enables efficient command and control of edge devices by back-end applications: (1) every device and application in the system is addressable through PubSub+ topic routing; (2) broker-enabled protocol translation lets back-end apps send commands over JMS while gateways/devices can receive the commands over other protocols (like MQTT, AMQP, REST/HTTP); and (3) messaging capabilities supported by the broker like fan-out and filtering enable back-end systems to send commands to individual, all, or select groups of edge devices.
• It’s fault tolerant: PubSub+ Event Brokers enable multiple qualities of service including guaranteed delivery for IoT scenarios where every message must be delivered—even to disconnected subscribers or those that can’t handle large volumes of data at a time.

Messaging

Messaging refers to the passing of data between two applications via an intermediary broker (message-oriented middleware). Messaging communication patterns like publish-subscribe, queuing and streaming can be differentiated from other communications patterns like request-reply over REST/HTTP in that messaging enables the decoupling/loose coupling of applications (Figure 4), and messages are generally sent asynchronously, whereas point-to-point request-reply patterns tend to support synchronous interactions between applications that are tightly coupled (Figure 3).

If you’re experienced with messaging, you may be familiar with open source tools like RabbitMQ, ActiveMQ or Kafka, or a commercial product like IBM MQ, TIBCO EMS (for on-prem deployments), AWS SQS/SNS or Azure Service Bus (cloud-native). Each messaging solution has its pros and cons, but a modern event broker like PubSub+ fits the bill for enterprise use cases that demand high performance and reliability across public clouds, private clouds, and datacenters, the flexibility to deploy anywhere, and the need to leverage a variety of open standard protocols and APIs.

Leverage modern messaging

PubSub+ Event Brokers are uniquely designed to support modern development practices (microservices, reactive, polyglot) and architectures (event-driven, hybrid cloud, multi-cloud), with support for the publish-subscribe messaging pattern (along with the traditional queuing and request/reply patterns), dynamic event streaming, and a host of additional features that ensure enterprise-grade performance and reliability no matter the demands of load and scale.

Cloud

Stream data across public clouds, private clouds and hybrid clouds

PubSub+ Event Brokers support event-driven applications and architectures across hybrid-cloud, multi-cloud and IoT environments, with support for the publish-subscribe messaging pattern (along with the traditional queuing and request/reply patterns), dynamic event streaming, and a host of additional features that ensure enterprise-grade performance and reliability no matter the demands of load and scale.

PubSub+ Event Brokers can be deployed natively in AWS, GCP and Azure, as well as in private clouds/datacenters, and the brokers can be connected to form a dynamic event mesh for event-driven communication across all environments (see Event Mesh use case).

PubSub+ Event Broker Cloud offers enterprise-grade messaging as a service, on-demand in your favorite public and virtual private clouds.

Here are some of the cloud-related capabilities and benefits you can unlock:

• Stream data from your premises to the cloud: enable secure, reliable, real-time data movement between legacy and cloud applications over WebSocket, AMQP 1.0, JMS or REST/HTTP.
• Stream data across private and public clouds; work inside the virtual private clouds (VPCs) offered by public cloud providers to maintain security and control.
• Leverage WAN optimization for high throughput and low latency between cloud regions (over long-haul links) with limited bandwidth and/or round-trip times.
• Filter data at the edge: only send events and other data to the cloud when you have applications in the cloud that are interested in the data (save $).
• Benefit from built-in fault tolerance and replication, both with fast failover, to ensure data is never interrupted and messages never get lost.
• “Lift and shift” existing applications directly to the cloud leveraging JMS support.