Build regionally resilient cloud services using the Azure Resource Manager

Cloud Services (extended support) and migration to Azure Resource Manager (ARM)

Today, we are announcing the preview of Cloud Services (extended support), which is a new Azure Resource Manager (ARM) based deployment model for Azure Cloud Services. Cloud Services (extended support) has the primary benefit of providing regional resiliency along with feature parity with Azure Cloud Services deployed using Azure Service Manager (ASM). It also offers some ARM capabilities such as role-based access and control (RBAC), tags, policy, and supports deployment templates.

With this change, the ASM-based deployment model for Cloud Services will be renamed Cloud Services (classic), starting today. Customers will retain the ability to build and rapidly deploy web and cloud applications and services. Customers will be able to scale cloud services infrastructure based on current demand and ensure that the performance of applications can keep up while simultaneously reducing costs. 

Cloud Services (extended support) provides two paths for customers to migrate from ASM to ARM. One path is to re-deploy, where customers deploy cloud services directly in ARM and then delete the old cloud service in ASM after thorough validation. The second path is to execute an in-place migration that gives our customers the ability to migrate Cloud Services (classic) to ARM with minimal to no downtime.

The preview of the re-deploy path of Cloud Services (extended support) is available starting today, while the in-place migration path will be announced soon.

Additional Azure services to consider for migration to ARM

When evaluating migration plans from Cloud Services (classic) to Cloud Services (extended support), customers may want to investigate the opportunity of taking advantage of additional Azure services such as Virtual Machine Scale Sets, App Service, Azure Kubernetes Service, and Azure Service Fabric. These services will continue to feature additional capabilities, while Cloud Services (extended support) will primarily maintain feature parity with Cloud Services (classic.)

Depending on the application, Cloud Services (extended support) may require substantially less effort to move to ARM compared to other options. If the application is not evolving, Cloud Services (extended support) is a viable option to consider as it provides a quick migration path. Conversely, if the application is continuously evolving and needs a more modern feature set, do explore other Azure services to better address current and future requirements.

Deployment model changes

Minimal changes are required to the service configuration and service definition files (.cscfg and .csdef) to deploy Cloud Services (extended support). No changes are required to runtime code, however, the deployment scripts will need to be updated to call new ARM-based APIs. The major differences between Cloud Services (classic) and Cloud Services (extended support) with respect to deployment are:

◉ ARM deployments use ARM templates which is a JavaScript Object Notation (JSON) file that defines the infrastructure and configuration for the project. The template uses declarative syntax, which lets customers state what they intend to deploy without having to write the sequence of programming commands to create it. The Service Configuration and Service definition file needs to be consistent with the ARM template while deploying Cloud Services (extended support). This can be achieved either by manually creating the ARM template or using PowerShell, Portal, or Visual Studio.

◉ Customers must use Azure Key Vault to manage certificates in Cloud Services (extended support). Azure Key Vault lets customers securely store and manage application credentials such as secrets, keys, and certificates in a central and secure cloud repository. Applications can authenticate to Key Vault at run time to retrieve credentials.

◉ A virtual network is mandatory for any resource deployed through the Azure Resource Manager. Virtual networks and subnets in ARM are created through existing ARM APIs and referenced in the .cscfg, within the network configuration section.

Source: microsoft.com