Overview Of Azure App Service Environment Using ARM VNET

Recently the Microsoft Azure Team announced the support for ARM VNETs, while creating the App Service Environments. You can take a look at the detailed announcement here.

Before we jump into the details, let me give the brief idea about what exactly ASE stands for and what is its significance in the real world

ASE in Azure means App Service Environment. Yes, as you can easily guess by its name it is some kind of environment for your app Services.

Let’s switch gears here and first understand what are app Services, given the recent changes in Azure (which are quite frequent and I consider it as a good sign). The app Services concept was brought into the picture, and it is nothing but the set of Services, shown below:

• Azure WebApps (previously known as Azure Websites)
• Logic Apps
• API Apps
• Mobile Apps

Now, these app Services are exposed as PaaS; i.e., platform as a Service offering of Azure, which means in order to run each Service, it will definitely need to compute the resource. The number of computed resources required depends on your Service load. In short – higher the expected traffic on the Service and you will need the high capacity compute nodes and for light weight traffic, you might want less powerful instances, which means you will need some plan to make sure of the continuous availability of your Application by deploying the correct number of compute instances, which is nothing but your app service plan. In a nutshell, the app Service plan is nothing but the set of computing resources, required to run your app Services.

Now coming back to the app Service environment, it is nothing but the premium Service plan of app Services, which can provide you full isolation and a dedicated environment for securely running you app Services.

Some of the advantages of it are:

• Complete isolation
• Very high scalability
• Secure network access 

Since we talked about the isolation, how can you relate it in Azure? Some of you might have probably guessed it by now, that if we need to set up isolation in Azure, we will need to create a virtual network aka Azure VNET.

Now about VNETs, Azure supports two modes of deployment i.e. Classic and Resource Manager. This article assumes that you are familiar with both the modes of deployment. Thus, we will not be going into the details of it. If you are not aware of it, the best way to get started would be this article ,which is apt enough to give you the basic conceptual idea.

All right, I guess that’s enough of a theory and let’s quickly see, how we can build ASE with ARM VNETs.

First things first, in order to provision anything with RM mode of deployment, we will need to create resource group. Thus, let’s do it.

The process is quite straight forward. Launch Azure portal and navigate to resource group section. Click Add from top nav action bar and create your resource group.

 

Once you are done with the creation of the Resource group, next thing we will need is to create the virtual network, which is a mandate. Before you create your App Service Environment, remember the isolation, which we discussed above?

I am going to create the new VNET, using RM mode of deployment, just to highlight the enhancement which the Azure team recently added i.e. ASEs can be created with ARM VNETs.

If you have pre-existing VNETs before, which are already compliant with your organization’s policies and governance or VNETs already configured with the express route setup, then in this case, you can go ahead and use the pre-existing VNET (no matter if it is created with ASM or ARM mode of deployment) to create your App Service Environment.

For this demo, I am going to create the new ARM VNET from scratch, shown below:

It will take a few seconds. Afterwards, you hit create and spin up a brand new VNET in selected resource group.

Once this is done, let’s create the ASE by clicking Add in the resource group and searching for App Service Environment.

Now, let’s pay attention to few of the details, which are asked during the creation of ASE.

• Name – The name of your App Service Environment.
• Subscription – Select the subscription, under which you want to create your ASE.
• Resource Group – Select the correct RG, under which your ASE will be provisioned. 

Now, the most important component in ASE architecture is the VNET.

Select the VNET, which we just created in the previous step. As of now, you won’t get any option to create new ARM VNET from the UI. It creates classic VNET i.e. v1 VNET.

Once you select the VNET, default subnet is selected. You can change / create new, if you wish to.

The VNET configuration

As the fundamental idea behind the provisioning ASE is scalability and security in terms of isolation, all your apps will be provisioned inside a VNET.

Now to access these apps, the incoming traffic will be allowed through the VIP. This means that the domain names of your apps will be public. You can optionally choose to set up Network security gateway (NSG) to control the inbound and outbound requests.

In a nutshell, it looks, as shown below:

Above is the scenario when you choose to select the VIP Type as “External”.



But what if there are certain LOB Applications, which you wish to bring into the ASE but wish to keep them isolated from the internet? The ILB ASE is a way to go in such scenarios.

ILB ASE

ILB ASE is another way of provisioning App Service Environments, wherein apps inside your ASE will be in complete isolation and can be accessed only via your VNET, either by using site to site VPN or by using express route connectivity.

The creation process remains very much the same except the part where you select your VIP type.

For provision ILB ASE – all you need to do is select the VIP type as “Internal” and provide your own domain or subdomain along with the security certificate, which will be used for Https.



The next part of configuration for ASE is selection of scale

This is segregated into the two sections, namely: 

• Front end pools
• Worker pools 

Front end pools consist of the Servers / resources responsible for handling app connections and worker pool resources are tasked up with the execution of app code.

Thus, if you have your Applications with high incoming load and comparatively less computing requirements, you might want to scale up your front end worker pools and when your computing requirements are higher than the incoming load, scale up worker pools with the high capacity workers.

Once you provision your ASE, you are free to update the compute sizes of your Web and the worker pool resources.

Please note, that it takes around 2 hours to provision the new App Service Environment. Thus, you might want to plan your deployments accordingly.