This is part 8 in a 10 part series: 10 reasons for the growth in middleware appliances. The series summarizes what we’ve learned from our clients about what they value in appliances and why they selected Solace.
For over two decades, messaging middleware has been transporting information between distributed applications so they don’t need to be directly connected. Over the years though, many strains of messaging have evolved, with highly specialized products to address niche problems like low latency, WAN synchronization, or internet data streaming. But the real workhorse of the space, is the kind of messaging that started it all. Guaranteed messaging doesn’t get the headlines, but it quietly addresses the vast majority of use cases.
This post explains how Solace fundamentally changes the guaranteed messaging game by rewriting the rulebook on what’s possible in terms of throughput, latency and simplicity. To fully understand what we’re doing for our customers today, we will first look back at how guaranteed messaging evolved in software.
In most distributed computing scenarios applications require assurance that data will be delivered, often in the order it was sent, or an administrator must be informed when delivery is not possible. That’s what guaranteed messaging does.
There are different message patterns, such as point-to-point, publish/subscribe, and request/reply, but the basic idea with guaranteed messaging is that applications can publish information to the message bus and know that it will get where it needs to be, whether the journey takes 20 microseconds, 20 seconds, or 20 hours. What kind of applications are we talking about? It’s easier to describe what applications aren’t best suited for guaranteed messaging: market data, some real-time gaming, and some sensor networks. Pretty much everything else is best done with guaranteed messaging.
The two most popular choices for guaranteed messaging today are IBM MQ and (persistent) JMS. IBM MQ pioneered the space a quarter century ago as a way to get data in and out of mainframe queues and continues as a queue-based product. JMS was a standards driven initiative aiming to modernize those ideas for the UNIX age, but its Achilles heel was lack of interoperability, leading JMS to stagnate post 2002. More recently AMQP is looking to deliver what JMS left undone, and shows some promise, but so far has not garnered mass adoption.
Regardless of which kind of guaranteed messaging is being used, software-based systems have a fundamental problem. They run on general purpose computers and need to access disks through an operating system. They “guarantee” that data won’t get lost by writing it to non-volatile storage (i.e. a disk) which is fundamentally slow. Moore’s law says today’s servers are about 30 times faster than those from 10 years ago, but the performance of hard drives has advanced much more modestly due to the physical limitations of disk platters.
As a result, today’s most popular guaranteed messaging products have performance characteristics that assume a disk write bottleneck. In the best case scenario, they can achieve thoughput of a few thousand guaranteed messages per second. This suits many applications, but if you do need more, you have to scale horizontally by adding more servers, buying more licenses and adding architectural complexity to your solution.
At Solace, we wiped the slate clean before we started designing our guaranteed messaging architecture, but with the important advantage of controlling all the hardware.
The key insight was that most messages (>90%) flow directly from sender to receiver while both are up and healthy, and writing the data to disk almost always turns out to have been a waste of time. So rather than optimize for the least common scenario (always store messages assuming the receiver might not be there), Solace optimized for the happy state where messages are received immediately, in which case they never have to be written to disk.
Then we used a series of hardware innovations to assure that data stored in memory can never be lost. Here’s a high level summary:
There are a lot of grizzly details in this white paper, but basically we eliminated the disk from the path between applications with no risk of message loss. Long-lived data in transit still ends up on disk eventually, but only after the fact using smart buffering techniques. As a result, Solace can achieve unprecedented throughput and latency rates with fully guaranteed delivery. How fast?
We usually claim throughput 10-20 times greater than commonly used software guaranteed messaging, but that’s actually lowballing because nobody believes us when we tell them it’s 100 times more. Our appliances are rated for 150, 000 messages per second – that’s 100 byte messages, fully guaranteed, from one sender to one receiver through the appliance. If you compare that to the throughput of typical MQ or JMS products, which deliver 1, 000 to 3, 000 messages per second, that’s between 50 to 150 times the throughput of software-based messaging. Our performance gets even better if you’re fanning out to multiple subscribers, where those 150, 000 published messages per second can be fanned out at up to 500, 000 messages per second.
It’s hard to visualize how much more throughput that is, so let’s take a look at a picture. These circles have relative areas of 1, 3, 150 and 500, representing MQ, JMS and Solace throughput. If these circles are cross-cuts of plumbing pipes, today’s software guaranteed messaging is like a drinking straw compared to Solace’s fire hose.
It’s worth noting that Solace’s messaging includes a JMS API, so for companies that use JMS today, Solace can be a drop in alternative at 50-150X the rates. Other customers have bridged MQ into Solace to take advantages of the greater throughput and cost savings.
While throughput is going way up, latency goes way down because disk writes are removed from the messaging path. Where MQ or JMS guaranteed messaging latency are in the order of a millisecond or more, Solace offers, still with full guarantee of delivery mind you, between 70 and 100 microseconds, depending on rate. Once again the details are in the white paper if you are interested. I may be a marketing guy, and nobody believes the marketing guy, but fortunately these numbers are all easily reproducible, turnkey, out of the box.
A common response is that this is overkill for a given application’s requirements. So who needs this kind of performance? A lot more companies that you think. Here are four profiles for our guaranteed messaging customers:
To be frank, some customers have bought our guaranteed messaging solution even when it seems like overkill. Their logic went like this “If I can buy state of the art technology that handles anything I can dream up for the forseeable future, and it costs less than just the equivalent, less-capable software I need right now, why wouldn’t I?” It is compatible with the JMS they use today, or an easy migration from MQ. The only difference developers and applications notice is that all the performance constraints they’re used to disappeared.
So there you have it. The War and Peace of guaranteed messaging blog posts. This subject got a mention as part of the other 10 reasons, but it gets its own spot on the list because it’s so differentiated in the market that it often becomes the single biggest reason a company chooses to become a Solace customer.