Iron.io Joins OpenStack to Drive Open Cloud Message Queues


Iron.io is now an OpenStack supporter. This may not appear all that unusual – given the top companies originally behind the initiative plus the growing numbers joining – but it is noteworthy for a cloud services company. 


With most cloud services, it shouldn’t really matter what the underlying IT stack or even what cloud you’re running on. API-driven services essentially abstract the VMs, infrastructure, and scaling away to provide elastic utility-based computing. Just plug into the APIs and eliminate the need to provision resources based on current or anticipated loads. 

Cloud Services Everywhere

 
But with the types of services that Iron.io provides – message queuing, task processing, data caching, and job scheduling – the locality of the services is important. Developers want these types of services close to their applications and in different configurations and combinations. 

Given that we believe message queueing, task processing, caching, and job scheduling are critical components within any production-scale application, we want Iron.io to be a part of every application built within every cloud platform running on every cloud infrastructure. OpenStack’s thought-leadership, traction, and increasingly prominent support makes it a clear bet to drive innovation within public and private clouds. And so it only makes sense for us to be a part of this effort. 

OpenStack Open Message Queuing Protocol

One key aspect with our support is not just in laying a marker on the cloud infrastructure layer but also in rolling up our sleeves and helping to define open cloud messaging protocols – ones that we believe will define the next generation of messaging platforms. 

We’ve spoken a bit about messaging protocols a bit before in this post. Current messaging protocols such as AMQP aren’t going away. They have many years behind them and many referenceable installations. It’s just that we don’t believe AMQP or any existing standard will be the messaging protocol in common use within the cloud going forward.
What's needed instead is a simple, secure, reliable messaging protocol that is HTTP-based, supports JSON out of the box, and is designed to support widely distributed and massively scalable sending and receiving. Older protocols could be adapted to this world, but coming up with something native to the cloud that's based on cloud application patterns will appeal to cloud developers now and the many that will follow in years to come.

OpenStack Marconi Project

This effort towards the future of Internet-scale messaging is encapsulated in the Marconi project. Kurt Griffiths from Rackspace is driving the effort forward. +Travis Reeder and +Evan Shaw from Iron.io have been influential in defining the API. Here's a description of the project:

 

 

Marconi is a new OpenStack project to create a multi-tenant cloud queuing service. Our aim is to create an open alternative to SQS (producer-consumer) and SNS (pub-sub), for use in applications that run on OpenStack clouds. The project will define a clean, RESTful API, use a modular architecture, and will support both eventing and job-queuing semantics. Users will be able to customize Marconi to achieve a wide range of performance, durability, availability, and efficiency goals.

We will fully support the protocol and plan to have the best and most reliable implementation available. We have a wealth of experience in this arena.  IronMQ is a high availability message queuing service that runs on several public clouds (AWS and Rackspace). It's tried, tested, and true – serving over 250M API requests a day.

Compute + Storage + ...

 

 

 
blankTo put the importance of the project in context, much of the emphasis with cloud protocols to date has been on the Compute and Storage aspects of the system. They are huge areas that form the core of any cloud application. But production-scale applications with lots of asynchronous activity need ways to connect processes within a system, interface with other systems, buffer activity to databases, and power service oriented architectures. To do this, you need a reliable messaging layer.

 

Here’s how HighScalability describes the importance of message queuing:

 

"[Y]ou can find a message queue in nearly every major architecture profile on HighScalability. Historically they may have been introduced after a first generation architecture needed to scale up from their two tier system into something a little more capable (asynchronicity, work dispatch, load buffering, database offloading, etc). If there's anything like a standard structural component, like an arch or beam in architecture for software, it's the message queue."

 

And so to us, the real equation in a cloud system is:

Compute + Storage + Message
blank

If you believe a cloud-native messaging protocol will be at the center of the next wave in connecting systems – and that the connections will not just be point-to-point within a closed system but on globally distributed and massive scale – then OpenStack and the Marconi project are efforts to pay attention to. 

Great things are happening in this space and we’re thrilled to be a part of OpenStack and helping to drive open cloud messaging forward.

Leave a Comment





This site uses Akismet to reduce spam. Learn how your comment data is processed.