Maybe it's time to rethink the cloud. Yeah, I know -- at this point, most IT shops haven't thought through the cloud the first time. But Microsoft's recent troubles keeping its cloud services available to users shine a harsh light on the issue of cloud availability and reliability.
Trouble is, those are the wrong things to be thinking about.
Sure, it sounds bad when a vendor as big as Microsoft can't keep its cloud network running. It's not comforting to know that Google , Amazon , Rackspace and other cloud providers have had outages too. So has software-as-a-service king Salesforce.com .
Look, the cloud involves too many miles of somebody else's wire between users and their applications for networking hiccups to be eliminated completely. But cloud availability will get better. It's a problem that cloud vendors know about -- and know they have to solve.
Let's think about a much bigger problem: The cloud is a good place to move a stand-alone virtualized server (or it will be, once vendors get their availability act together). But how much of your current data center falls into that category?
Don't answer yet. First, think about all your virtual-server applications that don't really stand alone. They talk to shared data stores or other applications. Their performance literally depends on how far data has to travel. Inside your data center, that's trivial. But up in the cloud, millions of round trips could be necessary between an application in the cloud and data in your IT shop. Even at light speed, that takes time.
Maybe you're thinking you could send the whole group of applications that use the same data stores up to the cloud. No more round trips, right? But one key principle of cloud computing is that you never know exactly where an app will run. With some providers, apps and data could end up communicating between New York, Silicon Valley, Seattle and Mumbai -- and total network latency could go from a problem to a catastrophe.
You can solve those problems. But that might mean redesigning how those applications work, how they communicate and how they interact.
Now think about this: That's the pretty part of your data center. Then there's the ugly stuff, the part we don't like to think about. Apps that, say, scrape some mainframe screens, combine their contents with data from specialized industry-vertical software, then run the result through legacy business logic that no one has touched in years for fear of breaking a critical piece of some department's business process.
Our data centers are littered with that kind of cruft, accumulated over decades as we've moved from one IT paradigm to the next. There's never time or money to fix it because, kludgy as it is, it still does what users need, and untangling it will be all IT cost with no business-side benefit. But without that untangling, it will never work in the cloud.
So here's something worth thinking about: How much of what's in your data center is ready for the cloud? How much of it will have to be reconfigured, rebuilt or re-architected before you'll be able to move it up to the cloud? How much will never be cloudworthy?
And do you really think you'll have thought that all through before Microsoft learns how to run a network?
Frank Hayes has been covering the intersection of business and IT for three decades. Contact him at cw@frankhayes.com .
Read more about cloud computing in Computerworld's Cloud Computing Topic Center.