Archive for February, 2016

Transitioning from ASM to ARM

Azure services to support the Resource Manager modelThe interface to Azure has transitioned from the Azure Service Management (ASM) model to the Azure Resource Manager (ARM) model over the past year or so.  You can view the predecessor ASM as the REST API that allowed you to programmatically (PowerShell or CLI) access the functionality of the Azure “Classic” Portal.  Using X.509 certificates, ASM was the alternative and automated way to manage deployments, storage, hosted services, and almost anything you could manually do in the Classic portal.

In 2015, ARM gradually began replacing the ASM model in incremental service rollouts. ASM supports the current Azure “IBIZA” Portal. Using Azure Active Directory for authentication, ARM (is the recommended and supported way going forward to manage your Azure resources.  ARM promotes the concept of Resource Groups (RG). An RG is a declarative way of specifying Azure resources (such as storage, VMs, Web Sites, etc.) in a logical grouping to that they are deployed, or released, as a unit.

RGs use a JSON-based template model to describe the relationship hierarchy of all the resources.   During execution the template can be run in inline manual entry mode, or in a file named azuredeploy.parameters.json.  This is typically obtained at runtime from the GitHub code repository.

I remember in grammar school having to learn the metric system since they told us that over time the US would no longer use the measurements we had grown up with (inches and pounds and ounces).  The transition to the metric system would have been wrought with hair-pulling I’m sure for awhile as we cowered in our circa 1970 back yard “bomb shelters” (okay, dating myself here a bit!).  The transition from ARM to ASM has not had as dramatic an influence on society as the shift to the metric system would have had on the US population.  However, it has caused much consternation on the part of IT folks responsible for the deployment and management of Azure resources for their company. Here is some current guidance and information on where the process is as of today (Leap Day 2016).

Some services still don’t support ARM: We have re-tooled the majority of Azure services to support the Resource Manager model. For some of the remaining services that don’t yet support this model, we’re planning to complete the work within the next few months.

Connecting ASM and ARM environments: Connecting ASM and ARM environments is possible today by linking VNETs created under these models via the gateways. Both environments can also be connected to on-premises via VPN.  If using ExpressRoute though, an ExpressRoute circuit created in the ASM model can only be used with a VNET in ASM model, and ExpressRoute circuit created in the Resource manager model can be used with VNET created in Resource Manager model. We are working to address this and by April 2016, just one ExpressRoute circuit will be sufficient to connect Virtual Networks from both environments. In addition, we are also working on a capability that would allow setting up a high bandwidth ASM VNET to ARM VNET Peering connection [in the same region] without a gateway in between them. The Peering should be available in the summer timeframe.

Migration from ASM to ARM: Today, there are scripts to help you migrate Virtual Machines from ASM to the ARM model. We are also working on a few more solutions that will help reduce the VM reboots and network downtime when migrating.

When to choose ASM vs. ARM: When building new applications in Azure or starting new projects, we strongly encourage considering using the ARM model. However if some of the services aren’t yet supported under ARM, or if you have existing deployments under ASM, please continue using ASM until you become comfortable with connecting and managing both environments simultaneously. In the long term, please consider migration of ASM to ARM deployments (using migrations solutions we have planned) but rest assured that that we will be supporting the ASM model for a long time to come.


Yes – take a look at the new Microsoft Azure Stack (just put into technical preview). Azure Stack (AS) is a new hybrid cloud platform product that allows organizations to deliver Azure services from their own datacenter, thereby helping them achieve more.

The main motivations behind the development of AS is customers have asked for Azure in their DC – plain and simple. Various motivations have driven the creation of AS.

Business requirements, If the Customer has a set of requirements that the Azure Cloud can’t support, then the hybrid cloud may be the answer. These could be items such as wanting to minimize latency, customization of application architectures, data sovereignty, etc.

Application Flexibility – Make cloud-first innovation possible everywhere . This allows you to make app deployment decisions based on business need (vs. technology constraints). Deployment is based not upon technical capabilities but rather upon business needs (On prem vs in Cloud). In other words, we don’t want to use technologies in the Cloud for the sole reason that they are not available on premises. We will talk a little more about the innovation possibilities that this opens up in another slide.

Inadequate Alternatives – Finally, customers are finding that the alternatives they currently have don’t meet their needs. For organizations that are looking for speed and innovation of cloud computing in their datacenter, Microsoft Azure Stack offers the only hybrid cloud platform that is truly consistent with a leading public cloud. Only Microsoft can bring proven innovation – including higher level PaaS services – from hyper-scale datacenters to on-premises environments to flexibly meet customers’ business requirements.

So let’s look at the three cases for the hybrid Cloud platform starting with Business and Technical considerations.

  • Latency – Latency is an issue if an app requirement that cannot be satisfied by using the public Cloud.
  • Customization – For example, an organization needing deep integration with internal applications, systems,. Or Customization for using (on-premises) a certain type of hardware that a company already uses.
  • Data sovereignty – Data cannot be allowed to leave country borders or the enterprise – e.g. EU.
  • Regulation – Local laws around how to transact business, public sector organizations, compliance and auditing needs etc. Regulations that require data to be handled on premises

The Microsoft Hybrid Cloud with Azure Stack brings the power of Azure into your DC. There are three main investment areas or benefits of the hybrid cloud platform.

  1. Azure Services in your Datacenter – initially a subset of the full azure set (compute, Networking, storage, app services, service fabric). Your IT folks can transform DC resources into Cloud services. This is a Cloud “Inspired” infrastructure – due to translation to on prem machines to Azure VMs. Have to map what’s on prem to the Azure models.
  • Transform on-premises datacenter resources into cloud services for maximum agility.
  • Run Azure infrastructure services – including Virtual Machines, Virtual Network, and Blob/Table Storage – for traditional apps like SQL Server or SharePoint.
  • Empower developers to write cloud-first apps using on-premises deployments of Azure App Service (Web Apps) and Docker-integrated containers.
  • Make developers productive with the same self-service experience as Azure.
  • IT gets to control on-premises Azure experience to best meet business requirements.
  • Hit on PaaS differentiation: – Web Apps, Docker-integrated containers

2. Unified App Development – The same API, PowerShell, ARM etc use in Azure work with Azure Stack. Write once deploy both AC and Azure. RBAC and Powershell, azure portal, Visual studio. Choice of open source app platforms, languages, and frameworks.

  • Identical APIs and application model with Azure Resource Manager
  • Role-based access control with Azure Active Directory and Azure Resource Manager
  • Unified Azure SDK
  • Native Visual Studio integration
  • Support for application platforms, languages, and frameworks, including Linux, Java, node.js, and PHP

3. One Azure Ecosystem – can get quickly productive in AS since the platform is the same on both locations.

  • Curated Azure Resource Manager templates for SharePoint, SQL, AD
  • Curated gallery images for Windows Server and Linux
  • GitHub-based gallery

This approach and solution builds bridges between all three schools of thought: developer, IT Pro, and business dev person.

  • As a developer, I would be excited about… Application developers can maximize their productivity using a ‘write once, deploy to Azure or Azure Stack’ approach. Using APIs that are identical to Microsoft Azure, they can create applications based on open source or .NET technology that can easily run on-premises or in the public cloud. They can also leverage the rich Azure ecosystem to jumpstart their Azure Stack development efforts.
  • As an IT professional, I’m going to be super happy about (moving forward in my career, pleasing my developers, etc.). IT can help transform on-premises datacenter resources into Azure-consistent IaaS and PaaS services, thereby maximizing agility and efficiency. End users can quickly provision services using the same self-service experience as Azure. IT gets to use the same automation tools as Azure to control the service delivery experience.
  • As a business, you can truly take advantage of cloud on your terms.

Stack Architecture

Let’s look at the architecture of the Azure Stack (with Level 1 as the topmost layer and Level 5 on the bottom).

Level 1 – Guest workload resources created by Azure Stack and which end-users (devs / IT Pros) use to get their work done. Each of those resources as supported by an Azure service or combo of azure services.

Level 2 – At the next layer down we get into the actual bits of Azure Stack, starting with the end user experiences. Each of these guest workload resources are supported by the both unique or common (in both AS or Azure portal) end user experience and developer tools.  It’s important to remember that this is “just Azure” and so the experiences that you’ve come to know and count on there are the same in Azure Stack. This means the same Azure Portal, same support for a variety of open source technologies and same support for development tools including integration with Visual Studio.

Level 3 – Unified Application Model from Azure Resource Manager. This means the same model of provisioning/accessing public cloud Azure is the same as provisioning/accessing AS. This piece of technology is central to how Azure and Azure Stack operate as clouds and we’ll talk more about this one.

Level 4 – The extensible service framework is mapped into three services

  • Core Services – Common services across all resource types (RBAC, subscriptions, Gallery, usage, metrics, etc.) these services are a core part of AS. (Ex. Azure Portal)


  • Additional Services – The Azure model is extensible that you can add to AS and customize the AS in your DC. (Ex Web apps for TP1 can be installed to AS if you want). Also in future could be API Apps, Mobile Apps, and Logic Apps.


  • Foundational Services – Some services in Azure are at the root/basis for other services. This is the main part of what Azure Stack is – this set of foundational services (i.e. VM, Containers, Blob, Queues, and Table storage, and Premium Storage, Networking (with LB and gateway), Platform services) that provide resources to customers as well as serve as the basis for other services.

Level 5 – This is all supported by the Cloud Infrastructure that runs on Windows Server technology on the physical hardware (Infra. Mgmt., Compute, storage, networking)

Azure Stack came out the end of  January for Public Preview 1. GA is planned for Q4 CY 16.