Azure Classic Deployment Issues

As a Tier 1 Cloud Service Provider, almost all of our work on Azure is done under the CSP program. Since this is a newer Azure offering, it does not have one of the potential stumbling blocks that other programs such as “Pay as you Go” and “Open” do—Azure Classic Deployments.

Azure History

To understand the issue with Classic deployments, you first have to understand some of Azure’s History. Microsoft originally code-named Azure as “RedDog,” and intended it to host only Platform-as-a-Service (PaaS) workloads like Azure SQL Databases and Web Apps. If you deploy any of these workloads today and look at the naming conventions of objects, you can still see remnants of that name in various places.

The primary container for these objects was an Azure Service. The idea was to gather all the things necessary to make a website work into a single Service.
They named this Management Model the Azure Service Management (ASM). We typically call services deployed under this model a Classic Model.

At the time, Microsoft was adamant that the right way to go to the cloud was through redeveloping your applications to use the ASM model. In addition, there was initially no way to provision Virtual Machines on Azure (Infrastructure-as-a-Service).

Since that is the easiest and quickest way to get onto the cloud, due to competitive pressure, Microsoft eventually started offering IaaS services. However, since a single VM may participate in multiple services, it did not fit well into the Service Management model.

To accommodate the IaaS services, Microsoft created a new model. Instead of basing the model around managing services, they based it as a resource. The new model was called Azure Resource Management (ARM), and it grouped objects into Resource Groups instead of Services.

The Cloud Solution Provider Program

Around the time that ARM was first being deployed, a new program was also introduced, Cloud Solution Provider. Since this was a new program, it was deployed to allow the use of ARM only, not ASM.

This means that resources deployed under the CSP program are never going to be classic deployments.

However, under older programs such as “Pay as you Go,” “Enterprise Agreement,” and “Open,” these classic deployments can still co-exist with ARM deployments. This can present a problem, because Azure Classic Deployments don’t always work with newer features developed since ARM debuted.

Mixing Azure Classic Deployments with ARM Services

We recently ran into a good example of this with Azure Files. We had a client with a legacy Azure Pay as you Go subscription that had Azure Active Directory Domain Services (AAD DS) already deployed. Our intention was to use it as the security for an Azure File Share. Unfortunately it was a classic deployment, which will not work as an identity provider for an Azure File Share, thus requiring an upgrade of AAD DS.

Depending on the service, it can be very easy, difficult, or impossible to upgrade an object from ASM to ARM. In the case of classic AAD DS, you can upgrade it by opening a support ticket with Microsoft. Please note, though, that doing so will incur 1 – 4 hours of downtime for the service. Also understand it is basically a redeployment of the service under ARM.

So, when working with a mixture of Classic and ARM services, don’t always assume that new features will be supported the way you would like by the Classic services.

Have any questions about mixing your Azure Classic Deployment with ARM services? Please contact us at any time!