In the cloud, and back.

Unfortunately, not all projects that try to adopt cloud computing are successful. Some of them are doomed from the start, while others manage to limp along and eventually succeed. Although there are many successful implementations of cloud projects, on which businesses depend on daily, this blog is about an actual adoption failure, and attempts to present facts that led to this failure. The company in question is very large, does business at a national level, and is highly subject to seasonal activities; so cloud computing was very attractive for its ability to scale (up and down) and use multiple data centers for failover and high availability. However, as much as the high level alignment was right, many early signs of adoption were ignored and ultimately lead the company to almost entirely redo its technical architecture planning away from cloud computing. At least for now.

High Availability Requirements

While High Availability is a major attribute of cloud computing vendors, including Microsoft Windows Azure, it is slightly overrated as some organizations are starting to find out. Indeed, if you read the fine prints, high availability is usually expressed per month. So a 99.9% high availability on a database server in the cloud per month is in fact relatively low on a yearly basis. While this isn’t a significant problem for most organizations, it can spell trouble for the highly seasonal business. Indeed, if your business is highly seasonal, and you end up making 80% of your income within 60 days of the year, the systems better be up and running for 60 days with a 99.99% or better availability on a yearly basis. You just can’t afford downtime.

Too Early

While cloud computing has matured significantly over the last year or so, this project relied on very early versions of the Microsoft Windows Azure platform, which at the time only offered Platform as a Service capabilities. While staying on the bleeding edge is important for companies to remain competitive, this customer couldn’t be successful in this environment. There were too many workarounds implemented and unproven cloud architecture patterns selected; the lack of Virtual Machines and permanent storage disks was a significant burden for this project. This company simply tried to adopt cloud computing too quickly without starting with smaller projects to build up its knowledge capital.

Bad Taste

Last but not least, the cloud adoption failure left a bad taste with parts of the management team, making it difficult to justify any now valid cloud implementation patterns. This is a shame, because the company has difficulties in thinking beyond its current data center boundaries by fear of another failure. Indeed, who would go into a management meeting and propose cloud computing to this customer at this time? Timing, indeed, is of the essence.

While it could take time for this customer to look back and extract lessons learned for this significant adoption failure, it could very well help in unusual ways the next time around.  With a clearer understanding of the benefits of cloud computing, and some of its adoption challenges, this company will undoubtedly build a more thoughtful approach to cloud adoption over the next few years and build better customer solutions in the end. And although I don’t wish this kind of adoption pains to anyone, it could be a necessary evil for some corporations while cloud implementation patterns are better defined, and more widely understood by management and technical teams alike.

About Herve Roggero

Herve Roggero, Microsoft Azure MVP, @hroggero, is the founder of Blue Syntax Consulting (http://www.bluesyntaxconsulting.com). Herve's experience includes software development, architecture, database administration and senior management with both global corporations and startup companies. Herve holds multiple certifications, including an MCDBA, MCSE, MCSD. He also holds a Master's degree in Business Administration from Indiana University. Herve is the co-author of "PRO SQL Azure" and “PRO SQL Server 2012 Practices” from Apress, a PluralSight author, and runs the Azure Florida Association.

Print | posted @ Saturday, April 5, 2014 10:53 PM

Comments on this entry:

Gravatar # re: In the cloud, and back.
by Koshy at 4/6/2014 5:23 AM

more thoughts :

1.) High Availability - If the customer cannot afford downtime, a possible solution could be to deploy replicated db across regions (say east us, east asia). This is based on the understanding that MS has not brought down a service across all regions simultaneously.

2.) Too Early - Yes, IaaS does give a bit more flexibility, but Azure PaaS itself is really good if you don't mind the vendor-lock. I think the clue here is to adopt slowly - haste is always a waste.

3.) Bad Taste - Once bitten twice shy. A possible solution is to start low with an Azure private on premise offering, while migrating non-risky applications/process first, then go for a cloud-burst or move in entirety.

Last but not the least , have a thorough risk analysis and mitigation plan for cloud adoption.
Gravatar # re: In the cloud, and back.
by Herve Roggero at 4/6/2014 9:56 AM

Good points. However, high availability doesn't improve with replicating data across regions, because no cloud provider offers active-active replication of data. So cross region deployments help mitigate the risks by spreading loads on multiple data centers, but not for the overall high availability of your solution.

Regarding your assumption of MS has not brought down services across all regions is incorrect. Do you remember the issue with the signing certificates a couple of years ago? It even affected DNS routing that was supposed to help with cross data center mitigation planning. And MS isn't the only vendor exposed to such risks...

Great point about risk analysis and mitigation planning. In this particular case, what's interesting is that the mitigation plan was full replication to another cloud provider or internal systems, which becomes very difficult with PaaS, because of the vendor lock-in you mention. Interestingly enough, the only easy way to offer a solid mitigation plan is with the use of IaaS for the time being, until cloud vendors provide a uniform standard across PaaS solutions.

Thanks for your thoughtful comments.
Comments have been closed on this topic.