Evaluating Rackspace vs Amazon (AWS)
With cloud computing becoming the norm these days, many software start-ups are developing their products as web-based solutions. At some point, this decision necessitates picking a cloud service provider. Its usually a decision between Rackspace vs Amazon. We delayed the decision until we were a few months away from launching our product (mainly to conserve cash, but also because we had no reason to commit to anything until that point). At that time (September 2012), Rackspace offered free hosting for up to a year to start-ups; while there were other factors, that weighed heavily on our decision. Since that year recently expired, we re-evaluated our earlier decision and ending up choosing Amazon AWS.[caption id="attachment_2480" align="aligncenter" width="294"] Should we go with Rackspace?[/caption]
Having had experience with both services, I've outlined below some of the pros and cons that we observed when evaluating Rackspace vs Amazon. Every startup is different, of course, but hopefully this will provide some insight into why we chose Amazon.
Rackspace's claim to fame is their "fanatical" support, with which we only had limited experience (fortunately). But for the times we did need to contact them, there was a live person to chat with or talk to on the phone.
Amazon doesn't have a number to call to talk a real person, or even a live chat feature. However, when we were evaluating their cloud offering, I did have a chance to speak to someone in their sales department, who offered to have a Solutions Architects review our system architecture. We haven't needed to take them up on this offer yet, so I can't say if that was just part of their sales pitch or not.
Rackspace vs Amazon Customer Support Winner: Rackspace.
When we signed up for Rackspace initially, it was very early in their shift to the "public cloud," so we found they lacked a lot of features. Fortunately, we were able to find workarounds, but even after a year of using them, lots of features still didn't exist. Amazon's public cloud is much farther along in terms of their feature set.
Rackspace's load balancer solution was very rudimentary. We were unable to get Web Sockets to work, which is a technology that we rely on to "push" notifications to everyone that has joined a deposition. In addition, they did not support 256-bit SSL encryption (only 128-bit was supported). We ended up spinning up a separate server and run our own load balancer using haproxy as a workaround for both issues.
Amazon's load balancer supported both Web Sockets over SSL and the ability to have 256-bit SSL encryption. It still leaves a few things to be desired (like being able to have a "backup" server which web traffic is routed to only in the case of a primary server failure), but it's still light years ahead of Rackspace.
Rackspace vs Amazon Load Balancer Winner: Amazon.
VLAN / Firewall
In September 2012, Rackspace had not yet deployed their VLAN solution (called "Cloud Networks") so we had to engineer our own. That meant we had to manage iptables on every server and encrypt the traffic between all of our servers (because otherwise any other Rackspace customer would have been able to "sniff" the traffic between servers). Managing iptables on multiple servers became a maintenance nightmare. They eventually deployed Cloud Networks, but we never had the time to update our design, so I can't really speak to how it works now.
When we switched to Amazon in September, we were able to take advantage of their VLAN solution (called "Virtual Private Cloud", or VPC). We restrict traffic into and out of each server using Security Groups (instead of iptables), which is much easier to manage. We still encrypt traffic between servers because of our previous design, but we may re-evaluate this decision in the future.
Rackspace vs Amazon VLAN Winner: Undecided, since we never tried Rackspace's Cloud Networks. However, I lean towards Amazon because it lets us load balance between two different availability zones within the same VPC, giving us high availability at the same time.
Rackspace's public cloud allowed us to use servers in either Dallas or Chicago. To provide guaranteed uptime, it would have required setting up a completely parallel environment in both geographic regions. Because these regions are not connected internally to each other, architecting this would have been difficult.
When we switched to Amazon, our production environment was able to span multiple "availability zones" within the same VPC, which means all of the traffic between each availability zone is secure. We have deployed our environment in the U.S. East geographic region and we have parallel environments in Availability Zone A and C. According to Amazon:
Each availability zone runs on its own physically distinct, independent infrastructure, and is engineered to be highly reliable. Common points of failures like generators and cooling equipment are not shared across Availability Zones. Additionally, they are physically separate, such that even extremely uncommon disasters such as fires, tornados or flooding would only affect a single Availability Zone.
Because we replicate our data in real time from Zone A to Zone C, if Availability Zone A ever has an extended outage, we can re-route traffic to Availability Zone C with minimal downtime.
Rackspace vs Amazon Infrastructure Winner: Amazon.
Rackspace's user interface is very intuitive to use and required no learning curve. In addition, if you ever lock yourself out of your server (for example, by applying the wrong iptables/firewall rule), they have a "web console" that lets you log right into your server as if you were sitting in front of it with a keyboard and monitor.
Amazon's robust feature set naturally makes their user interface more complicated. They've actually improved it some since we switched over, but there was a big learning curve because the design was very unintuitive. In addition, on occasion we did lock ourselves out of a server, and when that happened, we had no way to access it (via a web console like Rackspace) and had to spin up a new server using the old image in order to recover our data.
Rackspace vs Amazon User Interface Winner: Rackspace.
During our tenure with Rackspace, they were continually performing maintenance on their infrastructure, which on one particular occasion caused an interruption in our service (at the most inopportune time). At other times, we would simply lose the ability to access a particular server, and would have to reboot it. We did not feel comfortable with unexplained outages, so when it came time to start paying for the service, we looked to other options.
There have been some pretty high profile outages of Amazon's Cloud, most notably the NetFlix outage in December 2012. However, with the ability to load balance between "availability zones", we've minimized this risk substantially. Theoretically, with our architecture, the only chance of a lengthy outage is a natural disaster taking out all of their entire facility in Virginia. That's their official line, anyway.
Rackspace vs Amazon Reliability Winner: Amazon.
Rackspace and Amazon both have different server configurations, so comparing price is not an easy task. However, when looking at the most comparable servers, we decided that they are very similar in price. Rackspace wins the price category for companies who are just getting started, but once you have to pay they are roughly the same. The big difference came down to the fact that Rackspace charges for servers whether they are running or not. With Amazon, we can have an entirely separate testing environment using the same number of servers as our production environment, and not pay for that service unless we start the servers. Because we don't need to have all of our test servers running 24/7, the difference in cost was substantial. Our Amazon bill is roughly 30% of what our Rackspace bill was with the same configuration.
Rackspace vs Amazon Price Winner: Amazon.
Reasonable people can disagree with our conclusion in comparing Rackspace vs Amazon, but with the extra features Amazon offers along with the ability to minimize our costs by turning off unused servers, it was a no brainer for us to switch to Amazon.