Customers scrambled to transfer data from Nirvanix’s facilities to other cloud providers or back on to their own premises. “Some folks made it, others didn’t,” says Kent Christensen, a consultant at Datalink, which helped a handful of clients move data out of the now-defunct cloud provider.
Nirvanix wasn’t the first, and it likely will not be the last cloud provider to go belly up. Megacloud, a provider of free and paid online storage without warning or explanation suddenly went dark two months after Nirvanix’s bombshell dropped. Other companies have phased out products they once offered customers for cloud storage: Symantec’s Backup Exec.cloud, for example is no longer being sold by the company.
More could be on the way: An analyst at Gartner’s data center conference late last year predicted that one in four cloud providers will be acquired or forced out of business by the end of next year, mostly though merger and acquisition activity.
With all these changes happening in the fast-moving cloud industry, it begs the question: What should users do if their worse-case scenario actually happens and their public IaaS cloud goes dark?
At the most basic level, preparing for your cloud provider to go out of business should start before you even actually use the cloud, says Ahmar Abbas, vice president of global services for DISYS, an IT consultancy. DISYS helps companies create a cloud strategy, and one of the first things to plan before going into the cloud is how to get the data out, at any time. “It all goes back to how businesses historically plan for disaster recovery,” says Abbas.
Typically DISYS will work with customers to classify the applications and data that are being placed in the public cloud and rank them based on criticality to the business. High-value data and applications that are mission critical need the highest levels of availability and are treated differently from low-value data that and organization can live without for a certain period of time. If a business is running a core enterprise app in the cloud that is crucial to the company’s daily operations, it should have a live copy of that app in another location, be it another cloud provider or on the company’s own premises, Abbas says. For testing materials perhaps there backup once a month, or maybe even not at all.
It all goes back to how businesses historically plan for disaster recovery.
— Ahmar Abbas, vice president, DISYS
There are other common sense steps users can take. First and foremost, be smart about who you choose to work with. “If you pick an Amazon or an IBM, then the chances of a severe event happening are much diminished,” he says. “They’re not going out of business any time soon.” Just going with a big-name provider isn’t a panacea though. Amazon Web Services and just about every cloud provider has outages and service disruptions, so customers should always prepare for the worst and hope for the best.
Cloud providers offer service-level agreements (SLA) which guarantee a certain amount of uptime. But, users should be careful they are following the SLAs closely to ensure their systems are architected in a way that they can be reimbursed for any downtime from their provider. Some vendors, like Amazon, require multiple Availability Zones within its cloud to be down before an SLA kicks in.
Customers can still find themselves stuck though in a situation like hundreds of users of the Nirvanix platform did though. If a data migration out of a cloud is necessary, Datalink’s Christensen says there are ways to make the process as efficient as possible. One is to reduce the amount of data actually being transferred using data caching, deduplication and WAN optimization tools. Some providers don’t charge for putting data into their cloud, and only charge customers for getting data out, so making that process as efficient as possible is beneficial. Datalink worked with a handful of customers after the Nirvanix bombshell and most were able to recover their data, or were already using Nirvanix as a secondary storage site. Christensen says that’s a common use case for the cloud today: Use it as a backup site so that the original copy of the data is still live somewhere else in case there is an issue in the cloud.
Noah Broadwater, who heads up digital products and technology for the Special Olympics, has been using cloud services for 10 years, so he’s aware of the risks cloud service providers pose. He’s come up with an innovative way to hedge his use of the cloud.
One of the biggest problems customers face if they do have to get data out of a public cloud platform is that the vendor may use a proprietary file storage platform, so even if the user is able to get data out from their defunct cloud provider, the end user may not have the ability to run those applications or data on their internal systems. “If you don’t have the system software to run it on, it doesn’t matter if you have the data, it’s unusable,” he says. Technically data mapping and cleaning can be done, but that’s a long and cumbersome process.
Broadwater’s come up with another way: Before entering into a contract with a provider, Broadwater negotiates an escrow account with the vendor that promises to have the vendor supply the most up to date version of the data software into a locked account.
Broadwater, as the customer, only has access to that account and software if the vendor declares bankruptcy or if the customer is unable to use data stored in the vendor’s cloud. “We can’t touch the code unless those clauses in the contract allow it,” he explains.
Broadwater uses a third party storage provider, in this case Iron Mountain, to hold the machine image of the software for the life of the contract. Vendors have been surprisingly willing to comply, Broadwater says. It is an extra expense in the contract, but it provides full protection without paying for a full secondary backup of all the data, he explains.
There are many ways customers can prepare for the worst-case scenario in the cloud. From simple disaster-recovery best practices, to unique plans of attack – Broadwater says it’s better to be safe than sorry.