Cons of Cloud computing and how to avoid long down-timeadmin | Wednesday, September 2nd, 2009 | No Comments »
Cloud computing does everything as promised -
* Takes the head-ache of scaling up/down based on the traffic requirement
* You would pay only for the traffic and no need to speculate the traffic
* Hi-powered computing availability transparently
Well, great! – Every good thing comes with a few setbacks that you should be aware of and plan accordingly to mitigate the setbacks.
The Cons are -
* Check for the level of up-time in SLA : Just because the technology is in the ‘cloud’ does not mean you would expect availability or up-time of five-9s (99.999 ). There would always be down-time which your business might not be able to bear the losses.
Mitigate this : Go with the biggest cloud vendors such as Amazon (Ec2) or Google (Azure) or Microsoft and make sure the SLA indicates the level of up-time that your business requires.
* Red flag – Upgrade! Upgrade! Upgrade! - Google had a down-time of couple hours yesterday when upgrading one set of servers. What does this mean? Like I said, your data in cloud, does not mean the underneath operating system or your application database or application itself is always current. They require timely patching or upgrades as you would do on physical infrastructure. Keep in mind that ‘Cloud’ could be shared by several other businesses and you are prone to down-time during such upgrades
Mitigate this: Make sure that the SLA specifically addresses this upgrades and what other arrangements would be happening when upgrades are imminent. Plan accordingly at least a week as outlined below
A) Clone the current cloud instance(s)/Grid into new instance(s) or Grid of cloud that is upgraded. Run tests to make sure that the upgrades/patching did not break the behavior of your application. One this is done, communicate to your customers that there is an imminent application upgrade that would be happening on such and such date and time – flash them on the application screen to remind them.
B) make sure that the master-master transaction database is ready to take the production traffic
B) If you need the DNS changes, take care of them as required
C) Slowly send the users to the new home and be on alert to make sure that users are not seeing anything unusual. Keep a feedback form in the corner so that users can write about different behavior they are experiencing
D) If everything goes smoothly which typically never happens without a glitch, note down the different steps and measures you took for this exercise for future
Although it would seem a bit complicated, its not hard at all. We at ElasticCloudPro, have done this couple of times and have experience in migrating server farms from physical data centers or to a new cloud infrastructure consisting of farm of instances (grid) or even into a single instance.