Original URL: https://www.theregister.com/2013/09/19/why_move_storage_to_the_cloud/

Five reasons why you'll take your storage to the cloud

And five reasons why you won't...

By Trevor Pott and Iain Thomson

Posted in Storage, 19th September 2013 11:14 GMT

The cloud will inevitably replace all other forms of IT. The cloud is a passing fad. The cloud is good, it is bad and it is hideously ugly. The cloud is a paradigm shift that will obliterate all previous technological developments. The cloud is an iterative evolutionary augmentation of extant technologies and nothing to write home about.

The marketing for the cloud is terrible, was terrible and will be terrible in the future. Nobody can agree on what the cloud is, why we should care or even if it's of benefit to us. Despite this, nerds the world over have opine passionately about the ephemeral technology du jour and The Register does so like stoking the fires.

Thus we present five reasons you won't go into the cloud ... and five reasons you will.

1. This salt shaker is bugged for your protection

"The cloud" as it stands today basically means "American technology companies". There are a few outliers – primarily in IaaS – but the really sexy stuff is almost all American. This is a practical problem for cloud adoption advocates.

Wading through the legal morass of what kinds of data we can legally store where is expensive, frustrating and subject to change with the next law passed by our governments. The net result of this is that it doesn't make business sense to use American cloud providers for anything. Even if they have a datacenter in your country they can still be compelled by their government to pull any data you've stored (such as the personally identifiable information belonging to your customers) and never tell you.

For obvious reasons an American legal attack surface of any kind is simply unacceptable in today's cloud computing. What of the UK? I'm pretty sure that as a Canadian company I can't store data there either. Probably not France, given recent revelations on their side too. China's out, for obvious reasons ... that leaves "store my data in my own nation" or "store it in Switzerland". (There are a few EU nations I could probably get away with for now, but I'm sure that's only until their own intercept programs are made public.)

Ultimately the only solution is "the data must be stored only within the boundaries of your own nation and by companies without a legal attack surface in other nations." Legal attack surface, BTW, does not simply mean "headquarters are in your nation."

If the sysadmins live in another nation then the men with the dark suits can show up with a "do this and never speak of it" letter and you'll never know your data was pulled. If your customers have reason to believe that their data was read they can sue you because you made the choice to use that cloud provider and it was that choice which put their data at risk.

The only acceptable solution from a privacy standpoint is that the cloud provider must license their software to a company within your nation that then stands it up inside the datacenter of a hosting provider that is also located in your nation (and who has no legal attack surface anywhere else.) Of course, that's anathema to most cloud providers and impossible for many others. If they've built your application on a PaaS offering such as Amazon, then they're stuck ...and so are you.

On the other hand ...

300 million-plus wallets can't be wrong!

The counter argument to this is simple: the rest of the world doesn't actually matter all that much. The CEO of a cloud provider crystallised the argument around privacy during a PupperConf after-party this year.

"There are several dozen US companies spending or willing to spend a million or more per month on cloud services," he told me. "But I haven't seen one outside the US willing to do that." The big money is in America and most cloud providers will do just fine mining that market for some time to come.

The rest of the world takes consideration, care, investment and a heck of a lot of work to deal with. Most cloud providers have built their business not only around the software they sell but around the internal business processes they use. Some tout their DevOps prowess, others their support, stability or what-have-you. To replicate that outside the US requires partnerships, licensing and constant vigilance to ensure that licensees do not ruin the cloud provider's good name.

There's a lot of money to be made in America. More than enough for the next decade or so. What's more, non-American companies don't seem all that bothered by little things like their own data protection and privacy laws. It's easier for everyone to simply assume that politicians will smooth out any barriers to adoption.

Everyone's doing it. You can no more kill cloud computing that you can stop non-commercial copyright infringement, win the "war on drugs" or succeed at prohibition. Many businesses are seeing benefits from cloud computing whereas few have been sued over the privacy aspect. Statistically, it seems likely you can use it to your advantage and get away with it.

2. 404 as a Service

Google goes dark for two minutes and significant chunks of the western world wonder if they should go home, or wait for Google to fix itself. It sounds like the premise of a science fiction novel, but this actually happened a few weeks ago.

In addition to the cloud provider having a lie down there are layers of things that can go wrong between you and the provider, The ever-present idiot with a backhoe, ISP router misconfiguration or even the NSA botching a fibre tap and accidentally wiping out an undersea cable or two.

Natural disasters are another consideration. Here in Edmonton we pretty much don't have natural disasters; there's the odd tornado every few decades and flooding is a possibility if you live by the river, but statistically there are few better places to have a pile of servers run reliably for years at a time. If I go put my data in a datacenter in San Francisco then natural disasters as a service interruption modality become something I have to start thinking about.

As a consumer of cloudy services you have no control over versioning, UI (Google stop moving my buttons!), or the development process. In the wrong hands "rapid release" can mean "automated iterative failure as a service."

One of the fundamental problems of cloud computing is that when the thing blows up you don't have a neck to wring. There's a lot of finger pointing (it's your network/computer/browser, no it's your cloudy server, no it's $ISP), but you've no real option during outages except "hurry up and wait."

Having said that ...

Sucking less, at scale

Despite this, the cloud provider is most likely better at IT than you are. For the big players, there's more of them than there are of you and they have entire teams of people just to do monitoring.

Cloud providers leverage economies of scale. That doesn't just apply to getting cheap hardware or having a little bit of muscle when they sit down with Microsoft across that long negotiating table. It means things like testing, automation, quality assurance and the raw manpower that can be brought to bear.

They're better at it than you. Even with the potential for outages, you will probably still get better uptime with a cloud provider than rolling your own IT.

3. The forever cost

Storage doesn't die; you have to keep paying, forever. 50GB of data on Amazon S3 for a month looks nice and cheap. 50 GB in month 1, 60GB in month 2, 75GB in month 3…that starts to add up and the amount you need to store very rarely goes down.

In addition to the raw cost of storage or computing power you need to pay for bandwidth. Backups are still something you have to do and that is a cost you'll have to cope with, bringing additional bandwidth costs as well as sourcing a second cloud provider to store it on. (What use is backing up to the same cloud provider?)

Cloud computing brings compliance and regulatory burdens. The costs here can get quite high, especially if you use cloud providers outside your own nation. Factor in the opportunity cost of locking yourself into a given cloud provider and that you can't leverage existing investments in hardware, software and so forth.

You might think you're getting rid of the IT department by going cloudy, but you aren't. You're adding layers of things you need to monitor, audit and meet arbitrary bureaucratic standards on whilst replacing periodic one-shot expenditures with a monthly tithe.

Mind you ...

Nothing to something and back again

The cloud is great for bursty workloads, temporary workloads, or dev environments. It's great for getting something working fast or for a fixed timeframe. Want to run for president? Well, you could invest in a sea can full of servers to do the work you need, or you can spin it all up on a public cloud for a couple of years and then tear it down after the election's over.

Pay as you go means no upfront investment. If your business succeeds then it will pay the bill at the end of the month. If it fails, it fails. You don't have to dig in your jeans to buy a great big pile of infrastructure just to play the game. All you need is the first month's "rent".

4. If it ain't broke, don't fix it

The emergence of a new technology does not mean the eradication of so-called legacy technologies. You may already have a great non-cloud solution to a business need. Switching to the cloud means retraining your staff, changing significant internal business processes and will likely cause many unforeseen disruptions.

New technologies should augment rather than supplant old technologies. We use what works – and what we're comfortable with – until there is a demonstrable reason to replace it. In many cases we never replace the old technology entirely, keeping the older stuff around in case of emergency.

If centralized, utility-style X were always better than roll-your-own, why do hospitals and datacenters have backup generators? Shouldn't the national grid be "better"? If what you have works then there just isn't a need to jump to the cloud. Even if you do make the leap, you'll probably want a backup local IT plant for some time to come.

Sure about that?

Change as a service

As much as existing technologies and business practices are a nice security blanket, not everyone wants to keep things as they are. Sometimes a swift kick in the butt is what's required and this is something that cloud services seem regularly able to deliver.

Everybody loves the idea of doing without the IT department – or at least giving them a good scare to keep them in their place – and cloud computing can be used to that effect. It can also be used to provide "simplicity as a service": when an incumbent software provider has become hopelessly complex and difficult to use you can bet a cloud provider will pop up to replace them with something far easier to work with.

5. Data ownership

Do you have access to your data in the cloud? Not the data as presented you through the interface of the software, but the raw data needed to pick up and move to another vendor. There are business continuity questions to be asked here.

If you license a product, you can run it in your data center for a decade, or transfer data out of it at any time. You own it. ''How do you get your data out of the cloud? Can you transfer it to a different cloudy service if you need to? What if your provider goes out of business or gets sued into oblivion? If your cloudy provider simply isn't there tomorrow, how to you access and use that data? Backups don't matter if you have nothing to restore them to!

What about more temporary outages? If the cloud service goes down, will there still be useful work for staff to during the day? How long can you go without your cloud service provider? How long would it take you to restore/convert your data from your existing cloud provider into something usable enough to keep the business running? Would your business even survive an outage of that length?

Mountain out of a molehill?

Cloudy similarity

Many kinds of data are straightforward and generic. Email, file storage, and some kinds of big data you've designed the analysis or reports for. If an IIS website/SQL server dies on Microsoft's Azure cloud, it's not a big deal to arrange a replacement.

Some cloud providers have easy transfer mechanisms to other apps, e.g. Quickbooks online to the Quickbooks desktop client. For others there are cloud brokers who can take the task of data migration off your hands ("oh shit" as a service.)

Similarity at this level makes the cloud a natural extension of your datacenter. IaaS offerings are not something you generally have to worry overmuch about. Do your backups right and you can light up replacements anywhere. PaaS is something you can probably build a backup cluster for and SaaS providers are slowly starting to come around to the realisation that people don't appreciate lock-in.

Like it or not, the cloud is here to stay. There are reasons to use it and reasons not to. There are reasons to use only some aspects of it and reasons to go whole hog. As always, please leave your ideas in the comments below. ®