ARM concepts in Azure Stack for the WAP Administrator–Introduction Post
You may have read about the first Technical Preview for Azure Stack, that was just released. This blog post tells you all about it, and the bits have since been released, with the documentation and a white paper.
A cornerstone component of Azure Stack is Azure Resource Manager (ARM). It plays a central role in how you design templates and how tenants leverage and deploy those templates.
While it may be tempting to map ARM’s concepts to something we currently know in the Microsoft private cloud portfolio (e.g. Windows Azure Pack, WAP), it actually doesn’t apply very well to Azure Resource Manager: Like most components of Azure Stack, Azure Resource Manager comes from Microsoft Azure (public cloud) and is being brought on premise through this new product. There is a lot of documentation available already on ARM, after it’s been proof-tested for the last 12 to 18 months in Microsoft Azure.
But we’ll give a try at mapping those concepts through this blog post series J, for the benefit of helping folks understand how to map concepts between a WAP-based solution and Azure Stack. For this reason, we titled the series “ARM concepts in Azure Stack for the WAP Administrator”, and this in the introduction post for the series, with the posts coming over the next few weeks.
The focus will be around Azure Resource Manager capabilities, as shown in the table of contents below. We will focus on designing and publishing tenant services, and templates. Each post will try to highlight how the concepts map, and what’s different compared to a Windows Azure Pack solution.
Table of contents
- Introduction post, and some first information on the Azure Stack POC architecture and ARM’s role – this post
- Cloud Service Delivery in WAP and Azure Stack
- Plans, offers, subscriptions
- Resource Deployment - using the portal, Visual Studio, APIs or CLI
- Packaging and publishing templates on Azure Stack
- Multi-tier applications with ARM
- In-guest configuration with ARM and technologies like Virtual Machines (VM) Extensions, including Desired State Configuration (DSC)
- Troubleshooting IaaS deployments in Azure Stack – This maps to an understanding of how the different Resource Providers (RPs) work together in an Azure Stack installation
Important note: Some posts in this series will be more focused on Infrastructure as a Service (IaaS). This will especially be true with posts #6 and #7, and we may also partially use IaaS as a way to illustrate some concepts in posts #3 and #5. But, don’t be mistaken: We will be doing so mostly because it’s what you many of you may be using today with WAP (with VM Roles and Standalone VMs). However, as highlighted in the links and documents from the beginning of this post, the mission of Azure Stack is much broader than IaaS, and several other Microsoft Azure services are planned during the preview cycle for Azure Stack, and beyond. For example, multi-tenant and Azure-consistent storage is already present in this first preview, as are Web Apps since the update today. You can view the list of Azure Services planned at general availability of Azure Stack in this white paper. To summarize, ARM concepts are independent of the resource provider they call, even though our series will focus on some IaaS-specific concepts as well, like Virtual Machines (VM) extensions.
Finally, this introduction post would not be complete without mentioning the non-goals for the series: This series does not intend to cover a full comparison of Windows Azure Pack vs Azure Stack. As a new product, Azure Stack is much more than the next version of Windows Azure Pack, as the white paper highlights. This specific series will also not cover deployment or infrastructure.
My peers Victor Arzate and Tiander Turpijn will be co-authoring this series with me, and we hope you will find it useful as you start exploring the first technical preview of Azure Stack!