Making Sense of Microsoft's Azure
Last week, Microsoft announced its cloud-computing effort, called Azure. Fitting between Google's and Amazon.com's current offerings, it represents a very big step toward moving applications off the desktop and out of a corporation's own datacenters. Whether or not it will have any traction with corporate IT developers remains to be seen.
Nonetheless, the Azure effort has brought more of a Wild West feel to the whole arena of cloud computing. If this were the late 1880s, Amazon.com would provide the land grants, as well as raw Linux and Windows acreage to build your applications upon. Google's general goods store would stock and give away all the APIs that a programmer could ever use, and some of the scrappy prospectors that came to build the new towns would be from Microsoft. Steve Ballmer as Billy the Kid, anyone?
[See how Amazon, Google, and other cloud offerings fare in the InfoWorld Test Center comparison " Cloud versus cloud." | See why InfoWorld's Neil McAllister is concerned that Azure may not work well for many developers. ]
Enough of the metaphors. Mary Jo Foley's excellent explanation of the different bits and pieces of Azure is worth reading. But the first instance of Azure is long on vision and short on the actual implementation: Microsoft calls it a "community technology preview," what the rest of us would consider an alpha version, given how long it takes Microsoft to actually get things nailed down and working properly (Version 3 is usually where most of us start to think of its code as solid). Granted, Google calls many of its applications beta, but they are typically in much better shape -- I mean, Gmail has been in beta for about 17 years now.
What you'll need to settle on the Azure frontier
So why should you consider entering Microsoft's cloud frontier? First, consider what your .Net skill set is and whether your programmers will use JScript or something else for the majority of their coding work. The good news is that Azure will work with .Net apps right from the start. (Support for SOAP, REST, and AJAX will be coming, Microsoft promises.)
Microsoft has talked about testing and debugging these apps on your local desktop, just as you do now, then deploying them in its Azure cloud. The bad news is that you probably have to rewrite a good portion of these apps so that the user interface and data-extraction logic can work across low-bandwidth Internet connections.
Microsoft CTO Ray Ozzie, in a Cnet interview, says, "Fundamentally, the application pattern does have to change. Most applications will not run that way out of the box [on Azure]." While good programming practice today is to separate Web-page content from formatting instructions, most programmers assume they are running everything on the same box. Remember how miserable LAN apps were back in the days of Token Ring? We have 10Gbps Ethernet now, and people have gotten sloppy.
This is no small issue, and my prediction is that most apps will need some major surgery before they can be cloudworthy. One wag already has placed his bets:Stephen Arnold writes in his blog, Beyond Search, "I remain baffled about SharePoint search running from Azure. In my experience, performance is a challenge when SharePoint runs locally, has resources, and has been tuned to the content. A generic SharePoint running from the cloud seems like an invitation to speeds similar to my Hayes 9600 baud dial-up modem." For those of you who are too young to remember, that means very slow.
While you are boning up on .Net, you might also want to get more familiar with Windows Server and SQL Server 2008, because many of the same technologies will be used for Azure. One thing that won't be in Azure is Hyper-V; apparently, we have another hypervisor to run the Azure VMs. Too bad -- I was just getting comfortable with Hyper-V myself. Nobody said this was gonna be easy.
The datacenter land grab: Enough for a secure frontier?
Speaking of servers, Microsoft is in the midst of a major land grab of its own, building out datacenters in multiple cities and beefing up the ones it already has. More good news is that Microsoft plans on using Azure to run its own hosted applications and is in the middle of moving them over to the platform (so far, only Live Mesh is there today). Right now, all Azure apps will run in its Quincy, Wash., datacenter, 150 miles east of Redmond, but you can bet this will change as more people use the service. At least Microsoft tells you this; Amazon treats as a state secret how many and where its S3 and EC2 datacenters are.
Of course, the big attraction for cloud computing is scalability, and Ozzie, in the same Cnet interview, has this to say about it: "Every company right now runs their own Web site, and they're always afraid of what might happen if it becomes too popular. This gives kind of an overdraft protection for the people who run their Web sites." I like that. But given the number of outages experienced by Amazon and Google over the past year, what happens when we have bank failures in Dodge?
Second, where do you want to homestead your apps? Just because you want to make use of the Microsoft services doesn't mean your apps have to reside on its servers. If you are happy with all the Google Goods, stay with that. If you like someone else's scripting language or toolset, do likewise. (By the way, our sister publication CIO.com has published a thoughtful, helpful examination of the JScript universe.)
What Microsoft is trying to do is manage the entire cloud lifecycle development, similar to how it already manages local app development with Visual Studio and .Net tools. Yes, Amazon.com will let you build whatever virtual machine you wish in your little piece of cloud real estate, but Microsoft will try to work out the provisioning and set up the various services ahead of time.
Oh,and how does the cloud frontier play with the enterprise?
The real trouble with all of this cloud computing is how any cloud-based app is going to play with your existing enterprise data structures that aren't in nice SQL databases; they may even be scattered around the landscape in a bunch of spreadsheets or text files. SnapLogic (and Microsoft's own Popfly) has tools to mix and mash up the data, but figuring out the provenance of your data is also not taught in traditional computer science classes and is largely unheard of around most IT shops, too. Do you need a DBA for your cloud assets? It is 10 p.m.: Do you know what your widgets are doing with your data?
Next, pricing isn't set, although for the time being, Azure is free for all. If you look at what Amazon.com charges for the kind of real estate that Microsoft is offering (2,000 VM machine hours, 50GB of storage, and 600Gbps per month of bandwidth), that works out to about $400 a month. Think about that for a moment: $400 a month can buy you a pretty high-end dedicated Linux or Windows server from any number of hosting providers, then you don't have to worry about bandwidth and other charges. And there are many others that can sell you a VM in their datacenter for a lot less.
However, Amazon.com's S3 storage repository is amazingly cheap, and it's getting cheaper as of this week; in fact, Amazon.com is now charging less per gigabyte the more you store with it. Microsoft should set tiered, fixed monthly pricing and make the storage component free. I am thinking a basic account should be free, and $100 a month would be just about right for the next level. The pricing of Microsoft's Office Live Small Business hosting services is an indication of what to expect.
Finally, take a moment to do a browser inventory as best you can. Writing cloud-based apps is going to be hard enough without having to account for variations in how your browsers support Java and other APIs, too. You'll find that you are supporting way too many different versions from different vendors, and getting people to switch just because the IT sheriff says so is probably impossible.
If you are going to enter the brave new world of cloud computing, this is yet another indication of the beginnings of where the Wild West will begin for you.