Search This Blog


Wednesday, February 29, 2012

Rackspace Guest Post: Gives App Developers Agility, Scalability Boost

Here's a piece that Travis Reeder posted for the Rackspace Blog the other day.

Much of the discussion of the cloud stack these days centers on app servers and storage. Whether it’s deploying, monitoring, scaling, making fail-safe or redundant, the base model is one where app servers and storage solutions are the core of the cloud stack. This view is certainly a correct one but it’s only a partial picture and here’s why. 
My co-founder, Chad Arimura, and I are cloud developers at heart. When we started working together, we were developing applications for others. Although the cloud was just emerging, we made the fortunate decision to create applications using 100 percent cloud resources. The use of these virtualized resources — namely app servers, NoSQL databases, and object stores — allowed us to quickly build some heavy-duty applications with very small teams. But project after project, it was clear that the core of each app was more than just a set of app servers and data stores. 
Even at the onset of building a cloud app — but especially as we needed to grow and scale it — several patterns become clear, 1) all the parts and components of the application needed to be loosely coupled, 2) a lot of processing needed to be offloaded to the background, 3) messages and events needed to be exchanged in ways that were non-blocking and asynchronous, and 4) getting the right flow for the granular pieces — the data and processes — was as important as dealing with the bigger blocks in the architecture.
For the rest of the post, go here →.

Tuesday, February 21, 2012 is now on Rackspace

We’re happy to announce that IronMQ, one of’s premier application services, is now included as a service within the Rackspace Cloud Tools program. We’re especially proud of this milestone because in addition to being multi-platform and multi-language, we are now also multi-cloud.

IronMQ is a hosted message queue for orchestrating data and events within cloud apps and between systems. Accessible through simple API calls, the service provides high-performance messaging without having to manage servers or maintain infrastructure.

IronMQ - An Essential Component Optimized for Rackspace Developers
An easy-to-use, scalable and durable messaging system is essential for building loosely-coupled components and non-blocking data and event handling. Cloud apps need to exchange large volumes of data between internal processes as well as with other applications, sites, and services. With this volume and increasing number of interchanges, a middle layer is needed so that senders and receivers can work asynchronously and independently from the activities of others.

For example, uploading a new document to a cloud service might cascade a number of other actions. Message queues are a primary way to orchestrate these types of actions both internally and when interfacing with other systems. Developers are using IronMQ to process massive amounts of streaming data, connect mobile apps to backend systems, orchestrate sequencing and processing flows, sync with legacy systems, and handle many other critical messaging needs.

Including IronMQ within the Rackspace cloud means that developers have access to a high-performance hosted message queue that runs in the same cloud as their applications and datastores. Rackspace developers not only gain an essential component of the modern cloud stack but also one that has been optimized to work within their cloud environment.

Easy Decision + Developers Benefit
Making the decision to bring IronMQ to Rackspace took all of a few seconds. Rackspace is a key player in cloud infrastructure and is making some very strong moves with OpenStack and other initiatives. When the proposal came up in the product meeting, it was a quick set of +1’s around the table.

Actually standing up the IronMQ service within the Rackspace cloud, however, wasn’t as simple. Don’t get us wrong. Rackspace is easy to work with both technically and on a personal level. But bringing an elastic and massively scalable service to new cloud infrastructure took some doing. We’re fortunate in that we have a great team that thrives on building high-performance systems and so they readily took to the challenge. 

The nice thing about us doing the heavy lifting is that Rackspace developers get to build durable message handling into their applications with simple API calls and without having to worry about managing servers or dealing with redundancy, fault-tolerance, scalability, and other system concerns. 

Rackspace Option in the IronMQ HUD (Dashboard)
Rackspace + IronMQ
The benefits of IronMQ included as a Rackspace Cloud Tool are not difficult to see. We share with Rackspace a similar vision for what the future of IT looks like.

Rackspace Cloud Hosting
  • Rock-solid cloud provisioning
  • Managed service capabilities
  • 100,000 strong user base
  • Fanatical customer service
  • Hosted message queue
  • Easy to use/flexible interfaces
  • Durable, secure, massively scalable
  • Multi-platform, multi-language, multi-cloud

An Additional Note
One great thing about partnering with Rackspace is that they’re known for their fanatical customer support. We don’t claim to be at their level but it’s certainly something we’re striving for. If you’re a Rackspace developer, we urge you to give the service a try and let us know what you think. if you have questions or need some help, stop into our public chat room. You’ll find many on Team Iron hanging out there. 

To learn more about IronMQ, please visit the IronMQ product page.

To see learn more about IronMQ on Rackspace, please visit the Rackspace Cloud Tools page.

Monday, February 20, 2012 is sponsoring AngelHack 2.0. is sponsoring AngelHack 2.0. AngelHack brings together startup communities from around the country for hackathon competitions. Participants spend a weekend building startups ideas which are then judged by top angels, venture investors, and tech bloggers.

AngelHack 2.0 will be on March 3-4th and will be held in San Francisco and Boston. 700+ participants are expected and over $75k in prizes will be awarded -- including prizes from for the top apps use IronMQ and/or IronWorker. Should be a great event so keep an eye out on the weekend and the 5th especially.

Prizes for top apps using

Tuesday, February 14, 2012

When Unit Tests Aren't Enough... ABT - Always Be Testing

Traditionally, developers create unit tests to test code and to ensure bugs don't get introduced as time goes on and your code changes. The theory is that if you write tests that cover every line of code, then when you make a change and the tests still pass, you can feel pretty comfortable that it will work as it should.

Well there is a lot more that can go wrong in your production system than introducing a bug in your code.

What Else Can Go Wrong?

Your database could fail, your hardware could fail, your cloud provider could fail, your network could fail, your load balancer could fail, your users could do something unexpected causing a failure, etc, etc, etc. There are so many points of failure in a full production system that testing your code alone just isn't enough, not even close.

Always Be Testing

One of's core values is reliability. All of our services are built with reliability in mind meaning we do whatever we can to ensure that our services are running at all times and that our users can rely on us when building their applications. We provide core infrastructure services and our users depend on us to be reliable because if we go down, they go down. Continuously testing our services is part of ensuring that we are reliable and we are always looking for new ways to test and monitor our systems so we find problems before any of our users do.

One of the best ways to test every piece of a system is to test the piece that is closest to the user whether it's the user interface or an API. Testing at the edge ensures that we're testing the entire system including the API/UI, the servers, the databases, the hardware, third party services, etc. We're testing from the top all the way to the bottom of the stack and back again.

The ABT (Always Be Testing) Gem

I created a simple testing framework (for Ruby) called abt that given a git repository URL, will clone the repository, run the tests and send out notifications (customizable). This is not the same as Continuous Integration (CI) as you know it. A typical CI server will kick off your unit tests when someone commits changes to code. ABT is run on a schedule using IronWorker so the tests are run regardless if the code has changed.

And it's easy to use, here's a step by step.

1) Get an account so you can use IronWorker

If you don't already have an account, go sign up now at, it's free.

2) Install abt gem

sudo gem install abt

3) Ensure the library you want to test can use the ABT config parameters

The tests should check for a global $abt_config variable, for example:

Have a look at this file for a real world example in the iron_mq gem.

4) Queue it up on IronWorker to run the tests

There is some configuration for IronWorker and configuration for the test suite you want to run. Then we just specify a git URL and pass along the configuration in test_config. Finally, we add some notifiers, in this case we're using the included HipChatNotifier, but you can create your own to do whatever you want whether it's sending an email, notifying PagerDuty or posting a Tweet.

So after it runs we'll get notified in our HipChat room if it passed or failed with the details.

Here is a post to HipChat for a failing test:

And here is an example post for a successful test:

5) Schedule it to run continously!

Now let's schedule it to make it run every 30 minutes. Just change worker.queue in the code above to:

This will run the first test right away and then repeat the test every 30 minutes indefinitely.


So there you have it. A simple way to constantly be testing your production and/or staging environments. Constant Integration testing if you will. And it's pretty easy to make any ruby client library work with the abt gem (it just needs to know how to access the configuration), so you can start using it right away.

If you are running a service people depend on, you should abt, always be testing. 

Source Code and more Information:

Friday, February 10, 2012

Rate Limiting Your Workers to Play Nicer with Other API's

Many third party API's have rate limits to ensure you don't overuse or DoS them. Twitter for instance has the following rate limits:
  • Unauthenticated calls are permitted 150 requests per hour. Unauthenticated calls are measured against the public facing IP of the server or device making the request.
  • OAuth calls are permitted 350 requests per hour and are measured against the oauth_token used in the request.
Now that's not a lot of requests! 2.5 requests per minute if unauthenticated. So how can we slow down/throttle our massive queue of Twitter related tasks in IronWorker so we don't hit that limit?

Using IronWorker's 'delay' parameter for Rate Limiting

IronWorker supports a 'delay' parameter (docs) when you are queuing up a task which allows you to specify a time to wait before the task will be eligible for execution. 

So let's use Twitter for example, if we have 10,000 tasks and each task will hit twitter once, we can skew our tasks to ensure we don't hit the rate limit. If we can do 2.5 requests per minute against the Twitter API, then let's stick to 2 IronWorker tasks per minute (leave a little room just in case). So here's how you could queue up those jobs:

And there you have it. A nice, simple way to throttle your workers. 

Wednesday, February 8, 2012

Platforms, Languages, and App Services : Economies and Communities of Scale

Platforms, Languages, and App Services
The case for cloud platforms is being made convincingly these days. Platforms magnify the power of virtualized cloud infrastructure first by providing an ability to quickly deploy and scale applications. And second by providing greater visibility and control of this virtual environment. The growth and success of platforms such as Heroku, AppFog, and others make it clear that this component of the cloud stack is not just central to building scalable apps but also key in terms of reaching and influencing developers.

The trend towards a polyglot world is also something that has gained momentum within the past year. Successful companies like Heroku, AppFog, Twilio, and New Relic realize the innovation taking place across a wide spectrum of computer languages and rather than picking sides or playing favorites, a +1 strategy around all languages makes the most sense. And as much enthusiasm and momentum as cloud platforms appear to be getting, languages are generating even greater heat and passion among developers. The creation of communities of interest around dynamic languages and frameworks is only just accelerating.
And so it shouldn’t be a surprise to see us move into a multi-platform multi-language world. The announcement of PHP and Python support along with release as an add-on within the AppFog program are important milestones for us. We bring our services to two important language communities -- PHP and Python -- and we add AppFog, a cloud platform leading the way towards a NoOps world, to our list of other platforms we’re integrated with.

The IT Reference Model for the Next 5-10 Years
The developers in these communities creating cloud applications represent only a small fraction of the app development taking place but they’re leading the way in what the future looks like. The tools and services they are using -- along with the patterns and best practices -- are the ones that will make up the IT reference model for the next 5-10 years.

Our goal at is to be a key part of this reference model. We see Messaging as a Service and Background Processing as a Service as essential elements within the emerging cloud stack. Combining elastic messaging and background processing with scalable app servers and expandable storage solutions is a natural fit.

An obvious benefit this combination provides extremely fast application development with far less complexity. A common reaction with using platforms and infrastructure services is that developers almost feel cheated because it’s too easy to get started. They don’t have to earn their stripes by doing a lot of sys ops work (standing up servers and loading up OS and binary images). Of course that quickly turns into one of relief because they’re able to get right down to the core of the application.

Economies and Communities of Scale
And now, it’s not only speed and agility that come to the forefront. With proven platforms and application services, developers also get scaling, durability, and the potential for massive capacity. These benefits can accrue to the leanest startups as well as to mega-organizations with multiple applications, large datasets and the need to compete with companies much more nimble.

The combination of cloud platforms like AppFog and Heroku with dynamic languages like PHP, Python, and Ruby and application services like IronMQ and IronWorker are changing IT in ways that are only apparent once you start using them. Fortunately, the numbers are in favor and growing each day and all along the way, these developers are creating new economies and new communities of scale.

IronWorker and IronMQ now on AppFog

Today, we’re happy to announce that IronMQ and IronWorker are now included as supported add-ons for AppFog. We are very excited about this partnership because we share in the AppFog vision of creating fast, scalable and reliable applications in the cloud.

Through our partnership, we will be helping developers by providing massively scalable messaging and task queues so they can spend far less time managing infrastructure and more time on the things in their application that really matter. is fully committed to supporting multiple languages and platforms. Our products currently run on Heroku, Engine Yard and AWS. The addition of AppFog is an important next step in’s expansion. Stay tuned for future language and platform announcements...

To learn more about IronMQ and IronWorker, please visit our product page.

To learn more about the and AppFog partnership, please visit the AppFog’s add-on page.