IronMQ Handles 100 Million Messages a Day
Overview
Iron.io reached a key milestone on Christmas Eve this year. IronMQ, our cloud-based message queue, reached its first 100 million messages per day mark. To put this in perspective, Salesforce recently announced it's handling 1B transactions/day. Twitter has 140MM users tweeting 500MM times a day and Github records 500,000 events per day.
Handling 100 million messages a day is a solid milestone for us and we couldn’t be happier. The service was released in December 2011 and in the course of these 12 months, we’ve seen strong growth. More and more cloud developers are realizing not only the benefits that message queues provide – we’ve listed a number of these reasons in a post on Top 10 Uses for a Message Queue – but also why cloud-based messaging makes so much sense.
Table of Contents:
Achieve Cloud Elasticity with Iron
Speak to us to find how you can achieve cloud elasticity with a serverless messaging queue and background task solution with free handheld support.
The Rise of Distributed Cloud Computing
In our minds, hitting this mark really just lays down a marker on the start of a new era of distributed cloud-based messaging and event-handling. We frequently hear people in the space saying the cloud changes everything. And while it’s true, we’re only at the beginning of what cloud computing and elastic services can truly provide.
Much of the news on cloud computing these days is focused on PaaS and IaaS. In other words, it’s about launching servers and deploying runtime apps. But behind every cloud-application of any complexity or size lies a number of independent processes, task workloads, and connections to other systems. All this activity needs a way of gluing these pieces together. Hence, the message queue.
[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.
From HighScalability's repost of Top 10 Uses for a Message Queue
From Monolithic to Distributed – From the Start
It’s not just second-generation architectures deploying message queues. We’re seeing more and more developers start out with a distributed application in mind and including message queues and asynchronous processing right as a core part at the onset.
Besides the ability to scale workloads more easily, one of the bigger advantages of starting with a distributed app in mind is it makes it easier to build features and expand capabilities. Instead of having one process directly invoke another process, it’s much cleaner to use a message queue to keep the processes separate and independent. Need to post a notification about an event – easy, just add a message to a queue and a separate notification process can pick up messages from the queue and take care of the task.
By putting in a middle layer between processes – instead of invoking the second process directly – the processes become independent of each other. The first process above doesn’t need to know how to post a notification and it doesn’t have to monitor the process flow of that second task. It’s just putting a message on the queue and continues on with its processing.
The other processes can also just do their work independently, creating a system that’s easy to grow and maintain. Message queues also provide an easier and more rational way of handling exceptions. If the notification process fails, the corresponding message to the action can be put back on the queue for retrying or placed in another queue specifically designed for handling exceptions and escalating issues. (Try doing exception handling when processes are tightly coupled.)
Putting in this type of design upfront results in code that’s far less brittle and much easier to maintain and expand. Which is a huge benefit regardless of whether you’re just getting to market or are already a hit and growing 30% month-to-month.
Iron.io Serverless Tools
Speak to us to learn how IronWorker and IronMQ are essential products for your application to become cloud elastic.
Thanks for subscribing! Please check your email for further instructions.
Benefits of Cloud-Based Message Queues
Adding message queues to cloud applications only really makes sense though if there’s a net gain in terms of installation and operation. Adding a messaging layer by having to stand up servers and deal with reliability (servers, API connections, monitoring, log files, etc..) is not an easy task for most teams, even ones with a dedicated sysops team.
When message queues are easy to set up, simple to use, highly available, and extremely reliable, a whole new world opens up. The analogy is the generation of power. The progression moved from water-driven millstones to individual coal-fired factories and ultimately to industrial-scale power plants and transmission lines. This last step – the industrialization of power – transformed the industry and the world. It lowered the cost of building and making things, revolutionized cities, factories, and homes, and ushered in new inventions, services, and businesses.
Similarly, by plugging into elastic messaging services, developers will no longer have to maintain large sets of queues running on multiple servers. In an elastic world, service providers like Iron.io take on the responsibility for seamlessly managing servers, API endpoints, multiple zones, and other infrastructure resources and abstracting away most physical constraints.
Benefits of the shift to cloud-based messaging include:
- Speed to market: applications and systems can be built much more quickly
- Reduced complexity: reduced risk/overhead in critical but non-strategic areas
- Increased scalability: ability to seamlessly scale throughput and functionality
What’s Next
As we look to 2013, the future is bright for message queues and distributed apps. The message bus has been a key part of enterprise systems for a number of years and now, with the ease and advantages of the cloud, message queues will take new forms and uses.
The ease of an HTTP/REST API, the simplicity of string and JSON message formats, and the flexibility of OAuth security bring messaging to many more people and far sooner in the development cycle. Add in high availability and the ready throughput of an elastic service, and you get production-scale use within hours and awe-inspiring apps within days.
Just as VMs have made it easier to create new applications, elastic on-demand message queues and asynchronous processing will power another era – large-scale distributed cloud-based systems where message passing is abstracted away from servers and where ease of use, reliability, monitoring, and features specifically for cloud apps are key.
Developers will win because they will be able to build and scale applications much more quickly, at a lower cost, and with far less complexity. Iron.io’s mission is to drive this shift in computing and deliver this higher value.
We’re pumped to reach 100MM/day... But back to work. We have millions and billions more to go. Stay tuned.
Unlock the Cloud with Iron.io
Find out how IronWorker and IronMQ can help your application obtain the cloud with fanatical customer support, reliable performance, and competitive pricing.
Congrats guys. Here’s to a very distributed 2013 and all it will open up!
“A very distributed 2013” … love that. Thanks for all the support.
No more Far que, and Far que too. All synchronous elastic scale and deployment options for incoming and outgoing data models connecting to Public and Private Clouds via various Apps developed through an OAuth certified Payment gateway or Facebook credit scenario. How good does 2013 look for the future of all developers?
thanks for sharing.
AWS provides SQS, what is your difference?
100 Million messages is not much actually, especially for a day.
Firat.
Sosyal Medya
@sosyal
SQS does not guarantee FIFO, does not guarantee one-time delivery, and has far greater latency (on the order of seconds at times). SQS has uses an XML message format.
IronMQ offers high-availability multi-zone message queue with FIFO, one-time delivery, and fast cloud performance. IronMQ’s message format is string/JSON-based which makes it much easier to use. For developers building modern cloud applications and/or connecting cloud apps to external or legacy systems, IronMQ is a solid and reliable choice.