BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
What's wrong with Windows Azure? In a word: marketing.
From the beginning, Microsoft's efforts to explain Windows Azure to the world fell under the assumption that potential customers understood cloud computing. After all, if they know what a nail is used for, then you only need to explain the features and benefits of a hammer.
Microsoft missed the boat in getting this point out to potential customers, at the cost of Windows Azure.
First, consider how cloud computing looked three years ago. It was generally accepted that everyone had their own definition of cloud. When Windows Azure entered the market, vendors and customers were free to define the cloud to suit their needs or, more often, their desires. The architects of Windows Azure created a Platform as a Service (PaaS) implementation that closely matched NIST's definition of cloud computing. Microsoft went with it -- it didn't have to create and defend its own definition; a generally respected standards organization had already done the legwork.
Second, Amazon Web Services (AWS) had been in the market for roughly three years when Windows Azure previewed in late 2008. Much like Windows Azure was a near-perfect implementation of PaaS, AWS was a near-perfect implementation of Infrastructure as a Service (IaaS). And while Amazon had plenty of technical guidance available as to how its cloud offering should be used, it was also possible to use it in a very traditional manner, where it behaved like a legacy hosting service. This appealed to customers looking for a new technology that could be adopted with minimal changes to implementation approaches.
Third, in the fall of 2005, Ray Ozzie, then chief software architect at Microsoft, introduced what has become known as the "services disruption memo." Ozzie outlined the case that service-oriented computing would become the next paradigm shift in the industry and introduced Microsoft's strategy to address this.
Windows Azure was part of that effort, though Microsoft didn't let on to this until late 2008. And when it was introduced, it was part of a message campaign called "software plus services." No one at Microsoft could explain what it meant, and its competition claimed this was a cynical attempt to redefine Software as a Service (SaaS) to Microsoft's advantage. The message that Windows Azure was a platform upon which custom services could be built quickly and easily was lost in the mix.
The problem with this is that markets, like nature, abhor a vacuum. If a vendor fails to define its product and, more importantly, fails to define a product's value proposition, the market will do it. And much of this market-driven definition will focus on what the product is not. For Windows Azure, this boiled down to it not being IaaS.
Unfortunately, with each passing month, cloud consumers declared strongly that what they actually wanted was IaaS.
Many observers have assessed that the market did not and will not want PaaS, at least not for some time. And Windows Azure often appears as the poster child for rejection. Customers say they don't necessarily want what Windows Azure has. In reality, though, many have never heard the real Windows Azure/PaaS value proposition. PaaS hasn't been readily adopted because it is a different approach and therefore must be used differently. But sometimes different is a good thing.
Microsoft missed the boat in getting this point out to potential customers, at the cost of Windows Azure. And this is a textbook example of what happens when a vendor doesn't control -- or clearly state -- its product message, especially in newer markets like cloud computing.
About the author
Mark Eisenberg has been working in mobile application development since 2005 and joined Microsoft's nascent Windows Azure sales team in 2009, despite being an early cloud skeptic. After embracing the cloud and its technological potential, Mark began working at Fino, where he combines his cloud and mobile expertise with his technological background to expand the firm's developing cloud and mobile practices.