What Is App Service Environment?

In this post, I will explain how you can run Azure App Services in an isolated or virtual network-connected deployment and why, despite the price, it was the right choice for some projects I’ve been working on.
 

 

Normal App Services

When you deploy an app services plan (a set of under-the-cover virtual machines) to host one or more app services in the Free, Shared, Basic, Standard, or Premium Tiers, then the infrastructure that your app services are deployed into are multi-tenant. This means that the virtual machines that make up your app services plan are in a shared pool. Those virtual machines might be dedicated to you, but they come from a shared environment. A set of transparent and hidden front-end servers (offering the load balancing functionality) are shared between all of the tenants (customers) using the virtual machines in this app services environment. And finally, because you are in a multi-tenant environment, the app service plan is not connected directly to a virtual network. Although, you can connect your app services to a virtual network via a P2V VPN connection and use this to route externally via a site-to-site VPN connection.
The goal of app services is to make things easy for you. But easy means making some small compromises. For a small number of customers, these compromises are too much. And it is because of this, that Microsoft launched the Isolated tier app services plan, which allows you to deploy your own app services environment (ASE).

App Services Environment (ASE)

The term ASE is normally used to describe a customer’s deployment of the isolated tier app services plan, but it’s something that I have also heard Microsoft use to describe the hidden pieces of the other tiers. Typically, if you hear ASE, then it’s a reference to the Isolated tier.
In short, the Isolated tier app services plan must be deployed into an ASE. The ASE provides a single customer with a completely private deployment of app services. There are a few traits to this:

• Privacy: The customer has a completely private, single-tenant deployment, offering them total control over Internet connectivity, security and compliance.
• Virtual Network: The virtual machines of the app services plan are connected to a virtual network. This allows for some interesting architectural possibilities, which have caused me to recommend ASE twice in recent weeks. I originally thought that I’d never recommend an Isolated tier because of the cost but I was wrong.
• Deployment: There are two deployment types; you can publish an ASE using a public IP address (the same as many other IaaS components in Azure) or using an internal Azure Load Balancer.

IaaS

As several other parts of the Azure PaaS catalogue, ASE is built on IaaS components. One will have to understand virtual networks, IP addresses, load balancers, Network Security Groups, and more. This is more evidence that, even with an advanced PaaS deployment,  the future career of IT pros (that are willing to do continuous re-learning) are secure. Although, “disk monkeys” are probably still at great risk.

External ASE

The first type of ASE deployment is an external ASE, using a PIP to make the web apps available to the Internet using a public IP (PIP) address. The first benefit of this approach is that you get a single-tenant (you) ASE but it’s still on the Internet. The second benefit of this approach is that the instances of the app service plan(s) that you deploy in the ASE are connected to a virtual network, just like virtual machines. Now some interesting architectural possibilities arise (more on this later).

Internal ASE

The second type of ASE is an internal deployment, where the ASE is shared to the virtual network via an internal Azure load balancer with a private IP address from the virtual network. Note that with this deployment type, you have sole responsibility for managing the DNS of the app services.
It is up to you if you deploy the app service(s) on the Internet or not, and if you do, how you accomplish it. There are plenty of interesting ways to share a private IP address to the Internet in Azure, including the web application gateway, third-party firewall appliances, and more. The architectural possibilities are interesting!

Virtual Network Connectivity

The reason that ASE has popped up, unexpectedly, in proposals that I have written, is the connectivity to virtual networks. Don’t get me wrong, a more traditional app service plan does offer network connectivity:

• Hybrid Network Connections: A secure tunnel to a TCP-based service, such as SQL Server, typically running on-premises or in another cloud.
• VPN: A point-to-site VPN connection to a virtual network using a gateway, which can route to on-premises via a site-to-site VPN.

The problem with both of those approaches is scale. In one of my proposals, the customer needed many connections to suppliers and partners without deploying any change-making software. If an ASE can be deployed into a virtual network, then a VPN gateway can enable those connections without deploying any software. The higher sizes of gateway support up to 30 site-to-site VPN tunnels.

 
The ASE also has the ability to talk directly to virtual machines on the virtual network. That works both ways. Another customer has a preference to use a certain brand of firewall for edge network security. That firewall can be run as a virtual appliance in Azure, so it can be deployed on an edge subnet in the virtual network and route to the private IP address of an internal ASE deployment (internal load balancer).
Or if a customer wishes, the ASE can be published to on-premises users via an ExpressRoute or VPN connection, with no Internet connection at all! The customer gets the cloud benefits of a PaaS deployment but with the security of an isolated installation.

Summary

When I saw the fixed cost of an ASE (~$1,043.82/month RRP in East US) plus the cost of the isolate tier instances (starting at ~$219/month RRP in East US), I thought I would never deploy ASE. However, when we compared the architectural, technical, and operational (developer) benefits with the alternatives, ASE with the Isolated app services tier was a no-brainer.