Cloud Computing Isn't All Azure Skies
The Tubes are atwitter with discussion of the news from PDC this week, not least of which was the announcement of Microsoft's new Windows Azure cloud computing platform. Details about the offering remain scant at this point -- the SDKs and developer programs are "by invitation only" -- but what I've heard so far sounds promising. I'm particularly interested in Live Services, which finally lifts the lid off the inner workings of Live Mesh (of which I am a devoted user).
But while I'm fairly rah-rah about the potential of cloud computing platforms in theory, I remain skeptical about their efficacy for enterprise software development in practice. By comparison, Microsoft is nothing if not gung-ho. Where Amazon and Google have tread carefully, unveiling their cloud services first as pilot programs with limited applications, Microsoft seems determined to deliver its version of the cloud to its entire ISV community on a plate. While the geek in me is itching to play around with this stuff, my instinct says "caution."
Let's dispense with the "Microsoft is evil" argument for the moment: Who wants to get in bed with Microsoft for something like this? Windows developers, that's who. You Microsoft ISV partners out there all recognize that a certain amount of vendor lock-in goes with the territory. It might be nice not to have to keep that revenue stream going from your accounts into Microsoft's, but for you the benefits outweigh the costs -- and the risks.
And if you think about it, who makes for a better cloud-computing partner than Microsoft? They're already expanding their datacenters, up there in Redmond, to support the new hosted platforms. That's exactly the kind of thing you want from a cloud vendor. Microsoft reaches into its deep pockets so you don't have to have deep pockets of your own. So what if your applications will be tied to Microsoft's services and APIs? For Windows developers that's true already.
I believe, however, that the kind of lock-in you get with a cloud-computing service is different than the lock-in you get with the Windows developer ecosystem as it exists today.
For the sake of argument, let's suppose that you have developed a traditional Windows application for your business. One day, Microsoft releases a new version of a key framework, and the updated API breaks some of your code. You now have several options. One is to rewrite your code, introducing a certain amount of cost and risk. Another option is to do nothing, and continue to run your software with the older version of the framework. That will doubtless work for a while, but eventually the older framework might not work with a new version of Windows, or even a new Service Pack.
These sorts of compatibility issues are a fact of life with all forms of software. The important thing is that they are always manageable. Even if you have to find an aging MS-DOS computer to run your legacy code, that is still an option -- for a while, at least.
But where are you going to find an old version of the Microsoft's cloud computing platform to run your legacy Windows Azure code? With the cloud computing model, when you buy a ticket, you're in for the ride. When Microsoft says it's time to update your code to suit the latest version of its platform, you'd better do it.
Think that kind of thing won't happen? I believe it's more than likely, particularly as the market for cloud-computing services heats up. Let's suppose that tomorrow some clever graduate student comes up with a way to scale cloud services more cheaply and effectively than any other method before. Do you think Microsoft will ignore this method if it thinks it needs it to stay competitive? Even if all of its customers will have to adjust their code to work with the new method, do you think Microsoft will be deterred?
Cloud computing environments create a whole new kind of developer partner. In traditional ISV relationships, the customer pays the fees for the necessary tools and then the sky is the limit. With cloud computing, the customer's capabilities are directly influenced by the vendor's bottom line. If the vendor decides it can no longer afford to provide certain services -- or service levels, or security, or guarantees of privacy -- then henceforth that will be the new deal. My nightmare scenario is that we'll end up with application hosting services offered up on the same terms as credit cards. Every few months, a slim brochure will arrive in the mail explaining the new terms and what we'll need to do to remain in the program.
Even if it never comes to that, the fact that the vendor has its hand on the on/off switch is what makes the cloud computing model seem so troubling. The day that the vendor -- be it Microsoft or anyone else -- decides that your applications are no longer going to run on its platform is the day that they stop running, period. If you raised an eyebrow at the revelation that Google has reserved the option to terminate applications running on Android phones remotely, this fact of life of cloud computing should give you even more pause.
OK, so I can't keep you from harping on Microsoft forever. I'm sure some of you are already itching to say, "It's Microsoft, what do you expect?" But my question is this: Given these realities, just what cloud computing vendor would you trust to host your apps?