Just in Case. Bring Alternate Plans to the Cloud Party

As I write this, Lori and The Toddler are on their way to the store, his first trip out of the house without a diaper (nappy for our UK friends), she bravely told him that they would go get some robots as reward for being a big boy. I told her that it was brave – possibly brazen – to take him out straight away, to which she replied “I’m putting clothes in the diaper bag and taking it along just in case”. I’m sure all will be well, he has inherited his mother’s stubbornness, and is pretty focused on any activity that ends with a robot “IN MY HAND” (shout that in toddler voice, and you’ll get the idea). But Lori has planned ahead just in case because this is all new to him.

And that’s precisely the deal with cloud. It’s new. In fact, if you look at something cloud and go “this is the same stuff that we were doing 5/10/20 years ago”, then chances are a vendor is hoodwinking you with what I’m told is called “cloud-washing”, or you’re doing it wrong. Since it is new to you – Infrastructure as a Service is the best definition I’ve seen to date – you should go into it with contingency plans. What happens if it doesn’t scale as expected? What happens if it does scale and the costs get exorbitant? For public cloud, how do you get your stuff out of the cloud if need be? Once you go cloud – be it private or public – your infrastructure consumption is likely to be larger than your physical infrastructure, so what’s the backup plan?

In short, expect the same type of growth that you saw with virtualization. It will be easier to provision, and thus more projects are likely to be tried. The choke point will be development, which will help keep the numbers down a bit, but don’t count on it to keep your cloud provisioned applications in line with your physical ability to host them, particularly if public cloud is part of your plan (and it should be). So you’ll need to have a backup plan should your vendor do any of the many things that vendors do that make them less appealing. Like get purchased, or have a major security breach or any of a thousand other things.

There are not yet viable cloud interoperability standards, largely because there is not yet (in my estimation) market convergence on the definition of “cloud”. Until there is, you’ll have to fend for yourself. That means knowing how to get your apps/infrastructure/data back out of cloud A and into cloud B (or a non-cloud datacenter).

Another odd thing that you will want to consider is data protection laws and storage locations in the cloud. Lori has talked about this quite a bit for apps, but it’s even more important from a storage perspective. Know where your cloud provider is physically storing your data, and what the implications for that are for you. If you are in a country with one set of infosec laws, and your cloud provider stores your data in a different country, what exactly does that mean to you? At this time it probably means that you will have to implement the most stringent of the two country’s laws. Of course, if the storage provider doesn’t tell you what country your data is in (Amazon for example spawns copies of data, who knows where), then you have a more fuzzy problem. Are you responsible for maintaining the standards of a country you didn’t know your data was stored in? I’d say no, but I could argue that it’s your data, you are responsible for seeing it is protected and knowing where it’s at. If you’ve got data centers in multiple countries, you already understand the implications here, but it’s worth revisiting with cloud in mind, particularly if your cloud provider has datacenters in a variety of locales.

Finally, if your applications are running in more than one geographic location, you’ll need something like our GTM product to make sure you are directing connections to the right servers. If you have multiple datacenters you may or may not have already put some type of architecture in place, but with cloud – particularly with cloud-bursting – it becomes a necessity to front your URLs with something that resolves them intelligently, since the application is running in multiple places at once.

Cloud provides a great mechanism for doing more and being more adaptable as an IT department, but look before you leap. As the old adage goes, “Those who fail to plan plan to fail”. Cloud is big enough that you don’t want to jump off that cliff without knowing your parachute is packed.

And hopefully you will have fewer incidents than The Toddler is likely to have over the next few days. Though first time implementations of new technology tend to have their share of incidents in my experience.