Welcome!

A voice of reason in a cloudy landscape

David Abramowski

Subscribe to David Abramowski: eMailAlertsEmail Alerts
Get David Abramowski via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Blog Feed Post

Clouds, lightning and media thunder


As reported by CNET News “Lightning took down Amazon Cloud” and confirmed by Amazon there was a small outage in the Amazon EC2 infrastructure.  The media decided that this is a great reason to run another hype story and provide you with a headline that is really misleading.  The Amazon Cloud (which is a rather large infrastructure) did not go down.  The truth of the matter is that a small number of servers in a single location were impacted due to a lighting strike that disabled a power distribution unit.

From this media thunder I now have the opportunity to evangelize cloud computing.  Let’s start with the premise that you have a web application running on an Amazon EC2 image and you use Amazon EBS to locate your database. Finally let us suppose that your image was on one of those ill fated servers. So how should this all play out, let’s take a look.

Since you have external monitoring of your application, you would have immediately been notified when the lightning strike took out your Amazon EC2 instance.  At that moment in time you would spring into action.  You first check the AWS health status to find out what is going on.  You see that there is a problem isolated to a single availability zone.   So now you know you need to bring up a server elsewhere.

So you issue the command to Amazon to give you an instance in another availability zone.  After a few minutes the server is available and you can install your pre-configured Amazon Machine Image.  This image is basically an exact copy of the server that went down.  Within five or so minutes the new server is alive and well fully configured and running your application.  You run a pre-configured script that makes a few configuration changes around security groups and data store connections.  You then re-configure your Amazon Elastic IP to point to the new server and voila, you are back in business.

Compare that to the same outage in a data center that isn’t using virtualization.  When a server goes down a major process ensues.  The data center team has to physically locate the server and perform diagnostics (hours?).  If they can’t fix the problem, then they either assign a new server (if one is available) or they install a new server (days?)  Once the server is installed, the software must be installed (hours?) and then finally a new IP address is assigned and DNS changes must be propagated to the world to make the server accessible (hours?).

Now each data center may have different procedures, but you get my point.  When you have a virtual infrastructure and you actually plan your architecture properly, hiccups are just part of every day business.  With the Amazon cloud, applications like mioworks.com can rely on the overall strength of the data center and compete on a level playing field – or maybe, they have an advantage because of the cloud’s flexibility.

Posted in Sofware Startup Tagged: amazon, Amazon EC2, aws, Cloud, cloud computing, EC2, web

Read the original blog entry...

More Stories By David Abramowski

David Abramowski is a technologist turned product leader. David was a co-founder of Morph Labs, one of the first Platform as a Service plays on AWS. He was the GM for Parallels Virtuozzo containers, enterprise business, and most recently he is the leader of the product marketing team for the IT Operations Management solutions at the hyper growth SaaS company, ServiceNow.