Extending Standards Support by Embracing AMQP 1.0

Since we founded our company with the goal of disrupting the enterprise messaging market, the application landscape has shifted dramatically. Back then, there was no cloud and the market for messaging was dominated by two commercial, closed, proprietary products: IBM MQ Series (now IBM WebSphere MQ) and TIBCO Rendezvous.

But in the last decade or so, the increasing popularity of open and de facto standard messaging APIs and protocols have brought enterprises and developers relief from those days of vendor lock-in. Namely, JMS for general Java-based messaging workloads, RESTful applications for point-to-point, MQTT for IoT, and WebSockets for streaming to browsers and mobile devices.

All that progress has allowed many more use cases to be addressed in an open way without the risk of vendor lock-in, and Solace has been championing these technologies and techniques. We’ve supported JMS for years, and more recently added REST capabilities and support for MQTT and Paho APIs to our platform.

There’s one thing missing from this list that next-generation architectures absolutely need – an enterprise grade messaging protocol capable of handling the kinds of workloads needed between enterprise applications and companies themselves.

That’s where AMQP comes in. The AMQP working group (now part of OASIS) has been around for nearly a decade, and I myself have been part of that process, but it took longer than anyone expected to ratify an official specification in 2012, which became an ISO/IEC standard in 2014. Early versions were implemented as proof of concepts, and have found some adoption in the market (most notably in the open source code base RabbitMQ based on version AMQP 0.91), but versions prior to 1.0 are not wire or API compatible with the AMQP 1.0 standard that will be supported going forward.

Since we joined the AMQP working group back in 2009, our strategy has been that we will add AMQP support into our products when the demand from the market matches the clear promise of AMQP as difference-making open standard protocol – that time is now.

Today we announced that we are hard at work building enterprise-grade support for the AMQP 1.0 protocol into our multi-protocol platform, and we expect to deliver a first version in early 2017. That implementation will work with the existing Apache Qpid APIs, and we’ll work with the open source community to improve them over time to benefit all AMQP users.

Why now? Because AMQP 1.0 is an important standard protocol that enhances our “Open Data Movement” strategy and because so many enterprises are asking us to do so. Enterprise architects are planning for their migration to private and public clouds, and it’s clear that their proprietary protocols won’t come along for the ride. They need an open standard protocol for heavy duty workloads, and AMQP 1.0 is the right fit for the job.

There’s been a chicken-egg challenge in the form of lack of enterprise-grade support, which is where we come in. We are no longer the ambitious little startup that was taking on the big guys a decade ago. Today Solace is the established leader in modern messaging and has won the trust of the most demanding companies in the world. We have a track record of helping enterprises break free from vendor lock in, and more customers have migrated from IBM and TIBCO to Solace than any other platform.

Of course, we’ll make sure our AMQP 1.0 exhibits the same kind of performance and stability we have delivered in everything we do. We’ll also make sure it fits cleanly alongside MQTT, JMS, WebSockets streaming, and RESTful messaging to allow unified sharing between all kinds of endpoints. We’re confident it will be the best AMQP 1.0 implementation to date.

Summary

The shift to the cloud has created a unique opportunity to take control of your application infrastructure, and we want to help you make it happen. By committing to open standard protocols for new and migrating workloads you’ll have maximum choice and a much easier time changing horses if what you’ve chosen today looks like the wrong choice tomorrow.  The key is that you retain the freedom and flexibility to control your own future. We say “Choose open standards, and may the best implementation win!” We think that will be ours, but welcome all comers that will help make this technology meet the needs of all kinds of workloads.