The obvious and easy choice was Amazon Web Services (AWS) Elastic Compute Cloud (EC2). A hosting service such as EC2 allows a lot of flexibility in server solutions including quick ramp up if the luxury problem of needing more servers occurs. Freedom to choose operating system and providing a virtual server resembling what you get from a traditional hosting services were also important for us. There were alternatives, traditional hosting services where you book physical servers would incur a larger fixed cost than we wanted and at the same time, we would have lost the flexibility. We currently fire up servers and test things in no time just to shut those servers down after the test. With a traditional hosting provider, we would need spare servers for testing or used the live servers. Windows Azure could have been an alternative, but it’s just a .NET Windows hosting environment and not flexible enough. I feel I should mention Google App Engine as well, but we didn’t really consider it since it’s too restricted and even more locked in than Windows Azure.
We decided to use CentOS for the servers. The reason for this was favorable experience with Fedora over the last year and Ubuntu getting more painful at the same time. Red Hat Enterprise Linux (RHEL) was a contender, but CentOS provides us with the part of RHEL that we need without all the parts that we would pay for, but not use. Debian would have been our choice a few years back, but the Fedora and Ubuntu experiences over the last year brought us down on the Fedora, RHEL, CentOS side and as mentioned, CentOS was the best fit among those three. Windows wasn’t considered. We had absolutely no need for anything Windows in there and remote management and configuration of Linux systems is so much easier while being extremely stable. The Amazon Machine Image (AMI) we use was created by RightScale.
Web Serving Environment
We chose Apache because that’s what we’ve used in the past and Apache is solid and dependable. The downside of Apache is that it’s a big beast that might be overkill for our need. An alternative that we looked a bit at is nginx, but we didn’t want to spend time on that before launch. We will however look more closely at nginx in the future.
I am a rubyist and we chose Ruby. The first time I tried Ruby, I wrote a few scripts that I would normally have written in Perl. These weren’t big scripts, but far from one-liners. They downloaded some content and analyzed it. Writing the scripts in Ruby took me a bit longer than it would have taken writing them in Perl, but they worked right away. In Perl there is always something wrong unless you have a one-liner. The strongest alternative was Python and between Ruby and Python it comes down to taste. The first readability I got as a Googler was in Python and I did write a lot of Python, but it still doesn’t feel right. I was very happy when I got a chance to sneak myself to a Ruby readability. Java was sort of not considered, but would have been the choice if the lightweight short time-to-market alternatives hadn’t been available. We use Phusion Passenger to serve a combination of pure Ruby racks and Sinatra apps in Apache.
Our LARC stack (Linux Apache, Ruby, CouchDB) works very well for us and that combination has enabled us to develop our service very quickly with the result being an easy system to maintain. We haven’t really looked back at those choices except for a few moments after upgrading to CouchDB 0.10.0 and seeing that our map reduces that put a lot of work in the reducers had to be rewritten. One look at MongoDB‘s query language stopped those regrets. As mentioned when discussing web serving environments, we do consider switching from Apache to nginx, but it’s not a high priority thing and we are happy with Apache and the consideration comes more from curiosity than need. As for CentOS and EC2, they just work and gets out of the way which is exactly what they should do.