We are happy to announce an upgrade to the App Service Environment. The App Service Environment (ASE) is a powerful feature offering of the Azure App Service that gives network isolation and improved scale capabilities. It is essentially a deployment of the Azure App Service into a subnet of a customer’s Azure Virtual Network (VNet). While the feature gave customers what they were looking for in terms of network control and isolation, it was not as “PaaS like” as the App Service was normally. We took the feedback to heart and for ASEv2 then we focused on making the user experience the same as it was in the multi-tenant App Service while still providing the benefits that the ASE provided. To make things clearer I will use the abbreviation ASEv2 to refer to the new App Service Environment and the initial version as ASEv1.
App Service Plan based scaling
The App Service Plan (ASP) is the scaling container that all apps are in. When you scale the ASP you are also scaling all of the apps in the ASP. This is true for the multi-tenant App Service as well as the ASE. This means that to create an app you need to either choose an ASP or create an ASP. When you wanted to create an ASP in ASEv1 you needed to pick an ASE as your location and then select a worker pool. If the worker pool you wanted to deploy into didn’t have enough capacity then you would have to add more workers to it before you could create your ASP in it.
With ASEv2, when you create an ASP you still select the ASE as your location but instead of picking a worker pool you use the pricing cards just like you do outside of the ASE. There are no more worker pools to manage. When you create or scale your ASP we automatically add the needed workers. To distinguish between ASPs that are in an ASE and those in the multi-tenant service we created a new pricing plan named Isolated. When you pick an Isolated pricing plan during ASP creation, it means that you want the associated ASP to be created in an ASEv2. If you already have an ASEv2 you simply pick the ASE as the location and the size of worker you wish to use.
ASE creation
One of the other things that limited ASE adoption was feature visibility. Many customers did not even know that the ASE feature existed. To create an ASE you had to look for the ASE creation flow which was completely separate from app creation. In ASEv1 customers need to add workers to their worker pools in order to create ASPs. Now that workers are added automatically when ASPs are created or scaled, we are able to place an ASEv2 creation experience squarely in the ASP creation flow.
To create a new ASEv2 during the ASP creation experience, select a location that is not an ASE and select one of the new Isolated SKU cards. When you do this the ASE creation UI is displayed which enables you to create a brand new ASEv2 in a new VNet or in a pre-existing VNet.
Additional benefits
Due to the changes that were made with the system architecture, the ASEv2 has a few additional benefits over ASEv1. With an ASEv1 the maximum default scale was 50 workers. With ASEv2 the maximum default scale is now 100. That means that you can have up to 100 ASP instances hosted in an ASEv2. That can be anything from 100 instances of an ASP to 100 individual ASPs, with anything in between.
The ASEv2 also now uses Dv2 based dedicated workers which have faster CPU’s, twice the memory per core and SSDs. The new ASE dedicated workers sizes are 1 core 3.5 GB, 2 core 7 GB, and 4 core 14 GB. The end result is that 1 core on ASEv2 performs better than 2 cores in ASEv1.
To learn more about the ASEv2 you can start with the Introduction to the App Service Environment. For a list of the ASE related documents you can also look at App Service Documentation.
