Marc’s Musings

Since finding out about EBS, I’ve been playing with it and Amazon’s EC2 (their Elastic Compute Cloud) and am very impressed.

After my intial tinkering I’m to the point where with a couple keystrokes, I can start up an instance of a virtual machine anytime I want.  It can range from a "good" machine to an insanse server with copius amounts of CPU and RAM.  So far I’ve only been using the smallest instance type since that beats out my current dedicated server box by a good margin. 

I’m about 90% sure I’ll be switching my hosting over to this.  Here’s my short analysis that I did while deciding.

Right now I have a dedicated server.  It’s a Celeron 2ghz with a 1GB ram and a single 160GB hard disk.  A comparison between that and EC2 yields the following:

Pros:

Reliability - Right now I’m one hardware fault away from a weekend rebuild of the server.  I’ve got plenty of backups and wouldn’t lose any data, but there would be a royal pain in the ass in reconfiguring a new server.  Under EC2, I’d be one command line away from launching a brand new instance that has the exact configuration as the original server.  The EBS storage is on a more reliable, redundant, platform than the current single-disk configuration that I have.  And even if that were to fail I have the same level of backups that my stand-alone server has.  So worse-case, I have to launch a new instance and restore some databases.

Performance - The smallest EC2 instance has more ram and more CPU power than my dedicated server.  The largest EC2 instance is equivalent to about 15x of my current server which means I can scale quite a bit without even thinking about clustering, which leads to…

Scalability and scaling speed- Imagine I get on the front page of some very busy site and have a traffic explosion.  With EC2, In 20 minutes I could provision a much beefier machine to act as my server.  With the stand-alone option, I’m looking at ordering a new server, waiting for it to become available, configuring it, moving data over, waiting for DNS to propogate to it, that’s probably a few days at the least.  Beyond that, with EC2, I believe I could set up a cluster in a weekend instead of who knows how long.  But more importantly, EC2 allows me to scale back down just as easily when the traffic dies down so I’m not stuck paying for the peak possible usage forever.   This is the "Elastic" part of "Elastic compute cloud"

Cons:

What if EC2 or EBS becomes unavailable for some reason?  Amazon had an S3 outage last month and it could happen to these services.  I have no good answer here.   Amazon doesn’t have an SLA for EC2 yet, I assume they will eventually. The only solutions for a problem like this are:

1. Create an instance in a different EC2 availability zone (Each AV is supposedly seperate and hopefully outages own’t span them).  Unfortunately the EBS volumes aren’t shared across zones, so I’d have to restore a DB from a backup.
2. Boot up virtualization software, such as VMWare, on a dedicated standalone server and run it on there.

What if Amazon discontinued EC2?  Luckily, the images can be converted to other virtual machine formats.  So I could go to another hosting cloud provider or get a dedicated server running VMWare and boot up my server on it.

Cost-wise, with EC2, I’ll be spending about $10 less a month than I do now for a dedicated server.  (Sounds like a "Pro", huh?)  But, I’ll be on metered bandwidth so that cost will raise over time whereas the dedicated server had the first 1500GB free so it’ll cost more eventually (assuming my traffic continues to grow).  But then again, the per-gig cost of Amazon is lower than my hosting provider.  So if I started to break the 1500GB barrier (unlikely for the foreseeable future), EC2 would start to win again.  

Conclusion:

For me, the reliability is the tipping point one way or another.  I have more confidence in Amazon’s datacenter than I do in a single stand alone dedicated server so I believe it’ll be more reliable.  But I have no way of knowing that for sure. 

Either way I need a decent disaster recovery plan.  With EC2, that plan can be a couple steps from really-easy (starting a new EC2 instnce), to a medium ground (Starting an new EC2 instance and restoring a database), to fairly difficult (provisioning a physical stand alone server and configuring it).  With a stand alone server, that plan is a single step jumping right to the "configure a new server" stage.

This week, one of the projects I’ve been working on for the past year and a half ships.

Now, I have no idea if this next statement is actually true since I haven’t done extensive research.  But TimeLiner XE may be the first AIR app to ship.  And by “ship” I mean the more traditional meaning of the word, from a warehouse, on a CD, in a box.

This is a product that I’m really proud of.  We had a really rocky start in the development process, but I ended up taking the lead of most of the project and we were able to deliver something that I hope will really help kids out in school pretty close to the originally planned ship date.  It’s probably the most complex product I’ve ever worked on, and is definitely the biggest project I’ve managed.

For a little background, I work at an educational software company that sells directly to schools.  Because of the market, we generally need to produce our products on a CD, in a box, and with a (gasp) printed manual.  Sounds old fasion, doesn’t it?

It’s worth reflecting on the physical manifestation of software… It’s amazing how much satisfaction you can get from actually holding that beautifully designed box that is meant to contain your work.  Just to know that it was someone else’s job to go through iteration after iteration of design, and then someone else’s job to put ink on a piece of cardboard, and someone else’s job to assemble that cardboard.  All so the piece of software YOU worked on can be delivered to the customer in style.

The box is also great for those times when relatives ask what you do, and you can just point to that on your shelf and say “I made that.”  Then they can look at the pretty pictures on the box, or even crack the manual to see more pretty pictures.  It’s a lot easier to explain than giving out a URL to an AIR install badge or even giving a quick demo.

Unfortunately, there’s also an impending feeling of doom when you realize that you don’t get to update that software for a long time.  What if you missed some critical bug?  You lie awake at night wondering if you remembered to take out that September 1st expiration date that the Beta’s had and you wonder if QA ever tested that.   Those CD’s will last a long time and you can’t just throw up a new version of a web page and make all of the old versions disappear.  Sure we can do downloadble patches, and sure we’ll have a 1.1 version someday. But there is a certain feeling of permanency to the whole process.  I mean a major screwup means pressing new CD’s and packing them, and paying for postage.  That could be thousands of dollars.

I’m not sure if I dare to go check that expiration thing now…

Quick note, there’s a new signup for AgileAgenda betas.  Towards the end of the month, we’ll probably be releasing a Beta with a ton of improvements including things like fully integrated time tracking, resources across projects, and RSS feeds of tasks.