Cloud service extended support - Supported and unsupported scenarios

What is cloud service extended support?

Azure Cloud Service Extended support (shortly CS-ES) is the ARM (Azure Resource Manager) version of the existing Azure Cloud Service (Classic) version. The Azure cloud service (classic) works on the RDFE model while CS-ES has been upgraded to the ARM model which helps the service to utilize all the latest updates and the ARM features.

In addition, the Cloud service (classic) is deprecated for new customers as it uses an older framework and new customers are recommended to use the CS-ES.

The existing customers are provided a timeframe till Aug 31st, 2024 after which the Cloud service (classic) will retire and be deprecated for all customers.

New Features of CS-ES

The CS-ES gets to use most of the features of Azure Resource Manager model which the Cloud service (classic) was missing. A few major ones have been highlighted below.

• Tags support
  • Used for alignment purposes (based on cost center or the environment for the resource)
• Role based access control (RBAC)
  • Provide individual access to the user at a desired level of control based on the role.
• Governance using policy
  • The RP ‘Microsoft.compute’ can be used in policy to govern and restrict activities in the CS-ES model.
• Template Deployment.
  • Support of ARM template deployment which eases work of deploying the same resource under multiple environments or for template-based automation.

Supported and Unsupported scenarios for CS-ES from Cloud Service (classic)

Supported scenarios for CS-ES from Cloud Service (classic):

For the CS-ES, let us look at the supported features from the Cloud service (classic model)

• You create the code, define the configurations, and deploy it to Azure. Azure sets up the compute environment, runs your code then monitors and maintains it for you.​
• Cloud Services (extended support) also supports two types of roles, web and worker. There are no changes to the design, architecture or components of web and worker roles.​
• The three components of a cloud service, the service definition (.csdef), the service config (.cscfg), and the service package (.cspkg) are carried forward and there is no change in their formats.​
• No changes are required to runtime code as data plane is the same and control plane is only changing (Control plane refers to the all functions and processes that determine which path to use to send the packet or frame. Data plane refers to all the functions and processes that forward packets/frames from one interface to another based on control plane logic.).​
• Azure GuestOS releases and associated updates are aligned with Cloud Services (classic)​
• Underlying update process with respect to update domains, how upgrade proceeds, rollback and allowed service changes during an update don't change.

Changes to the existing scenarios for CS-ES from Cloud Service (classic):

After verifying the supported scenarios, it is also recommended to check the changes to the existing features in CS-ES rather than how it was used in Cloud service (classic).

• Must be inside a VNET. VNET need to be referenced within the NetworkConfiguration section of the .cscfg when deploying Cloud Services (extended support).​
• RDFE Certificate Store replaced by Key Vault​. ​
• Use of ARM templates​
• Already deprecated VM sizes like Basic A0, A1, etc needs to be replaced with Standard_A0, Standard_A1 SKUs​​
• Each cloud service (extended support) is a single independent deployment. Cloud services (extended support) does not support multiple slots within a single cloud service.​
• VIP Swap capability may be used to swap between two cloud services (extended support).​
• Domain Name Service (DNS) label is optional for a cloud service (extended support). In Azure Resource Manager, the DNS label is a property of the Public IP resource associated with the cloud service.

Unsupported scenarios for CS-ES from Cloud Service (classic):

Now, let us look at the unsupported scenarios of CS-ES when compared to the Cloud service (classic) model.

• Creating Empty cloud service :
  The concept of hosted service names does not exist anymore, you cannot create an empty Cloud Service (extended support).
• Resource Health Check (RHC) :
  Cloud Services (extended support) does not support Resource Health Check (RHC)
• Stopped state :
  Cloud Services (extended support) deployment only supports the Stopped- Allocated state which appears as "stopped" in the Azure portal. Stopped- Deallocated state is not supported.
• Scaling across clusters, zones and regions:
  Cloud Services (extended support) deployments cannot scale across multiple clusters, availability zones and regions.
• CTP package format :
  CTP package format is not supported in Cloud Services (extended support). However, it allows an enhanced package size limit of 800 MB
• Virtual Network reference :
  Virtual network reference is mandatory during the creation of a cloud service. For an existing cloud service, the virtual network reference cannot be changed. The virtual network address space itself can be modified using VNet APIs.