Introduction

The Azure App Service Environment (ASE) is a premium feature offering of the Azure App Services which is fully isolated, highly scalable, and runs on a customer's virtual network. On an ASE you can host Web Apps, API Apps, Mobile Apps and Azure Functions. The first generation of the App Service Environment (ASE v1) was released in late 2015. Two significant updates were launched after that; in July 2016, they added the option of having an Internal Load Balancer, and in August of that year, an Application Gateway with an Web Application Firewall could be configured for the ASE. After all the feedback Microsoft had been receiving on this offering, they started working on the second generation of the App Service Environment (ASE v2); and on July of 2017, it's been released as Generally Available.

In my previous job, I wrote the post "When to Use an App Service Environment", which referred to the first generation (ASE v1). I've decided to write an updated version of that post, mainly because that one has been one of my posts with more comments and questions and I know the App Service Environment, also called App Service Isolated, will continue to grow in popularity. Even though the ASE v2 has been simplified, I still believe many people would have questions about it or would want to make sure that they have no other option but to pay for this premium feature offering when they have certain needs while deploying their solutions on the Azure PaaS.

When you are planning to deploy Azure App Services, you have the option of creating them on a multi-tenant environment or on your own isolated (single-tenant) App Service Environment. If you want to understand in detail what they mean by "multi-tenant environment" for Azure App Services, I recommend you to read this article. When they refer to a "Scale-Unit" in that article, they are talking about this multi-tenant shared infrastructure. You could picture an App Service Environment having a very similar architecture, but with all the building blocks dedicated to you, including the Front-End, File Servers, API Controllers, Publisher, Data Roles, Database, Web Workers, etc.

In this post, I will try to summarise when is required to use an App Service Environment (v2), and in case you have an App Service Environment v1, why it makes a lot of sense to migrate it to the second generation.

App Service Environment v2 Pricing

Before getting too excited about the functionality and benefits of the ASE v2 or App Service Isolated, it's important to understand its pricing model.

Even though, they have abstracted much of the complexity of the ASE in the second generation, we still need to be familiar with the architecture of this feature offering to properly calculate the costs of the App Service Environment v2. To calculate the total cost of your ASE, you need to consider an App Service Environment Base Fee and the cost of the Isolated Workers.

The App Service Environment Base Fee covers the cost of the of all the infrastructure required to run your single-tenant and isolated Azure App Services; including load balancing, high-availability, publishing, continuous delivery, app settings shared across all instances, deployment slots, management APIs, etc. None of your assemblies or code are executed in the instances which are part of this layer. Then, the Isolated Workers are the ones executing your Web Apps, API Apps, Mobile Apps or Functions. You decide the size and how many Isolated workers you want to spin up, thus the cost of the worker layer. Both layers are charged by the hour. Below, the prices for the Australian Regions in Australian Dollars are shown.

In Australia, the App Service Environment base fee is above $ 1700 AUD per month, and the Isolated I1 instance is close to $ 500 AUD per month. This means that the entry-level of an ASE v2 with one Isolated Worker costs around $ 2,200 AUD per month or above $ 26,000 AUD per year, which is very similar to the price of the ASE v1 in this region. This cost can easily escalate by scaling up or scaling out the ASE. It's noteworthy that prices vary from region to region. For instance, according to the Azure pricing calculator, at the time of writing, the prices for the Australian Regions are around 35% more expensive than those in the West US 2. To calculate your own costs, in your region and in your currency, check the pricing calculator.

Moreover, the App Service Environment Base Fee is calculated based on the default configuration, which uses I1 instances for the ASE Front-End, and with the scaling rule of adding one Front End instance for every 15 worker instances, as described in the Front End scale configuration page shown below. If you keep this configuration, the App Service Environment Base Fee will stay the same, regardless of the number and size of workers. However, we can scale-up the Front End instances to I2 or I3 or reduce the number of workers per Front End instance. This would have an impact on the App Service Environment Base Fee. To calculate the extra cost, you would need to add the cost of every additional core on top of the base configuration. Before changing the Front-End scaling configuration, bear in mind that the Front End instances act only as a layer seven-load balancer (round robin) and perform SSL termination. All the compute of your App Services is executed in the worker instances.

With these price tag, the value and benefits of the ASE must be clear enough so that we can justify the investment to the business.

The benefits of the Azure App Service Isolated or App Service Environment v2.

To understand the benefits and advance features of an App Service Environment v2, it's worth comparing what we get with this premium offering with what we get by deploying an Azure App Service on a multi-tenant environment. This comparison is shown in the table below.

Reasons to migrate your ASE v1 to an ASE v2

If you already have an App Service Environment v1, there are many reasons to migrate to the second generation, including:

• More horsepower: With the ASE v2, you get Dv2-based machines, with faster cores, SSD storage, and twice the memory per core when compared to the ASE v1. You are practically getting double performance per core.
• No stand-by workers for fault-tolerance: To provide fault-tolerance, the ASE v1 requires you to have one stand-by worker for every 20 active workers on each worker pool. You have to pay for those stand-by workers. ASE v2 has abstracted that for you, and you don't need to pay for those.
• Streamlined scaling: If you want to implement auto-scaling on an ASE v1, you have to manage scaling not only at the App Service Plan level, but at the Worker Pool level as well. For that, you have to use a complex inflation rate formula, which requires you to have some instances to be waiting and ready for whenever an auto-scale condition kicks off. This has its own cost implications. ASEs v2 allow you to auto-scale your App Service Plan the same way you do it with your multi-tenant App Services, without the complexity of managing worker pools and without paying for waiting instances.
• Cost saving: Because you are getting an upgraded performance, you should be able to host the same workloads using half as much in terms of cores. Additionally, you don't need to pay for fault-tolerance or auto-scaling stand-by workers.
• Better experience and abstraction: Deployment and scaling of the ASE v2 is much simpler and friendlier than it was with the first generation.

Wrapping Up

So coming back to original the question, when to use an App Service Environment? When is it required and would make sense to pay the premium price of the App Service Environment?

• When we need to restrict the App Services to be accessible only from within the VNET or via Express Route or Site-to-Site VPN, OR
• When we require to control inbound and outbound traffic to and from our App Services OR
• When we need a connection between the App Services and resources on-premises via a secure and reliable channel (ExpressRoute) without going via the public Internet OR
• When we require much more processing power, i.e. scaling out to more than 20 instances OR
• When a static outbound IP Address for the App Service is required.

What else would you consider when deciding whether to use an App Service Environment for your workload or not? Feel free to post your comments or feedback below!

Happy clouding!

Cross-posted on Paco’s Blog. 

Follow Paco on @pacodelacruz.