Tags: cloud computing
Barriers to 'cloud computing' -- money for nothin' and chicks for free
February 16th, 2010I'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?

Barriers to 'cloud' based computing -- Security
August 6th, 2009You 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.
Score one for the marketers: why definitions of 'cloud' based computing frustrate me
July 14th, 2009Marketing is a great thing, but sometimes it just goes too far. All of this "cloud" talk is a prime example.
The discussion around cloud reminds me of the proverbial spring/summer activity of laying in the yard as kids and watching the clouds go by, calling out what it is you think this or that cloud is.
"Oooh, look at that one, it's a dragon!"
"What? that's not a dragon, that's a turtle!"
"Uh, huh, but now it's a sheep!"
The cloud is what you want it to be, because it is a giant nebulous concoction of water vapor and ice crystals, constantly changing shape and direction as dictated by the wind. It isn't any one thing.
That's great for childhood games, but as an architect and a consultant, I've just about had enough of all this. IT is a concrete thing. Technology is black and white (or 1 and 0 if you prefer). Nebulousness (is that a word?) does not fit in this environment. You don't get to say to the CEO, "well, it was sort of online, depending on what your definition of 'online' is" (or depending upon your definition of 'is' for you politicos out there). It's on or it's off and the business doesn't care why it was off if they needed it on.
Every IT vendor out there has some definition of 'cloud'. Literally, every single one. Look at the web sites. Everyone can tell you how they fit into the 'cloud', but not a single one of them can tell you what the 'cloud' really is. Of course, VMware and Cisco think they have a good definition, as long as it means running everything on the Cisco unified compute platform with VMware. That's the cloud? Hmmm, I thought 6 months ago that was called consolidation. Amazon thinks they have a definition, as long as it means shipping your data out to their server and storage farm to run compute cycles in their data center. You know, I thought that was just good old-fashioned outsourcing. SAP's got a definition, EMC has one, HP, IBM, everybody out there has one, and they are all centric to the products they've been trying to sell everyone for years. Yes, there are some unique aspects to some of the products (EMC Atmos comes to mind), but for the most part, it's all the same with re-packaging. vSphere and vCloud are ESX server with some really neat new features (and some completely undelivered as of yet promises), but it's still ESX Server. The Cisco unified compute platform is servers. Granted, an interesting architecture and management footprint, but let's be real here, they're servers.
What the 'cloud' really is in the IT context is the same thing it is in real life—vapor. It's the second coming of the xSP model that will save all businesses from the pain of having an IT department. I said to someone delivering a cloud pitch the other day "did you activate a time warp just before you came in here and take me back to 1999/2000? These are the same concepts that were pitched at me about ASPs, data center outsourcing, and eCommerce 10 years ago!" At least it sure feels like it to me.
Over the next few posts, I'm going to keep delivering my take on this topic, if nothing else to flush out some things and vent a little. I think that there is too much hype here, and we're headed to another bubble bursting if we aren't careful. The foundation of a technological breakthrough requires more than just a whizz-bang technology. It requires sound planning, terrific execution, and a goal. I don't think that anyone talking about cloud is providing those. There's a lot of theory, a lot of talking, but not a lot of reality. I'm all for open discussion, but could we maybe back off the child-like excitement that IT is going to be saved and suddenly align with the business based on the 'cloud'?

