A guest post from Paul Muller – Paul Muller leads global strategic marketing within the Software business at HP responsible for building awareness and implementation of best practices across all elements of the IT value chain as well as technology domains including Cloud, Security, Mobility and Big Data amongst IT and line-of- business executives alike, contributing best-practice in helping business and IT perform better.
“We are sorry to announce that our cloud service will be shutting down in 30 days. At that point, the service will no longer be available and all online and sync features will stop working. Click here to read more about this announcement.”
With a recent spate of takeovers and shutdowns, chances are you’ve seen more than one of these emails emails recently. I’ve had two in the last three months and nearly a dozen since I started using cloud services over 5 years ago. To be clear, my point is not that Cloud or SaaS is a “bad thing”, but more a reminder that like *all* of your suppliers, you need to be thinking about what to do when something you depend on is no longer available, and that doesn’t have to mean that they’ve gone bust.
Recently Vizify, a service that would gather up your social media activity and turn it into a great infographic and even a short video, was purchased by Yahoo (I assume for their people or IP) and shuttered. While annoying, the real impact was zero. The didn’t go bust, but some do.
Another had a greater impact. A collaboration service called Springpad which I had been using to work with co-authors on a research project, was shutdown on the 25th June 2014 (in their case due to lack a funding, clearly #selfies attract more VC money than helping people do real work!). Thankfully (or maybe not), we’d only just started using the tool and therefore there wasn’t a huge amount of work there and the Springpad team thoughtfully included a number of standard and defacto interfaces (JSON, Evernote) for getting our work out of the system.
Which begs the question, who (or what) next? You’d be forgiven for thinking the lesson here is not to trust your workflow to startups with economically unviable business models, but even profitable, publicly listed companies such as Google, Apple, Microsoft and even my own company have all voluntarily shuttered cloud and web services in the last five years – from the mundane (news aggregators/readers), to the commoditised (backup) to the concerning (marketplaces selling DRM protected media).
This becomes all the more worrying as I travel around the world hearing how gung-ho CIOs are racing to migrate apps and services into the cloud, incorrectly assuming that once in the cloud it’s safely “someone else’s problem” (a direct quote from a CIO at a regional summit just last week). While you can’t prevent any supplier or company from going belly-up or making your favourite (or mission critical) product end-of-life, the nuances of cloud/SaaS make the impact so much great unless you take steps to think through the service transition and design, specifically;
- Make sure you can get at your data – Sounds like a no-brainer, but the ability to pull the original data and potentially any of the valuable metadata you’ve created during the usage of the service is critical. There’s still going to be a huge disruption as you figure out how to port it, but it’s better than starting from nothing.
- Keep it open/contestable – The next most obvious thing to do is to ensure that service providers you chose are using open standards. JSON is great, but still requires someone to develop the right kind of adaptor and you have to deal with the resulting downtime. De-facto standards like WordPress have enabled hosting companies to offer “point and click” migration of websites and standardised virtual machine images and cloud operating environments like KVM and OpenStack can do the same up and down the stack.
- Prepare a transition plan as part of signing on for a new service – Portability/openness become less of an option as you move from IaaS and PaaS to SaaS (where the application itself is almost always proprietary). So while you may not always be able to easily extract or move all of your workflow, processes and data around, you must build in a transition process or plan as part of your due diligence BEFORE you commit to a new service (beyond the pilot), the challenge is to ensure that even the non-IT savvy parts of your enterprise understand this is not something to gloss over lightly.
- Regularly test your hybrid or transition/migration plans – Let’s be clear, your service provider going bust/shutting down is just as much a disaster as if your data centre burns down and like all good disaster recovery plans, you should regularly test the entire plan “live” (at minimum annually) to ensure you business will survive. Even temporary outages of cloud providers can be painful as the Amazon outage of three years ago taught their customers.
- Design for hybrid deployment – The least disruptive, and potentially hardest, option is to design application and services architectures that play nicely in both a cloud and on-premises model, sometimes called hybrid. This gives you the benefits of flexible consumption from your service provider, but enables you to move some or all of your workload on-premises in the event of an outage, commercial failure of your supplier or (and we’ve yet to see this), price gouging by deeply embedded service providers.
The good news is that commercialism abhors a vacuum and with this problem only likely to get worse with more cloud services popping up all the time.
I predict that entire companies offering apps or cloud services (irony) will be launched to fill the growing need for rapid “forced” migration and potentially brokers to facilitate customers switching from one supplier to another (which is really just a general case example of migration, just without the deadline).
The real lesson. Don’t let the lure of simplified consumption fool you into thinking that cloud is “consequence-free IT”. When it comes to our enterprises, the buck stops with each of us, to think otherwise is simply mortgaging today’s convenience against failure and leaving you exposed as a potential cloud refugee.
