Charles Makes a Point (or Two)

You want my data to go where?  How?

I wrote last time about my concern with bandwidth costs as a barrier to adoption of this 'cloud' based computing concept so many vendors are pushing these days, where our data centers no longer have boundaries, and we can dynamically move workloads across the wire to data centers that have spare compute capacity available in them to deal with peak loads.  No longer will we design for peak inside the four walls of our datacenter, and therefore we can deploy far less hardware than the previous generations of datacenter designers, and we can become capacity managers, not system administrators.  To clarify the point, I'm not talking about what Amazon does with S3.  I'm not aware of them pitching (today) S3 as a dynamic workload depot capable of addressing spiking workload needs (I've heard some folks talk about EC2 this way, but I've never seen any Amazon marketing material pushing this idea).  They're a pool of resources available for use in a planned fashion.  You move some data, you move some apps, you run what you need to run, you pull it all off (or keep it there if you need use of it long term).  Takes some bandwidth to make the initial move, but after that, remoting into the environment works well.  The same is true of security. 

Securing an environment of that nature where there is not a great deal of dynamic data mobility in and out of the shared infrastructure is a very important task, but not one that is any more difficult than securing any other outsourced data center.  I don't see security of these 'public clouds' the same way, and here's why.

Security is about control.  It is about limiting risk and exposure to unseen, unfriendly forces that seek to do some form of harm to your information, whether that is steal it, modify it, sell it, whatever.  In virtually every discussion I've had and everything I've read, the ubiquity of the Internet is one of the keystones to making this 'private cloud/public cloud' dynamic resource allocation trick work.  If your first choice provider doesn't have enough capacity available for you, move to your second choice, third, etc., until you find one (or a combination of several perhaps) that has the capacity you need.  If you only had one provider, and you had a great SLA with them to guarantee you a fixed amount of compute, storage, and network resource regardless of what else is going on in their environment, then securing this becomes relatively simple, much like securing a transport into a co-location facility is today (of course, you still have the bandwidth conundrum, but enough about that).  But that isn't the pitch.  The pitch is the 'cloud'  will allow for ubiquitous connectivity to any available 'public cloud' provider, and the Internet is the key to connecting to these providers (by the way when you read this, you must say 'the cloud' like the little martian toys in Disney Pixar's Toy Story say 'the claw', with great reverence and expectation that it will save you from all your datacenter woes).

I don't know about any of you, but when I think about data transport across the Internet, the very last thing I think is 'secure'.  Yes, there are things like SFTP and VPN tunnels, but neither of those scream 'ubiquity of network connection and transport'.  They instead scream 'something to tear up and tear down'.  Of course, you can't SFTP your data across the Internet for purposes of bringing up a virtual machine or series of machines.  How many VPN tunnels do you want to have constantly available for the purposes of transferring workloads around?  It's doable, but not necessarily very easy.  We can encrypt the data, and there are certainly things RSA has been talking about that would make this easier for us to do, but again this must be easy and not cost an arm and a leg to implement if it is going to be an attainable architecture to the mid-market, the place I argue needs this theory to become reality more than any other.

I actually like the idea of encryption done at a virtual host level, so that regardless of what transport mechanism is used and where it goes, the data is unreadable to anyone that might intercept it.  The problem becomes one of key management, as is always the case when talking about data encryption on a large scale.  There is a certain amount of overhead associated with this as well.  We're putting in these multi-core überfast CPUs to run our apps, not deal with encrypting/decrypting the data.  I agree with that, but with vSphere, we're talking about CPU and RAM levels per guest that are crazy, and will only continue to climb.  I don't think we're going to starve for cycles even in fully virtualized environments to encrypt at the rate the CPU space is going.  The other interesting possibility here is something like PowerPath.  I haven't seen if PowerPath/VE will support the encryption capabilities that standard PowerPath is capable of providing, but I've got to think it will at some point (perhaps it does today, I haven't been able to double check this).  Encryption appliances could make a strong push here, but I think that introduces another set of complexity and management challenges. 

Once again the problem is a lot of sizzle without a lot of steak.  We need someone in the vendor world to take the lead here, proclaim that yes, there is an issue that needs resolving, and provide us a way of doing that.  I know they've thought about it, there are way too many smart people inside of Cisco, EMC, VMware, HP, Microsoft, etc., to not have at least some thoughts.  I just don't see them being pitched.  I see way too much of the vapor and not enough substance.  This is something I will be exploring further with a number of folks as I get opportunity, and will share with you what I find as I can.

In my next post, I'm going to endeavor to address the largest issue which will encumber 'cloud' based computing, which is institutionalized thinking.

Thanks for reading.