What is the new Windows Azure?
Windows Azure was revolutionized by the announcements in the Meet Windows Azure event held on 7th June 2012.
The announcements themselves were but a technically incremental slew of new features for the Microsoft cloud stack. Still, they change the playing field a lot: Not only does Microsoft make a strong entry into the IaaS territory dominated by Amazon AWS, they also make Azure a lucrative option for the most developers of Internet-driven applications. First time in Azure’s almost four-year history, I might say. And this is significant: Redmond is at its strongest when bringing technology to the masses, and now they’re seriously at it.
The 10,000-foot view
To kick this post off, I have prepared a graphic presentation of the features currently available in Windows Azure. The graphic below also outlines the pricing model and availability status (released/CTP/etc.) of each of the components.
(click for a larger version, or download in PDF format)
This is not how Microsoft categorizes the elements of Azure, although I’ve tried to follow their terminology to the extent possible. I had great difficulty in coming up with this logical grouping – and I’m sure another observer could well derive another view… which brings us to the first point about the new Azure.
Azure is immense and very complex. Although Amazon’s competing AWS platform may sport even more sub-brands than Azure, there’s plenty here as well. Also, many of Azure’s features overlap without a strict taxonomy. Luckily Microsoft’s reference material is good: If you want to know how to use Azure for a certain purpose, www.windowsazure.com lets you know (and do) that.
A look from the top: Service models
The essence of Azure boils down to three elements I call service models: Infrastructure as a Service (virtual machines), Cloud Services (web and worker roles) and Web Sites. Of these, Virtual Machines and Web Sites were launched in the Meet event. That alone is telling – the Windows Azure surface just tripled in size.
While all three models can be used for same or similar purposes (for example, you could run a web site in any of the three frameworks) they do have distinct usage scenarios. The following table summarizes much of my architectural thinking on the models.
|Any web site, but best gains with simple architectures.||Anything that works over Web (UI, APIs).||A general purpose server: Any application or service (AD, SharePoint etc.).|
|Development mindset||PaaS: A web site with ASP.NET, PHP or Node.js: Azure is just a deployment target.||PaaS: A set of web and worker roles.||IaaS: Anything goes: it’s a normal server just in the cloud.|
|Pros||Easy, familiar, trivial migration for applicable sites.||High scalability, good fit for the cloud. Most native mental approach to PaaS.||Maximum liberty. Mostly trivial migrations.|
|Cons||Limited scope: Once you need a batch job or similar, you must pick up another technology.||Steepest learning curve, unfamiliar mindset for most. Architecture unique to Azure: lock-in concerns.||Must build much of the scaling and fault-tolerance yourself.|
It would make no sense to attempt to rank the service models by usefulness. They all have their sweet spots, and what works depends heavily on the application and your scenario.
Azure’s definite advantage – the one practically launched this June – is its ability to support multiple models. For example, you could whip up a quick web site to present data, and then switch on a virtual server to power a legacy app used to generate that data. You would then benefit from the ability to scale your web front easily. Your VM solution would be less scalable and fault-tolerant, but it would still work – and in many scenarios, scaling the backend wouldn’t be necessary at all.
The building blocks support you
Once you have embraced a service model, much of your productivity is derived from use of the building blocks. In the simplest case, you could for example deploy a web application and use the Database block. This scenario requires almost zero knowledge of the cloud, and you would still gain some serious benefits (not having manage the database server, backups etc.). At the other extreme, you would take on some serious challenges by adopting Access Control Service for identity or basing your communications on the Service Bus.
The good part about the building blocks is their learning challenge is roughly commensurate to the benefit received. The ones that solve simple problems are fairly simple (blob storage, relational database, CDN); the one needing more studying solve entire categories of problems (for example, Access Control Service radically simplifies many identity-related challenges). They also support gradual adoption. This is particularly important when migrating existing applications: Once your app runs in the cloud – even if only on a cloud VM – you can slowly start adopting the cloud patterns, release by release.
Using the building blocks comes with a disadvantage. As there are no standard APIs for this kind of support services, any investment into leveraging the building blocks cannot be directly reclaimed if you move off of Windows Azure (although architectural solutions necessary to use the Azure blocks are somewhat universal). Finally, developing with the some of the blocks often requires you to have a Windows Azure emulator environment, which can be a problem if you’re not running Windows.
Windows Azure is far from complete, but it’s probably safe to say that the service models are fundamentally fairly done – for now. Many of the near future developments are likely to focus on the building blocks. This also means that it’s a good time to learn Azure: What you have now is likely to stand for a relatively long time, with the additional blocks stacking up incrementally.
What do I need to understand?
A total Windows Azure newbie might then ask: Which of these components are mandatory, and which of them do I have to learn?
A fair question. To benefit from Azure, you might only take advantage of a single building block. For example, you could use blob storage for backup data. On the other hand, to call your app truly cloud-powered, you would use at least one of the service models. The Core and Networking layers are practically a must in any case – at least a cursory understanding of both is necessary.
To sum it up: Today, Windows Azure feels fairly ready. Microsoft needs to keep working, but once the latest additions are out of preview stage, it has pretty much covered all the basics for a cloud platform.
I will be doing a follow-up post on various architectural approaches to benefitting from Azure – more on this then.