DEVOPSdigest

Hot infrastructure trends seem to explode into the shared consciousness of tech leadership in strange but predictable ways. From containerization to blockchain, machine learning to multi-cloud, each has the promise of being better, faster, and cheaper. But often, delivering on each promise takes years, requiring new education and training of teams, and many dev cycles to re-build stuff that ain't (completely) broke.

Well, here comes a new hot trend: Edge Messaging. As with other mega-trends, Edge Messaging holds massive promise: better (user experience), faster (time to market), and more efficient (effortless scaling). But for once, the benefits of Edge Messaging aren't the huge investment in time, training, and re-engineering that slows down the adoption of many other innovations. Today, the only thing holding back the massive adoption of Edge Messaging is just knowing it's there and where it fits.

Edge Messaging: Here

What is Edge Messaging? Edge Messaging solves the problem of how to scale "Event-Driven" applications, as these kinds of apps move out of the data center into large-scale consumer and IoT use cases. Event-Driven architecture is nothing new: it's a common design pattern for enterprise apps that's existed for decades. The Event-Driven trend took off in the 90s when large enterprises needed to integrate back-office systems together. Rather than build point-to-point integrations between all of their different systems (Oracle, SAP, PeopleSoft, etc.), each back-office system would "publish messages" to alert other systems whenever an "event" happened (say, an order, new hire, or inventory change). These messages were dumped onto a message bus (early message buses came from Tibco, IBM, and others).

The key difference between Event-Driven communication and request/response communication is that Event-Driven apps are asynchronous; i.e. the "publisher" of an event doesn't really know (or care) when, and which, systems receive that message. This is different from request/response architecture, where the requestor (i.e. someone calling an API) waits for a response back from the responder (i.e. the server responding to that API call).

So, if Event-Driven architecture has been here for decades, then what's changed? Today, most apps are no longer "back-office" apps. Web, mobile, and IoT apps can often have millions of connected users. And traditionally, all of these "web scale" apps have been based on that request/response model discussed above (we often call these "REST-based apps"). Almost the entire Internet infrastructure is designed around synchronous, request/response-based apps. But, REST-based apps can't deliver the user experience people want today. Now, people expect apps to be real-time: whether chat features, digital whiteboards, games, IoT sensors, or smart home products, all these share a common need: the ability to send "messages" to these devices in real-time. These messages may be human-based (i.e. chats), or they may be targeted to a machine (i.e. "turn on a light" messages). These apps all need the same Event-Driven design that enterprises have been using for decades. However, the existing "behind-the-firewall" messaging buses of the past are totally unusable for handling the complexities of the Internet: millions of devices, unreliable mobile connections, firewalls, NATs, proxy servers, and more. This is where Edge Messaging comes in.

Edge Messaging: There

Today, vendors offering Edge Messaging infrastructure have matured and some operate at a very large scale. And those delivering on the promise are the vendors that make it really easy to "plug" existing apps into an Edge Messaging network. So rather than requiring application rebuilds or new product development, good Edge Messaging APIs can extend existing apps to add "real-time" features, or to consume data into the edge network that, prior, was simply being written to logs. Usually, it's as simple as a "Publish()" API call to send data points into the Edge network, and an equally simple "Subscribe()" API call so that devices (mobile, web, IoT, or server) can listen, in real time, to those published messages. Mature edge messaging vendors also provide a library of SDKs so the complexity of socket connections, authorization, and encryption is handled "under the covers".

Once messages are streaming into (and out of) the edge messaging network, what are the benefits?

First, a good edge messaging network can deliver a solid user experience, regardless of where those users reside. Like the CDNs of old, Edge Messaging Networks have multiple points-of-presence, connected with high-speed interconnects, ensuring that latency "feels" the same across a global population of users.

Second, a key requirement of an Edge Messaging Network is the ability to support "Functions"; i.e. an ability to run your app-specific code within the edge network. Why? An edge messaging network isn't just about moving messages from one device to others. In almost every use case scenario, the edge messaging network needs to route, filter, augment, aggregate, or transform the messages before being received by the subscribers.

Here are just a few examples:

■ Ability to prevent spammers who try to flood a social app with messages.

■ Aggregating temperature readings from IoT sensors, only sending alerts when thresholds are breached.

■ Counting votes in a social app and sending aggregated results back to the audience over time.

■ Tracking cars lat/long locations, and triggering alert messages when geofences are crossed.

Edge Messaging: Everywhere

An Edge Messaging Network doesn't solve one big problem, it solves a thousand medium-sized problems. Without one, teams can suffer from "death by 1000 paper cuts." As more apps across enterprise, consumer, and IoT move to event-driven designs, companies that try to handle the event-streaming and event-processing on their own often stumble, and often in unexpected ways. Some common pain points include:

■ Handling unexpected spikes, as message transaction volumes can often jump by 100x in seconds in some use cases.

■ Managing a distributed messaging system, with points-of-presence in multiple locations: syncing regions together, in real-time, can be a massive challenge.

■ Keeping reliable socket connections open to a heterogenous population of mobile, browser, and IoT devices.

■ Handling devices with spotty connections (tunnels, slow connectivity, etc.) with reliable deliverability

These are just a tiny number of the 1000 paper cuts that can kill a project. Today, mature Edge Messaging Networks are the easy choice, since they often only charge based on usage, so getting started is a low-cost, low-risk exercise.

Unlike so many "mega-trends" that seem to offer so much, but take a decade to adopt, Edge Messaging is a trend that's been long needed, and delivers benefits almost immediately.