'Moving to' versus 'building for' cloud computing
Ray Ozzie's memo about a "new day dawning" is a powerful vision of what cloud may do for some businesses, but achieving that vision means re-envisioning your own business and IT models.
Microsoft Chief Software Architect Ray Ozzie has written a memo that has generated tremendous buzz among the cloud-computing community. Microsoft CEO Steve Ballmer announced Ozzie's impending retirement from the company last week, and Ozzie took that opportunity to write "Dawn of a New Day," which outlines a future for computing that is both a challenge and opportunity for the software maker.
Don Reisinger has excellent analysis of that post, so I won't break it down in detail for you here. However, Ozzie's post is interesting to me because it highlights a key nuance of cloud adoption that I think IT organizations need to think about carefully: the difference between "moving to" and "building for" the cloud.
I, and others, have noted several times before that one of the key challenges for enterprises adopting cloud is the fact that they are not "greenfield" cloud opportunities. They have legacy applications--lots of them--and those applications must remain commercially viable, available, and properly integrated with the overall IT ecosystem for the enterprise to operate and thrive.
As Ozzie notes, however, the future introduces a "post-PC" era, in which software becomes "continuously available" and devices evolve into "appliance-like connected devices." That new future sounds simple enough, but there are huge challenges in making that a seamless, scalable computing model.
You can't just "port" existing applications into a new model like that. Software just doesn't work that way. While data formats and application metaphors may remain relatively consistent, key fundamentals such as user interface components (e.g. touch screens), data management (e.g. nonrelational data stores and new multidevice synchronization schemes), and even programming styles (e.g. "fail-ready" software) mean existing code is unlikely to be ready-made for a true cloud-computing model.
That's not to say that existing apps shouldn't be moved to cloud environments where it makes sense to do so. Development and testing, for example, are two legacy computing environments that benefit greatly from the dynamic, pay-as-you-go model of cloud. I am hearing reports that even relatively complicated legacy applications, such as SAP implementations, can benefit from cloud adoption if there is a dynamic usage model that meets the criteria laid out in Joe Weinman's "cloudonomics" work.
However, today IT organizations have to begin consciously thinking about where they are taking their business with respect to cloud. Not just technology, but the entire business. Are you going to look at the cloud as a data center alternative for your existing computing model, or are you going to architect your business to take advantage of the cloud?
A great example of the latter is online movie-streaming leader Netflix. In recent talks, Adrian Cockcroft, Netflix's cloud architect, outlined the company's decisive move away from private data centers to public cloud computing and content delivery networks. Making heavy use of the entire Amazon Web Services portfolio, Netflix has designed not only its IT systems for the cloud, but its online business model has evolved to make the company more "cloud ready."
The point is that you can't simply move your existing IT to an "infrastructure as a service" and declare yourself ready for a cloud-based future. Yes, you should move legacy systems to public or private cloud systems when it makes economic sense to do so, but you need to begin to evaluate all of your business systems--and, likely, business models--to determine if they will win or even survive in a continuous service, always-connected world.
There is a huge difference between "moving to" the cloud and "building for" the cloud. Are you prepared to invest enough in both?