Blogs

9 Common Reasons Cloud Systems Crash: Things to Remember When Negotiating Cloud Contracts

09.12.14

TexasBarToday_TopTen_Badge_Small (1)

My 2011 eCommerce Times column “Cloud Computing – New Buzzword, Old Legal Issues” reminded many folks that “the technology concept behind cloud computing has been around for more than 50 years, and the legal issues are equally old.” Obviously the reasons Cloud systems crash are equally old news, so it would be wise to negotiate Cloud contracts with these 9 common reasons in mind thanks to eWeek’s report on August 13, 2014:

  1. Human Error. This is by far the No. 1 cause for cloud downtime. Even with perfect applications, cloud environments are only as good as the people who manage them. This means ongoing maintenance, tweaking and updating must be worked into standard operational procedures. One bad maintenance script can—and will—bring down mission-critical applications.
  2. Application Bugs. While the cloud does introduce a new level of complexity, application failure still trumps cloud provider issues as a leading cause for downtime. More often than not, such failures are unrelated to the cloud infrastructure running your applications. Traditional IT practices still apply, except that you are continuously developing, testing and deploying your application in the cloud.
  3. Cloud Provider Downtime. Cloud failures are routine. Whether it’s an instance, an availability zone or an entire region, applications should plan for these failures. This means routinely checking performance and spinning up new instances to replace terminated machines. Amazon Web Services, for one example, enables users to spread and load-balance an application across several availability zones so that when one does fail, the application does not suffer.
  4. Quality of Service. As far as consumers are concerned, streaming videos that freeze up mean your cloud is not working. They don’t really care (or even know) that the application is technically speaking still running. That means accommodating for network latency, fluctuating demand and shifting customer requirements.
  5. Extreme Spikes in Customer Demand. This is actually a great example of cloud superiority. If customer demand exceeds capacity, there’s not much you can do with an on-premise IT infrastructure. In a public cloud environment, you can respond to fluctuations in customer demand by automatically scaling capacity during peaks and backing down when demand levels off.
  6. Security Breaches. Security is often raised as a red flag when it comes to hosting critical applications in the public cloud. Much like on-premise environments, it’s up to you to comply with regulatory and security concerns. However, the cloud does make it easier to check off a list of security requirements, since cloud providers have addressed these concerns repeatedly with hundreds of enterprise customers.
  7. Third-Party Service Failures. The whole is greater than the sum of its parts, but all it takes to bring your cloud down is one third-party app that isn’t working. This could happen to any type of infrastructure application (sustaining, garbage collecting, security and so on) in yours or another supplier’s data center. It’s up to you to continuously monitor these applications as well and have a contingency plan in place for a rainy day.
  8. Storage Failures. In a recent disaster recovery survey, storage failure was listed as a top risk to system availability. The cloud still depends on physical storage, which routinely fails. Much like overall service availability and quality, storage issues can lead to serious performance issues. This means planning for these failures by setting up dedicated cloud storage applications that maintain data resiliency and meet data retrieval requirements
  9. Lack of Cloud Disaster Recovery Procedures. Although disaster recovery has been a common practice for decades in physical data centers, cloud DR only recently has come under scrutiny. Few realize that it’s the customers who are solely responsible for application availability. Cloud providers can help you develop failover and recovery procedures, but it’s up to you to integrate them into your applications.

Look at your Cloud contracts and make sure you are properly protected to avoid these Cloud disasters.

The publications contained in this site do not constitute legal advice. Legal advice can only be given with knowledge of the client's specific facts. By putting these publications on our website we do not intend to create a lawyer-client relationship with the user. Materials may not reflect the most current legal developments, verdicts or settlements. This information should in no way be taken as an indication of future results.

Search Tips:

You may use the wildcard symbol (*) as a root expander.  A search for "anti*" will find not only "anti", but also "anti-trust", "antique", etc.

Entering two terms together in a search field will behave as though an "OR" is being used.  For example, entering "Antique Motorcars" as a Client Name search will find results with either word in the Client Name.

Operators

AND and OR may be used in a search.  Note: they must be capitalized, e.g., "Project AND Finance." 

The + and - sign operators may be used.  The + sign indicates that the term immediately following is required, while the - sign indicates to omit results that contain that term. E.g., "+real -estate" says results must have "real" but not "estate".

To perform an exact phrase search, surround your search phrase with quotation marks.  For example, "Project Finance".

Searches are not case sensitive.

back to top