Tuesday, July 17, 2012

Amazon and Rackspace: A Comparison, Part 1

This will likely be an on-going set of posts as I make my way through figuring out which one is the better offering.

 My company is failing in matters of redundancy and failover. I've been here for almost 2 years. When I stepped in as a Junior Sys Admin we had 1 of everything: 1 Apache server, 1 MySQL server, 1 Tomcat server, 1 switch, 1 ASA. Now, SaaS is a new frontier for me. Most of my previous sys admin work was spent in environments that had already been running for a while, and pretty much served inside users; employees and maybe the occasional contractor. These were small to medium-sized businesses that could get away with a single point of failure because if their ASA went down they wouldn't be losing revenue. Productivity time, sure, but not actual client-based revenue.

 In the SaaS industry, your infrastructure is your revenue. Your clients depend on you to provide the kind of environment that they can't necessarily provide for themselves: backups, high availability, etc. I coudl go into the history of my company and how it didn't start as a SaaS provider, hence the lack of foresight in building out the infrastructure, but I'll save that for another post. Suffice it to say that we are now, on my watch, playing catch up and trying to shape our infrastructure into what it needs to be to stay afloat.

I put together a presentation with the options as I saw it. I essentially researched and laid out the pros and cons of 3 options: staying in our data center and expanding physically, i.e. purchasing bigger/better hardware, expanding into multiple/bigger cages, etc.; staying in the data center but essentially creating our own cloud using VMWare or XenServer; or moving into someone else's cloud, like Rackspace or Amazon. After going through the various features, costs, and implementation challenges of each it was decided that the cloud was where we would be going. The only thing left to determine was if it would be Amazon or Rackspace.

Due to issues involving our in-house application server, I had opportunity to test out implementation sooner than I'd anticipated. After the read-only incidents and the failed controller/drives, we had a bunch of our own internal projects that needed to find somewhere else to live. I initially moved them into the data center with our clients just so that we could continue to work, but my plan is to move our development project to Amazon using their micro instance which is free, and to move the rest of us in to Rackspace. I figure this will give me good experience on the ins and outs of setting up either service and help me to determine which is a better fit for us. I admit I'm leaning heavily towards Rackspace for the following reasons: their customer service is unparalleled, their offerings are easy to understand, their control panel is simple to navigate, and you can combine physical and virtual systems pretty seamlessly. Amazon, on the other hand, really requires that you read the manual (closely and many times) to even begin to understand the various services they offer and how they fit in together. Just trying to get an estimate on how much an instance would cost was difficult and required metrics that quite frankly we don't have. Hell, just connecting to an instance from SSH is unwieldy. So, follow me as I try to set up services using both providers.

I had already set up a micro instance some time ago. When you set up an instance you create a keypair that will be used for SSH instead of the old-school user/password combo. Turns out that when I recently cleaned my computer of temp and downloaded files, I also got rid of my ppk file. No problem, I thought. I'll just create another one. Mmm, not so fast. You can't change the key being used by the instance. You have to actually terminate it and create another one. Understand that for a second. Let that wash over you. Say you create some keys, you create some instances using these keys, and then an admin leaves your company. With username/password-based SSH you simply remove them, right? With keypairs you'd generate a new key and distribute it to those who need it. With AWS, you have to actually terminate (that is, delete) your instance and start over again to make that change. Wow.

I deleted the instance, grumbling the whole way, and started again. This time I saved my private key to a network location. It took me a bit to jump through the hoops of connecting again (downloading puttygen, converting the pem to ppk, getting Putty set up right, getting the right username, etc.) but I finally did and I started setting up my server. I installed Tomcat, MySQL, and was all set to try and connect. I couldn't get to my Tomcat app on port 8080. Quick search revealed that the security group that I had created for the instance was in fact the only security group being applied. I had thought they'd be aggregate, but not so. I had named the security group SSH and so I wanted to remove it and add the 8080 rule to another more generically-named group, like the default group. I'm anal; sue me. Well, I couldn't delete the group because it was attached to the instance, and I couldn't point the instance to another security group. The option is there but grayed out and is apparently only available to VPC instances. Again, the only way to associate your instance with a different security group is to, you guessed it: terminate it. Seriously. This is definitely something that should be able to be done on the fly.

Fine, I'll suck it up and use the SSH security group and add the 8080 rule to it. I still can't pull the page up. Another check shows that even though my security group is the one being applied, it's not actually applying the rules. The rule set looks empty from the view of the instance, i.e. it shows that nothing from that security group is being applied. Ultimately I had to delete my instance again and start over, using the default security group and editing it to include whatever ports I needed open. Once I did this I finally got it to work.

I now have a working micro-instance in AWS for our development team to use for testing their Android application. It's an all-in-one box providing all web services and backend database service. In that sense it's not a true-to-life test of deploying our actual environment, but it was a good exercise in what it's like to get even basic services established.

Next, we try on Rackspace.

No comments:

Post a Comment