September 24th, 2013


Erik Onnen: Vice President of Architecture at Urban Airship

Matt Pfeil: Co-Founder at DataStax


Today we have Erik Onnen, Vice President of Architecture at Urban Airship, with us today. Erik, thanks for joining us. Why don’t you tell the audience what Urban Airship does?

Thanks Matt. Urban Airship is fundamentally a mobile relationship management company. We view it as our job to provide our customers with the best possible means of interacting with audiences on mobile devices.


That’s great. Could you maybe give an example of one of your customer use cases, so we can provide a little more flavor?

Sure. A common use case for our customers would be breaking news. For example, if you have the USA Today application and you get breaking news alerts (today they probably sent 3 or 4 already) we power those push notifications that go to those devices.


We also power inboxes for rich app user experiences as well. Offers of the week, for example. We are an underlying technology that a lot of the leading mobile applications use to deliver downloads, photos and videos, surveys and more to users. 


That’s awesome. I actually have the USA Today mobile app on my iPhone and I get those notifications all the time. Now I know who to contact if they don’t come through.

Yes, that’s us.


What’s your use case for Cassandra?

For us, being able to provide those mobile notifications that you see on your phone requires devices to register with Urban Airship’s backend and effectively give us a channel in which we can communicate back to those devices.


It’s slightly different between an iOS device versus an Android device or a Windows device. We support all of these platforms, Blackberry added onto that, as well. Ultimately, at the end of the day, there are hundreds of millions (if not of billions) of devices that connect to our infrastructure and provide metadata. Again, that might be a channel in which we can reach the device, but it also might be functionality that we provide that allows better segmentation of an audience to ensure the most relevant and valuable interactions possible.


Behind the scenes, all of that data is written into a cluster, or two or three, depending on the specifics of the data. That’s really the job of Cassandra to be the firing line for all devices that responded to our infrastructure, and to accommodate that traffic in a scalable way that we can easily add capacity when we need.


Those were some some really interesting stats mentioned, especially a billion devices. Out of curiosity, how big is your infrastructure? Can you share some stats about what it looks like?

Great question. We run all of our Cassandra clusters on bare metal hardware. These days, we try to put everything we’re doing with Cassandra on SSDs and give at least 96GBs of RAM.


We found that the combination of those two things actually lets us run on an overall net smaller deployment footprint. So, where in the past I would run an 18 – 25 node cluster on rotational media, we’re able to compact that down to a much smaller footprint and run on fewer clusters, but still get the throughput that we need.


Zooming out a little bit, today we run 7 different Cassandra clusters. Each one is very specific; we do that so that we can tune each to specific workloads and throughput dynamics as opposed to running everything in one large cluster. We found that it works better for our infrastructure and we can more easily tell if a certain piece of functionality is growing very quickly and requiring more scale. We know exactly where to add hardware, as opposed to amortising the workload over 30 different servers, or 60 different servers.


All in all, within our 7 Cassandra clusters, the smaller side on the smaller side is an 8-node cluster running on SSDs; while the largest cluster right now is 26-nodes including a blend of rotational media with a few SSD driven machines due to various legacy reasons.


That’s great information. If my memory serves me correctly, you and I have known each other for a while and you guys have been long-time Cassandra users, especially for growing to the size of clusters that you’ve mentioned over the years. What was your original motivation for looking at Cassandra? What other technology did you either migrate off of or evaluate it against?

Our workloads that I’ve described to you tend to fit a key value store very well. We like to have what we call a “migratory schema approach” where we can fluidly add things into our infrastructure in a rolling manner that allows us to change our data model on the fly, without having to take an outage and update a piece of code everywhere across the infrastructure.


In that sense, the column model worked really well for us. We are a very big Java shop and the fact that Cassandra is written in Java, opposed to Erlang, offered us confidence that we could get into the source, learn more about how the database works and contribute to the community. It fit very well with our model.


In terms of things we migrated off of; we also have some Postgres shards in our infrastructure in a legacy capacity today. Postgres is a great relational database, but in terms of our ability to add or remove hardware in a fluid manner, it just didn’t fit the needs that we had. We just didn’t need some of the more advanced relational capabilities. The key value model worked very well for us for the workloads that Cassandra supports today.


We’ve moved a good bit of infrastructure (we’re going pretty far into the “way back” machine here) off of Mongo DB just because the reliability of that platform didn’t meet the requirements that we had at the time.


As I mentioned earlier, Erik has been a long-time user of Cassandra, as well as community member, and you spoke the 2011 Cassandra Summit in San Francisco. There will be a meetup in Portland in the near future, so stay tuned tuned to Planet Cassandra for more information on that. Erik, I really want to thank you for your time today.

You’re most welcome, Matt. Thank you.