Azure Resource Manager: The Secret Sauce of the Microsoft Cloud Strategy
Since its introduction in 2009, Microsoft Azure has gone through a significant transformation. What started as a hardcore set of platform services is now a force to be reckoned within the infrastructure market as well.
According to Gartner, Azure is inching closer to AWS, firmly securing its place in the top right section of the Infrastructure-as-a-Service (IaaS) Magic Quadrant, which is reserved only for the market leaders.
One technology that’s accelerating Microsoft’s infrastructure services is Azure Resource Manager, which has become the cornerstone of Microsoft cloud platform. And it’s gearing up to play a key role in Azure Stack, the private cloud offering from Redmond.
In this multi-part article series, of which this piece is the first installment, we will take a closer look at Azure Resource Manager and its capabilities
The Evolution of IaaS
Back in 2008, Microsoft’s vision for public cloud revolved around platform services targeted at developers. It designed Azure to be the best platform to deploy and run .NET applications. Like its early counterparts — Google App Engine, and Heroku — Azure emphasized on building stateless applications that could scale automatically.
Developers had to package the code in one of the two deployment units: Web Role and Worker Role. The Web Role hosted the public-facing web frontends and APIs while the business logic went into the Worker Role. Persistent data was spread between Azure Storage and SQL Azure, the NoSQL and RDBMS offerings from Microsoft. The Service Bus exposed additional application services including messaging and queuing. The combination of Web Role and Worker Role was called as Cloud Services, which collectively delivered the compute capabilities of the platform.
Watching, no doubt, the stupendous growth of Amazon EC2, Microsoft realized the importance of pure-play infrastructure services. But the design and architecture of Azure made it extremely difficult to expose raw VMs to the outside world. Interestingly, both Web Role and Worker Role were just stateless virtual machines running on top of Hyper-V. Microsoft brought another flavor of cloud services called the VMRole, which enabled customers to open a remote desktop session to install custom software. These were the early signs of Azure IaaS.
VMRole was not even a remote match to Amazon EC2 instances. It essentially followed the same stateless philosophy of Cloud Services. Eventually, customers could mount object storage containers as persistent disks of VMRole. That partially solved the problem of running traditional workloads such as databases and line-of-business applications.
In 2012, Microsoft tweaked VMRole further to launch Azure VMs, which marked its official entry into the IaaS market. It partnered with Canonical and Oracle to support various Linux flavors along with Windows Server.
The early IaaS offerings were plagued with multiple issues. The I/O performance of persistent disks didn’t match the expectations. Microsoft suffered from multiple issues related to disk I/O and throughput, which questioned the viability of the platform for running mission-critical workloads.
Since Azure VMs were deeply rooted in the Cloud Services Foundation, Microsoft could do very little in augmenting the IaaS platform and improving the performance. The other area that was seriously impacted was networking. It was tough to implement transparent load balancing, auto scale, floating IP addresses, and VPN connectivity. None of these features were factored in the original avatar of Azure. Implementing standard DevOps processes on Microsoft’s public cloud was extremely hard.
During the same timeframe, Google decided to build IaaS from the ground up instead of extending App Engine. Google Compute Engine was launched almost the same time. On the other hand, Amazon continued to make progress with EC2 putting Microsoft under tremendous pressure. These factors forced Microsoft to go back to the whiteboard to redesign Azure IaaS.
Azure Resource Manager and IaaS V2
Microsoft laid the foundation for the next-generation IaaS at Build 2014 where it announced the new portal in preview. Along with it came Azure Resource Manager (ARM), the new way of declaring and provisioning resources on the Microsoft cloud. The new portal had the unique capability of grouping logically associated set of resources as one unit, which is called as a Resource Group.
Before the availability of the new portal and Resource Groups, Azure users had to deal with a fragmented approach that scattered the associated resources across different services. In Azure, a typical web application would have a few VMs, storage accounts, a load balancer, security groups, a virtual network, and an Azure SQL Database. Since each service is independent of the other, they are created in their respective sandboxes with no logical grouping. They don’t share any context for deployment, billing, and deletion. The most painful part is deleting all the resources belonging to an application. Users need to navigate to multiple sections of the portal and delete each of them manually:
With ARM, customers can declare all the associated resources in a JSON template which acts as the unit of deployment. These templates can be submitted through the portal or the command line utility. All the resources declared in the template go under one resource group. The new portal offers a consolidated view of resources that belong to the same resource group. The screenshot below shows a typical web application deployed through an Azure Resource Manager template.
The concept of Azure Resource Groups (RG) and Azure Resource Manager changed the game for Microsoft. It not only simplified the provisioning and deprovisioning of Azure resources but gave the company a common foundation for its public cloud and private cloud IaaS offerings. Azure Stack, Microsoft’s private cloud, has deep integration with ARM. The same ARM template can be deployed on both Azure (public cloud) and Azure Stack (private cloud). This is possible because of the way Microsoft is exposing the underlying infrastructure resources. A template author need not decide the target environment when declaring the resources. At runtime, it gets translated to a deployment either in the public cloud or private cloud. Developers using Visual Studio can author Azure Resource Manager templates interactively through the most powerful IDE.
In the upcoming parts of this series, we will learn more about the architecture, the resource providers, migration from classic deployments, comparison with AWS CloudFormation, and the best practices for authoring Azure Resource Manager templates.
Feature image via Pixabay.