Charles Makes a Point (or Two)

I've been getting push back on the idea that cloud computing has challenges becoming reality.  A lot of people seem to think it's already accomplished.  Private clouds, Amazon, Google, backup in the cloud, it's all happening. 

A thing hit me the other day while I was talking with someone about why Google Apps isn't a bigger hit in the Enterprise space (another topic for another day).  It occurs to me that one of the major reasons we aren't seeing more adoption (in addition to my other theories) is that there aren't many players.  Why aren't there many players?  The same reason a lot of 'good ideas' don't see the light of day: people haven't figured out how to really make money at it yet.

If you want to build these highly robust, highly available, highly flexible infrastructures that people can count on to run parts of their revenue-generating infrastructure (which if you want Enterprise customers you need to have), you don't go down to Best Buy and by some 1TB hard drives and some white box PCs.  You buy Enterprise infrastructure components.  That's not cheap (have you seen VMware license costs?).  This isn't a charity endeavor.  It's got to be profitable. 

Sure, you could try the Google approach with how they've built out their commodity-based infrastructure, but how many people does it then take to manage it?  People are obviously more expensive than technology, and at the scales this is supposed to work at, you need the technology or you need the people.  Either way your profit margins are slim.

This might be the biggest barrier yet.  What do you think?

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.