Page 47 - MSDN Magazine, April 2017

Figure 6 App Service Environment Version 2 Portal Page
the ASEv2 creation experience can be placed squarely in the ASP creation flow, as shown in Figure 5.
To create a new ASEv2 during the ASP creation experience, you simply select a non-ASE region and then select one of the new Isolated SKU cards. When you do this, the ASE creation UI is dis- played, which enables you to create a brand new ASEv2 in either a new or pre-existing VNet.
Time to scale The new ASP creation flow became possible only because the process for provisioning new workers was accelerated. ASEv2 automatically provisions new workers for your ASPs when youcreateorscaleanASP.Theonlywaytomakethisareasonable customer experience was to reduce the time required to create and scale out. To make this work, as much as possible is preloaded onto the VHDs used for provisioning the role instances, minimizing supplementary required reboots. Moving to the Dv2 workers was also helpful as they have faster cores and use SSDs. Both of those practices make install and reboots faster.
The new ASP creation flow became possible only because the process for provisioning new workers was accelerated.
System Management In ASEv1 the customer had to manage the front ends, workers and the update domain workers. The front- end roles handle HTTP traffic and send traffic to the workers. The workers are the VMs that host your apps. The update domain workers act as standby hosts in case of upgrades or worker failures. With ASEv1 the customer had to know how these components all worked together and scale the resource pools appropriately. When msdnmagazine.com
workers had to be scaled out to handle more ASP instances, users had to add more front ends and update domain workers.
ASEv2, in contrast, hides away the infrastructure. Now users simply scale out their App Service plans and the infrastructure is added as needed. When an ASP needs more workers, the workers are added. Front ends and update domain workers are added auto- matically as the quantity of workers is scaled out. If customers have unusual needs that require more aggressive front-end scaling, they can change the rate at which front ends are added to their ASE.
As you can see in the ASEv2 portal page in Figure 6, things are far simpler now. There’s no longer a need for the worker pool or front-end UI pages. With all scaling now automatic, there are no more scale or autoscale controls. And because the IP addresses used by the ASE are pretty important to know about, the UI con- solidates that information.
The release of ASEv2 is by no means the end of the ASE feature development efforts. There will continue to be a steady stream of improvements, but they will not impact the UX to the extent the changes made with ASEv2 did.
Additional Benefits Due to the changes made to the system archi- tecture, ASEv2 has a few additional benefits over ASEv1. With ASEv1, the maximum default scale was 50 workers. There were a number of system-architecture reasons why that limit was set, but these issues were addressed in creating the new ASEv2 experience. With ASEv2 the maximum default scale is now 100, which means you can have up to 100 ASP instances hosted in ASEv2. This can be anything from 100 instances of an ASP to 100 individual ASPs, with anything in between.
Moreover, ASEv2 now uses Dv2-based dedicated workers. These new dedicated workers are much faster than the A series VMs on which ASEv1 depended. They have faster CPUs, which improves throughput, and SSDs, which improves file-access performance. As in the multi- tenant app service, the choices for dedicated workers when creating an ASP are single core, dual core or quad core. The new ASE dedicated workers, however, have double the memory of their multi-tenant counterparts and come with 3.5GB, 7GB or 14GB of RAM, respectively.
Wrapping Up
ASEv1 was a great first step toward enabling customers to have net- work isolation for their App Service-hosted applications. ASEv2 built on that experience a far more PaaS-like capability that’s not just easier to use, but is also much more powerful.
All of the changes that have been noted here for the ASE have been vetted by a large number of MVPs and customers. Even before development started, the team wanted to validate its approach with people who had already tried using an ASE. As a result of this input-heavy approach, we are confident that the new ASE experience will be considered a substantial improvement and look forward to its success in the field. n
Christina Compy is originally an aerospace engineer who worked on the Hubble Space Telescope and has been working in the software industry for more than 20 years. She has been a program manager at Microsoft since 2013 and works on enterprise-focused capabilities.
thanks to the following Microsoft technical expert for reviewing this article: Stefan Shackow
April 2017 33