The Day the Cloud Went Bust

If you are on Twitter, I am sure you recognize the illustration: the Twitter whale signals that the system is not working as it should. Unless you are in the middle of a tweet-up, Twitter being out of service is unlikely to be more than annoying. But what about other cloud applications we have come to rely on? Do you know how damaging it is to your business when they are not available?

The company I work for is strict on disaster recovery and business continuity planning. We created our local DR/BC plan a few years ago, and every year we test it when my cheerful colleague Basil comes up with a new fictional disaster. My team and I work our way through the recovery plan to see if we have thought of everything to get the business restored in the shortest amount of time possible. During recovery training we re-establish the business sites and get the systems back up and running. But when we had our latest exercise a few weeks ago, I realized that we don’t perform this exercise for the cloud applications that we use. And that is not good.

Don’t get me wrong; I believe the cloud is the way forward. I think that many companies would be far better off using cloud systems than spending time and money on creating bespoke applications so they can do business like they always did. For the majority of companies, cloud applications offer more than enough features to run their processes. Moving to cloud applications gives them swift access to functionality that would be too costly to own, or take too long to build. New functionality is introduced regularly and hardware costs are shared. In addition, with the increasing risk of cyber threats it is best to put your apps and data in the hands of seasoned professionals who are fully focused on these topics.

But with the cloud comes a business risk that I believe most companies are not well prepared to handle: what will you do if one day your cloud provider goes bust? Some cloud providers have been around for a long time and are well-established, but the hype brings a lot of new entrants that certainly won’t all survive. And recent history has taught us that there are not many companies that are too big to fail. So it’s best to be well prepared.

We want to believe that cloud providers like Salesforce, Facebook, LinkedIn, Google, Twitter and so on are going to be around forever, but it’s unlikely they all will. Using reasonable business assumptions, we know that a number of them will not make it: they won’t receive a next round of funding or not enough customers sign up so they can’t pay the bills.

Since many people use Salesforce.com and are familiar with it, let’s use it as example in scenario planning (analog to when Basil takes us through the DR/BC exercise). Imagine that tomorrow, when you try to log in, you do not have access to salesforce. It’s simply not running anymore. Now I am sure that most of your sales managers have contact details for their customers on their smartphones, so that will get you through the first days. But what about the customer history? Leads and prospects? Recent marketing campaigns and customer participation? Tasks, opportunities and dashboards? Think about that for a second and envision how you are going to recover from that. And then take it one step further and make a list of all the cloud applications you use: what business functionality is at risk when the provider closes its doors?

When photo site Digital Railroad folded, customers had 24 hours to remove their photos. After that deadline, everything was gone. I read a number of License Agreements from cloud providers to find out what the customer position is. Most providers state in their License Agreement that the customer owns the data and describe how you receive that data at the end of the contract. Going back to the Salesforce example, the SF Agreement states that the customer receives “data in a comma separated value (.csv) format and attachments in native format”. After 30 days they delete all data. Google has its Data Liberation Front (dataliberation.org) that helps you get your data back. And in order to determine a standard, the IEEE recently started project 2301 on cloud portability and interoperability.

But even if you are able to get a data dump back from your cloud provider, the real problem is the missing functionality: how will you make sense of the data if the business functionality is not there and data relationships are missing? Now you might reason that this is not different from a software vendor that folds, but it’s not. In case a software vendor goes out of business, you will still have that software running on your systems, but it won’t be updated anymore. And that will give you ample time to continue using the functionality until you can migrate to a new system.

You might have heard of Schofield’s first law of computing. It says: ”never put data into a program unless you can see exactly how to get it out”. That’s really good advice to follow, but with the cloud there is an additional dimension: it’s the logic that makes it meaningful. So here it is, Anita’s first law of cloud computing: “never put data into a cloud program unless you know exactly how to get it out and replace the functionality”. In real life, that means that you must create an exit strategy that explains what to do when disaster strikes and your cloud provider becomes unavailable for good. Another idea might be to introduce source code escrow for cloud applications that are vital to your business.

Maybe the cloud is the future of computing. However, since we’ve already lived through Web 1.0 and 2.0, I’m not holding my breath. I am not saying that you should not move to the cloud, just the opposite: I think it’s the way forward. There is no point in trying to stop it: the cloud is cheap, sometimes free, fast, flexible and yes, secure. But if you want to protect your assets and the future of your business, you must be prepared, and a documented exit strategy is an excellent way of ensuring that your are.

You think odds are a disaster or something like this will never happen to you? That’s what we thought too. But one day it did. So it’s better to be prepared.