Before I come to my analysis of Microsoft's Windows Azure platform and the hidden danger lurking there for many ISVs looking to embark on a SaaS strategy, I'm going to segment cloud computing into several important but separate categories.
One of the reasons it's so difficult to satisfactorily define cloud computing is that people have many different needs and expectations from a cloud platform. To start a conversation about cloud — especially one that seeks to evaluate the relative merits of competing cloud platforms — without first identifying what needs are being met is to invite misunderstanding and confusion. So before I come to my analysis of Microsoft's Windows Azure platform and the hidden danger lurking there for many ISVs looking to embark on a SaaS strategy, I'm going to segment cloud computing into several important but separate categories.
First and foremost, we need to be clear whether we're talking about cloud as a service or cloud as an infrastructure asset. I often find myself halfway through a conversation about cloud computing, in which I've made the natural assumption that we're talking about delivery of cloud computing as-a-service by a third-party operator, when it suddenly dawns on me that the other person has been talking about buying software and hardware in order to implement their own cloud infrastructure.
There's a huge cognitive gulf between these two perspectives. In my view, most enterprises that invest in their own cloud computing projects are on a Fool's Cloud mission. Unless you intend to set up as a cloud provider in your own right, it's unlikely in the long term to be a good use of your funds. But I have to recognize that my point of view currently represents a tiny minority compared to mainstream opinion. Most enterprises are convinced the best way to take advantage of cloud computing is to implement it themselves. Many will find they achieve significant short-term savings from doing so, simply because moving to a virtualized data center architecture with automated provisioning is a much more cost-effective means of rapidly provisioning new servers than what they used to do. The newly launched Rapid Access Computing Environment (RACE) at the US Department of Defense is a good, topical example. But it's not a variety of cloud computing I want to discuss here — in fact, in many ways, I don't define it as cloud computing at all because it's behind the enterprise firewall rather than immersed in the public cloud.
So far, Microsoft has resisted siren calls to package up Windows Azure as a software bundle that enterprises can deploy in-house. Thus it fits firmly into the third party, as-a-service cloud platform category. Within this category, I see four distinct sets of use cases, all of which Azure explicitly caters for. In that respect, I think Azure represents a new, second-generation cloud platform that is more attuned than first-generation providers like Amazon to the present-day needs of the enterprise market. Those early providers came to market offering cloud computing as a standalone service, making no provision for enterprises to link cloud-based servers and applications with their in-house operations. That would be fine (up to a point) for those few enterprises that are prepared to embrace the cloud as a wholesale alternative to on-premises computing. But the pragmatic reality is that most enterprises today are destined for the foreseeable future to pursue a hybrid strategy, in which they're obliged to maintain computing infrastructure on-premise as well as extending into the cloud. Cloud providers that serve this market have to acknowledge and address that reality, by catering for several different use cases:
Short-term, overflow or burst capacity to supplement on-premise assets. This is the primary use case for as-a-service cloud platforms today in the enterprise market. This takes advantage of the pay-as-you-go elasticity of cloud computing, and it's been found to be extremely cost-effective for test and development servers as well as in cases where an enterprise application or project needs to bring in extra burst capacity at times of peak load. It's so prevalent that people commonly see rapid provisioning an elastic demand as the primary characteristic of cloud computing, which can easily be replicated on an in-house platform. That's because this use case doesn't often take advantage of the cloud-facing properties of cloud computing.
Cloud-based services and applications that extend on-premise assets with new capabilities. Windows Azure has got some interesting examples of this type of use case. There are the new Sites and Commerce extensions to Microsoft's Dynamics on-premise ERP software, for example, which supplement the back-office suite with the kind of automated front-office operations that are best done in the cloud. I'm even more interested by the new service codenamed Dallas, which uses Azure as an aggregation point for premium information services. This is a great example of where the cloud can deliver real-time information far more simply and cost-effectively than in-house infrastructure and looks set to foment a new set of Azure-native applications. Of course it's also meant as a vindication of Microsoft's Software+Services strategy, although it does nothing to allay my reservations that the strategy explicitly defines cloud computing as a supplement to conventional on-premises computing rather than as an outright alternative, and thus is prone to encourage over-reliance on in-house infrastructure.
Interim hosting as part of a cloud migration strategy. This can be either a good thing or a bad thing. Moving servers to the cloud as an interim step towards a wholly cloud-native IT strategy is something I can imagine many enterprises having to do in order to ease the complex process of shutting down on-premise assets as part of an orderly migration. But too often, I see people imagining that if they simply port an existing on-premise application to the cloud, that's all they need to do to take full advantage of cloud computing. It's a delusion, and I think it's where many ISVs (and enterprises) are going to get snared by Azure.
Cloud-based services and applications that replace and supercede on-premise assets. This of course is cloud nirvana, where all computing will ultimately end up. Azure shows promise as a platform able to fulfil this use case, but it risks being held back by the distractions of serving all those other use cases, especially those that rely on perpetuating on-premise and single-tenant computing assets. So long as it continues to evolve with the primary aim of complementing rather than rivaling what customers are able to do using their own in-house, on-premise computing infrastructure, it will struggle to compete with other cloud platforms that are not being held back by the same ambivalent motivations.
Why am I so insistent on cloud computing being multi-tenant? A full answer to that question will have to wait for another blog posting, but I recently presented a webinar (disclosure: sponsored by OpSource, an Azure rival) that sets out some of the case. In short, I worry that Windows Azure, and similar platforms, will lure developers into half-baked (half-aaSed?) cloud deployments without realizing they haven't completed the journey to the cloud. Many of the use cases above extend enterprise IT assets into the cloud, but they simply use Azure as an alternative platform for software and applications that are also intended for on-premise deployment. They don't change those assets to take full advantage of the real-time, bandwidth-rich, shared-API cloud environment. The risk is that, instead of being a staging post on the way to realizing the full benefits of cloud computing, Windows Azure will become a kind of rest-home in the cloud where applications go, not to be rejuvenated, but merely to be made more comfortable in their declining years.