Cloud Computing: do you have a clue?

This week's BTL guest posting by an IBM IT architect, Cloud Computing: Is it right for you?, was an interesting insight into what the big systems vendors are telling their customers about cloud. But it was so full of misconceptions and misdirection it abjectly failed in its stated mission of sensibly guiding enterprise decision makers. Sadly, this is typical of the ill-informed conventional wisdom you'll hear from the likes of IBM, HP, Oracle and most parts of Microsoft, Accenture, Deloitte and the rest when discussing cloud computing. To help redress the balance, here's a quick rundown of some of the most egregious fallacies in the posting.

• "Cloud Computing refers to the delivery of infrastructure components and services." This initial definition gets everything off on the wrong foot from the outset. It's very convenient for vendors of costly computing platforms to imply that cloud computing is all about buying truckloads of new kit to equip your data centers to cloud standards. Of course, it's no easy task to build a cloud data center, so you'll need lots of consulting to go with that, won't you? Yet in reality, most enterprise spend on cloud computing is on cloud applications, because it means users can get started right away on a pay-as-you-go subscription rather than having to wait 18 months while the app is scoped, provisioned and implemented.
• "The components that are housed in the cloud on the diagram are client devices, servers and data centers." You see? No mention of applications at all, even though SaaS gets a passing mention in the following paragraph. Even worse, this statement is a misrepresentation of the original use of the cloud symbol in architecture diagrams, which represented external services (such as X.25 resources) running on third-party infrastructure. The whole point was that you didn't have to worry about the underlying infrastructure, because it was abstracted within the service.
• "1. Does the cost benefit justify the disruption? Data center migrations are disruptive, costly, and complicated." So in just a few, short paragraphs, we have neatly segued into perpetuating the myth that adopting cloud computing is all about migrating your existing enterprise IT to a brand new cloud data center that IBM will help you to build. Neat, huh? IT people are especially prone to fall for this line of argument, because who wouldn't want to be the architect of a brand new state-of-the-art IT facility that's just like Amazon's? (Apart from all the parts where it's not, of course, because enterprise IT has so many costly additional requirements that [insert name of global systems vendor here] understands and Amazon doesn't).
• "Some applications cannot be virtualized as they require specific underlying hardware components." Suddenly, virtualization is a synonym for cloud. Do people really still believe that in 2012? While it's true that you can't just move legacy client-server and mainframe applications into the cloud without modification, you shouldn't even be starting with the notion that's what you're trying to do in the first place.
• "Some applications require minimal delivery speeds. If latency is an issue, it is best to keep the entire system ... local." Local to whom or what? Is the writer suggesting corporations move their entire global workforce into a single office conveniently located next to the data center to ensure subsecond response times? Perhaps instead it might prove less disruptive to upgrade the network! (Or use some cloud provider's high-speed infrastructure). Of course traditional enterprise applications are tightly coupled between app servers and databases so you'd best keep them close to each other, but any app today that can't deliver to remote workers and mobile devices without significant latency needs an upgrade.
• "The organization has to be willing to risk placing their and their customer's data in the hands of a third party vendor." Big systems vendors and SIs like to flatter their customers, but the truth is most CIOs today realise that cloud providers tend to have more robust security than most enterprises. Since many on-premise assets are actually in co-location facilities and managed with the help of third-party IT contractors, third-party dependency in any case is not a unique characteristic of cloud computing.
• "The last thing you want is your data to co-mingle with someone else's." If you use a co-location facility, if you send emails, if you run VPNs across the Internet, do you worry about your data co-mingling with others when the packets pass through the network's routers? Of course you don't. You know that the headers on the packets make sure that your data won't accidentally go to someone else's endpoint. Cloud vendors use exactly the same logical separation to keep your data from 'co-mingling' with anyone else's. The fact that it may be stored on the same disk or go through the same processor chip is as irrelevant as worrying about sending your physical mail through the same postal system as your competitors.
• "When shouldn't I use cloud computing?" The conclusion sums up the entire posting as a collection of reasons why you might not want to use cloud computing — after initially defining it in a totally misleading way. Not a mention of why you should use cloud computing. No reference to any of the real-world problems of cloud adoption, such as integration between cloud and on-premise IT. As advice goes, this is hugely unbalanced as well as showing a barely rudimentary understanding of the true dynamics of cloud. Yet this is the type of reasoning trotted out daily by the representatives of the global computing establishment. No wonder people get confused.