Ever since it’s launch, Azure Websites have rightfully gained popularity due to it being truely a PaaS solution that doesn’t pull down the pants on devs that doesn’t know too much about infrastructure. I must admit that when I started to approach WebSites, my feeling about it was a bit so-and-so, but I was wrong and I’ve changed my mind drastically. It’s simply a very productive environment, especially compared to PaaS Cloud Services. Nowadays, It’s my first choice for hosting whatever I do and I only revert to IaaS VMs if I really have to.

However, WebSites had one issue that made it not break through in the enterprise space directly. It couldn’t be part of an Azure Virtual Network. Okay, you had the Point-to-Site VPN capability, but that was as effective as Hertz or Avis giving you the keys to a plastic pedal car when you atleast needed a BMW. In April/May, during Microsoft’s event mania month, the possibility of letting Azure WebSites (and I’ll switch to the new name – WebApps – now) be all-in in an Virtual Network and leverage any Site-to-Site VPN connectivity to you local on-premises datacenter emerged. Welcome to – Azure WebApps meets the Enterprise.

Azure App Service Environment

WebApps is at the far end of the PaaS abstraction level and has always meant that you don’t touch the VM that is hosting your app. The App Service Plans (prev Web Hosting Plans) had the Free and Shared options that ran your app in a truely shared and multi-tenant environment. If you needed to do some basic stuff, like uploading a SSL cert for https to work, or adding host names for a CNAME DNS to work, you had to move to the Basic or Standard plans that were a little more dedicated. The Standard plan was required if you wanted to add the P2S VPN Virtual Network capability, for instance. With an SSL cert uploaded you could almost get a reliable ip address of your website, although that isn’t really promised or documented.

The App Service Environment takes the plans to a whole new step beyond the Standard plan. It provisions an environment of VMs with the WebApp/WebSite functionality that is just dedicated for you, and you alone. I’m not going to repeat what others have written, so check the references at end for introduction blogs. I will, however, tell you how it works from a WebApps/VNet perspective.

First, think of ASE as something that just holds your WebApps (WebSites). It’s like if you previously needed to create a new Standard Hosting Plan before you could use it, ie you had to click New in the portal, or, run a powershell script like Add-AzureWebsiteHostingPlan -Name yada-yada -Type “Standard”. That is what the ASE is.

ASE Front end and Worker Pools

This can be a bit tricky at first glance, but the Worker Pools are where you app(s) are hosted. Since an ASE can host as many of your WebApps as you like to squeeze in, and since they may have different scaling requirements, the ASE comes with three different Worker Pools that you can scale independantly. It’s the IaaS equivalent of letting the web servers run on A1/D1 VMs and the database server running on something more powerful, so to speak.

Currently, you have three Worker Pools and you can decide for each of them what VM size they should have. You don’t have to use all three pools and if this is just a test ASE, you probably will only use one of them and scale the other two down to zero VMs.

The Front End pool is nothing you provision stuff to. It’s just a pool of VMs taking the first hit at terminating SSL, etc. Forget it’s even there when you start learning ASE.

My Virtual Network

In my example, I will use a Virtual Network that looks like below. The app7 subnet will be dedicated to the ASE environment and it is advisable to let an ASE have an entire subnet of its own. Don’t co-hab IaaS VMs in it. In the infra6 subnet I will provision an IIS VM and in the dcnet7 there will be an AD/DNS server. (Yes, the use of the suffixes 6 and 7 are inconsequent).

 

The IaaS VMs provisioned shows up in the VNey config page, but anything you do with ASE does not show up. Listed below are my AD/DNS server cljungadwe6 and my IIS VM cljungwswe6. The DNS for the VNet is 10.6.3.4, ie the AD/DNS server.

If you decide to give ASE a spin, make sure you get all this configured before you create the ASE, since ASE is in preview and don’t pick up changes in your VNet config too often.

Creating the App Service Environment

When you create the ASE you will get that chance to point it to an existing VNet/Subnet. You can not have multiple ASEs in one subnet, so make sure you don’t reuse your subnets. Once you press the Create button, Azure will start spinning up the number of VMs you selected for your Worker and Front End Pools. During this provisioning, the VMs will grab info from the VNet, like DNS, so that’s why it’s important that all that is in place before you press create. Also, if your app is layered and requires network segmenting, you will be needing 2 or more ASEs and you will probably need Network Security Groups (NSG) to allow/deny network traffic between the subnets. I will not do this in this post.

Deploy your WebApp

The ASE takes currently almost an hour to provision and you just have to wait for it to complete. When it’s done, you can deploy your webapp just like you did previously with Azure WebSites – but with one major difference! You have to create the WepApp (WebSite) inside the new portal (portal.azure.com) and attach it to the ASE. It’s that way the WebApp understands that it’s hosting plan isn’t Free, Shared, Basic or Standard. “Attach” is probably the wrong word. What you really do is find the ASE you created under the selection of Location, so instead of selecting West Europe, etc, you select the ASE as the provisioning Location.

I have a powershell script that takes a web deployment package zip file and deploys it to a WebSite and that is how I deployed my little debug website below.

What this page does is just checking the environment and making a couple of web calls. The Request sent from IP is just the REMOTE_HOST in the request header so I can see where the browser request comes from. The Internal Server Ip addr is just an enumeration of the IPv4 addresses found on the web servers local NIC(s). Here you can see that the webapp inside a ASE only can find the loopback ip address.

The Outgoing traffic from IP is determind by making a outgoing web request to checkip.dyndns.com and parsing the result. This is handy to determind the webapps external VIP.

The VNet internal traffic from IP is determind from making a web request to the IIS VM on it’s internal VNet ip address. Since both the IIS VM and the WebApp should be in the same VNet, although in different subnets, this call should work. It also tells us that the ip address the webapp has in the VNet is 10.6.1.8 (The IIS VM checks it’s REMOTE_HOST and returns that in the http response).

Lastly, the DNS Servers shows us that the DNS server the webapp is using is the one that was configured in the VNet. This means that the webapp is a member of the VNet and could use the name resolution of your enterprise.

To prove this, I let the webapp do the internal VNet call using a name only the AD/DNS server 10.6.3.4 would be able to resolve. The AD domain in my demo was named yabbadabbadoo.local and the webapp was able to make a call using the name cljungwswe6.yabbadabbadoo.local. If your DNS infrastructure in your VNet is connected via a VPN gateway back to on-premises, this would mean that the code running in the webapp would be able to access resources in your local on-premises datacenter. Azure WebApps meets the enterprise.

One thing you still can’t do with your WebApp is making it and intranet only website, since it’s not possible to browse to it using the VNet ip adress, like 10.6.1.8 above.

 

References

MSDN – Introduction to ASE
https://azure.microsoft.com/en-us/documentation/articles/app-service-app-service-environment-intro/

MSDN – How to Create a WebApp in ASE
https://azure.microsoft.com/en-us/documentation/articles/app-service-web-how-to-create-a-web-app-in-an-ase/

//Build – Program Manager Yochay Kiriaty explains ASE
http://channel9.msdn.com/Events/Build/2015/2-633

Ignite – Program Manager Stefan Schakow explains ASE
https://channel9.msdn.com/Events/Ignite/2015/BRK3715