• 12/11/2013
    11:06 AM
  • Rating: 
    0 votes
    Vote up!
    Vote down!

Top 10 Cloud Fiascos

We don't mean to give cloud laggards encouragement, but you can learn from their concerns. Consider the evolution of the cloud disaster.


Are on-premises deployments any less prone to downtime or NSA...

Many of these slide commentaries seem to assume that on-premises deployments are less prone to failures and security leaks. Cloud infrastructure and service providers are under the microscope, so we read all about it. Meanwhile, the average private enterprise data center has its share of gaffes and lapses -- some would say more than its share -- but the mistakes tend to happens in obscurity, unless they're required to divulge a data breach. This is what it says it is, a report on 10 cloud fiascos, so I guess it's up to the cloud providers to contrast their track records with the typical on-premises experience.

Re: Are on-premises deployments any less prone to downtime or...

I absolutely think that cloud deployments are less prone to downtime; NSA hacking I don't have a good enough sense of things.  But we do give up control when we go to the cloud, which amplifies the cloud fiascoes.

Re: Are on-premises deployments any less prone to downtime or...

I don't think cloud will offer 100% uptime - in any providers' SLA, there is no such kind of term. However, I do trust that with the built-in mechansim and the nature of cloud, it's more robust and scalable compared to its on-premise peers. I think this is the good reason for IT to go for cloud. As long as we have something better and the beneift beats the cost, it's a progress. 

Re: Are on-premises deployments any less prone to downtime or...

Cloud providers are going to say whatever it is that they have to in order to sell their services. I don't think that they mean any ill will. But at the same time the only way that they can grow and become established is by obtaining users and growing the amount of user reliance that there is on their service. 

They will say what they have to. 

Cloud Security

Doug is absolutely right, there is no way to do an apples-to-oranges comparison of enterprise apps vs cloud apps on the topic of outages. There are also security issues relating to Snowden that have nothing to do with cloud. But Joe effectively shows how our notions about cloud "disaster" have changed in the past 2 years.

Easter outage was poster child of cloud collapse

I agree with Joe's number 3, Amazon's April 21, 2011, Easter outage is the poster child of cloud collapses. A human error of unplugging a main trunk network and replugging it into a backup net was compounded by automated systems trying to recreate data that suddenly appeared to be missing. It set off "a remirroring storm." It tied up several services used across availability zones, even though an outright failure didn't spread across zones. I've have had my differences with AWS execs. over interpreting the impact, but from my own interviewing, it did affect multiple zones. At the time, a second system in a different zone was your guarantee of availability. The event signalled changes were needed in Amazon's architecture for it to have a more foolproof approach to continuous availability.

Re: Easter outage was poster child of cloud collapse

Incidents like that also punctured the inflated claims about cloud systems being inherently resilient. With careful design, they might live up to that vision, but nothing is automatic.

Case Study: On-premise vs. Colocation vs. Cloud for SAP HANA

On-premise hosting can be less secure and take up more resources than cloud hosting, depending on who you have running things. There are other risk factors to consider, like the inherent risks of constantly adding, upgrading, and updating servers. 

On-premise is inherently inflexible. Once you invest in on-site systems, they can be very expensive and complicated to maintain, upgrade, or replace as you look to support additional applications or greater user volume in response to changing business needs.

The advent of hardware colocation offered up the next phase in data center evolution, helping companies to address some of the challenges associated with on-premise. In colocation, businesses rent space in a third-party data center, install their servers in the space, and run their applications on these off-site systems. The benefits of colocation include less demand on the customer's own data center, and potentially greater reliability and business continuity through third-party providers.

That said, other limitations still remain, including the cost, complexity, and inflexibility of owning, managing, and upgrading hardware.The most recent evolution, cloud hosting, has provided an alternative to the high costs of purchasing, supporting, and maintaining SAP systems. Hosting provides access to hardware as a service, while assuming all the costs and complications of owning, managing, and upgrading the hardware. This arrangement virtually eliminates capital expenses associated with running SAP HANA, and converts costs to operating expenses.

Just like choosing any provider or business partner, you have to pick a provider with a good reputation and known track record. Cloud hosting actually ends up saving quite a bit of money and manpower when done correctly. Check out this whitepaper on why deploying in the cloud is quickly becoming the preferred method of deployment for SAP HANA:

Four graphs of marketing more than enough

Five graphs of Savvis marketing in Pragathipatil's "Case Study." Savvis is a certified SAP partner to host HANA. Maybe four would have been enough.

I still have a negative opinion of cloud services

Joe, I agree with your article and the points you raise on the first page.  When asked, I tell people to be wary of the cloud.  Also, to add to those points are:

·         What if the owner of the cloud service stops his cloud business?

·         What if the cloud service changes it rules?

·         What if the cloud service changes its pricing?

If you have these worries, you might consider using two or more cloud services to contain your data.  If one fails, then the other(s) will have a copy. 

The more I look at it, the more it looks like the banking industry in the early days.  My mother and father were from the great depression, and after that, they learned to spread their money using several different banks.  If one failed, then the remainder of their money would be available.  In other words, do not put all of your eggs into one basket.

Re: I still have a negative opinion of cloud services

I generally agree with what you're saying, although I don't think the analog to banking is quite on point.  In banking, what you're storing (money) and the value of the thing (money) are the same, and the services are essentially fungible, and the additional transaction costs of splitting your money are fairly low, so it inherently makes sense to diversify risk by spreading around the money.

However, with cloud computing, what you're using is hardware, but the value of the thing is your entire application running.  Also, services are not really (or just barely) fungible, and the transactional costs of splitting your application(s) across cloud providers is very high right now.  Also, you will have a more fragile and slower architecture if you're spreading your application across the public internet.

I think a better strategy is that you want to make sure you can always move your workloads to another cloud, but that you may actually choose to simply run in one cloud for now.  So you want an abstraction layer to issue your various automation/orchestration commands to, and you want full configuration management so you can relaunch servers easily, but that is the vast majority of what you'll really need to do to mitigate your risks.