Karma

Pow is what we use for development on our local machines. It's easy to setup, and easy to maintain since it also eliminates the need for maintaining a /etc/hosts file. Pow

We use Bootstrap a lot. Everything that you see on our marketing website or web servers, it's all built from Bootstrap. Bootstrap

We use Rails for webpages and projects, not for backend services. Actually if you click through our website, you won't notice it but you're clicking though, I think, seven or eight different Rails projects. We tie those all together with a front-end library that we wrote, which basically makes sure that you have a consistent experience over all these different Rails apps.

It's a gem, we call it Karmeleon. It's not a gem that we released. It's an internal gem. Basically what it does is it makes sure that we have a consistent layout across multiple Rails apps. Then we can share stuff like a menu bar or footer or that kind of stuff.

So if we start a new front end project it's always a Rails application. We pull in the Karmeleon gem with all our styling stuff and then basically the application is almost ready to be deployed. That would be an empty page, but you would still have top bar, footer, you have some custom components that you can immediately use. So it kind of bootstraps our entire project to be a front end project. Rails

In the beginning we thought we wanted to start using something like RabbitMQ or maybe Kafka or maybe ActiveMQ. Back then we only had a few developers and no ops people. That has changed now, but we didn't really look forward to setting up a queuing cluster and making sure that all works.

What we did instead was we looked at what services Amazon offers to see if we can use those to build our own messaging system within those services. That's basically what we did. We wrote some clients in Ruby that can basically do the entire orchestration for us, and we run all our messaging on both SNS and SQS. Basically what you can do in Amazon services is you can use Amazon Simple Notification Service, so SNS, for creating topics and you can use queues to subscribe to these topics. That's basically all you need for a messaging system. You don't have to worry about scalability at all. That's what really appealed to us. Amazon SQS

For most of the stuff we use MySQL. We just use Amazon RDS. But for some stuff we use Amazon DynamoDB. We love DynamoDB. It's amazing. We store usage data in there, for example. I think we have close to seven or eight hundred million records in there and it's scaled like you don't even notice it. You never notice any performance degradation whatsoever. It's insane, and the last time I checked we were paying $150 bucks for that. Amazon DynamoDB

We use Sinatra a lot. I love Sinatra for APIs. It's really simple, really lightweight. It's awesome. Sinatra

The first time I actually started using Go was for software on our devices. So on our hotspots we have some custom software running in the firmware. For the first device, that was actually completely built by our manufacturer. But for the second generation most of the parts are built by us in-house and we needed a way to quickly develop software for the device. But we don't have any C programmers in-house, so we were actually looking for something that basically sits in between the friendliness of Ruby, but the performance and the ability to be deployed on an embedded system which you get with C. That's basically what led us to Go and it's been awesome for that. It works so well and so great. Since it works so great, it pushed us into looking into whether we should start using this for some backend services as well. Go

Most of our services are written in Ruby. We started out as a Ruby shop, but we're slowly also moving some stuff to Go. We're using Go more and more these days, actually, including some backend services. Ruby

Our architecture is running in Amazon VPC. That's actually what we started with and we're still very happy with. We’re pretty much tied into the entire platform. Amazon VPC

Nginx is the webserver we use in front of the Unicorn application servers. We have multiple Unicorn workers for every application (depending on their performance requirements), and Nginx basically functions as a load balancer. nginx