Recently
I was asked by a client: how do I deploy an API App or a Logic App to a Virtual Network
(VNet)?
If
you’ve ever used BizTalk Services (MABS) then you’ll know one of the biggest limitations
with MABS was that it didn’t support VNets: a lot of companies create VNets, and hook
them up to their on-premises network, so that their Azure environment becomes a secure
extension of their on-premises network.
VNets
can also be set to only allow trusted connections from external users through the
use of firewalls, network appliances or network configuration.
At
the date of writing, there is currently no support for running Logic Apps in a VNet
(yet, but watch this space) but there is for the other parts of Azure App Service
(AAS): the problem is solved through the use of App Service Environments (ASEs).
Introduction
to App Service Environments (ASEs)
ASEs
have been around for a while (they previewed in April 2015, just after AAS went into
preview, and Logic Apps/API Apps were announced) but there hasn’t been too much coverage
of them, hence my client’s question. ASEs are part of Azure App Service.
An
ASE is effectively a private deployment of all the VMs and services needed to run
your AAS apps. Instead of running on either shared VMs (Free and Standard Plans) or
dedicated VMs in the public portions of your subscription, ASEs give an entire deployment
of everything needed to host AAS apps but in a VNet – with the added benefit that
you get a lot of control over the scale up/scale out options.
When
you create an ASE it *has* to exist in a VNet: you can’t create one outside of a VNet.
The VNet is either created for you (with default values) or you can select a pre-existing
VNet when you create the ASE.
Configuration
of an ASE can look a bit daunting, but it becomes easier if you think of it as your
own set of virtual servers, with a set of front-end servers and 3 groups of processing
servers running in your VNet. All of the supported AAS goodies (web apps, api apps,
etc.) are deployed onto these servers, and you get to control the number of servers
available to handle load.
Servers
are grouped into either Front-End, Worker
Pool 1, Worker
Pool 2,
or Worker
Pool 3.
You
can set the number of instances per group – so the default is for a front-end group
with 2 servers, and single worker pool group with 2 servers, plus one allocated IP
address. Note that these aren’t the actual number of instances assigned to your API
App (or Web or Mobile) when you deploy it – this is the just the number of instances
that exist in the group that can be used. When you deploy your AAS app, you choose
which group it uses.
In
ASE terminology, each group is known as a pool, and the servers as instances: so if
you want two servers running on a worker process group, you’d have two worker
pool instances running
in your worker
pool.
Technically,
each pool instance is a compute resource: you can have a maximum of 55 compute resources
spread across your front-end pool and worker pools, and a maximum of 10 IP addresses
e.g. 5 front-end instances, and 2 worker pools each with 25 instances (the Azure portal
has some pretty nifty code in it which adjusts the ratio on the sliders as you adjust
the numbers!).
ASEs
are part of the Premium tier, which means they can get expensive: even at the default
settings the per hour cost is reasonably high, even with nothing running in the ASE
and no storage. As you add more instances, or more pools, the price per day increases.
How
to create an ASE
The
option to create an ASE can be found under Web
+ Mobile,
right under the Logic
App item,
when you click New in the Azure portal:
When
you select App
Service Environment you’ll
be given the option to give it a name, select or create the Resource Group the ASE
will belong to, select or create a VNet, and choose scaling options:
On
this screen you specify:
Your
ASE name – note that your ASE is given a name on the domain p.azurewebsites.net –
you’ll have to make your ASE name unique amongst all other ASE names.
The
subscription your ASE will be created in.
The
Resource group your ASE will belong to (this can be a new one or an existing one).
The
Virtual Network/Location for your ASE (by default a new VNet is created for you, but
you either choose an existing VNet, or change the options of the default VNet that
is created).
Scalability
i.e. how many pools and pool instances you want.
Note
the information box that indicates it will take a minimum of 2 hours to create your
ASE – this is accurate, as I’ve found from experience.
Selecting
the Scale option
shows this screen:
Here
you can specify what pricing tier you want to use for your pools (each pool can be
set to a different pricing tier, although the Front
End Pool must
be at P2 at minimum).
After
this, you can set the number of instances in each pool, and how many IP Addresses
you need.
If
you select one of the tier options for a pool, you’ll see a screen like this:
What
this lets you do is set the number of cores available for each of your instances i.e.
the number of cores for each of your virtual servers.
Looking
at those numbers, and knowing the defaults for an ASE, you can see that the default
settings will cost you a minimum of £272.70/month (about US$400/mo), and that’s without
any additional storage or traffic charges.
Note:
ASEs can be expensive, but they’re in the Premium tier for a reason: they’re designed
to handle very high load (if necessary) for customers that need an isolated environment
within a virtual network e.g. 50 8-core virtual servers. Plus, there’s one thing you
can do with ASEs that is difficult to do otherwise: you can provide automated geographic
redundancy (more on this later).
After
you click the Create button,
Azure goes off and creates your ASE – this will take a minimum of 2 hours.
How
to deploy an API App to an ASE
OK,
so now you have your shiny new ASE – how do we deploy an API App to it? Well this
is the really easy part: Your ASE will show up in your list of Locations when you
create your API App (as long as you select the correct subscription).
For
example, if I create an instance of the BizTalk
Flat File Encoder,
my location happens to automatically default to the ASE I created earlier:
Note
that we now have a new option available – Worker
Pool Size.
This lets us select the worker pool to use with the API App (remember setting up Worker
Pools when you created the ASE?). You use this to select which worker pool you want
to use (i.e. Worker
Pool 1, Worker
Pool 2,
etc.).
Also,
I note that you can select an existing resource group, or create a new one, although
the facility to choose an existing one wasn’t working correctly at the time of this
post.
If
we select the Location option, we can see that the ASE appears in the list of locations:
Benefits
of deploying API Apps or Logic Apps to an ASE
The
two main benefits of an ASE are these:
Ability
to deploy to a VNet.
Ability
to scale worker instances beyond that which is available in AAS outside on an ASE.
The
VNet argument should be easy: if you have an on-premises network which you are connecting
to Azure (either by VPN or ExpressRoute or similar), then an ASE allows you to both
access your AAS apps from your on-premises servers as well as allowing your AAS apps
to access on-premises server – no hybrid connectivity or service bus relay needed!
Plus you can use network security groups to restrict traffic access to your AAS apps
on an IP level.
The
ability to scale is essential if your workload is going to go beyond the capabilities
offered by vanilla AAS: up to 55 dedicated compute resources, each with up to 8 cores.
The ability for your ASE to autoscale as demand requires it is also essential for
enterprise apps.
Why
can’t we add Logic Apps to an ASE?
When
ASEs first came out, there was a bit of confusion about whether Logic Apps and API
apps were supported: the initial announcements indicated they were, but there appeared
to be no way of adding API Apps and Logic Apps to ASEs. That has changed, with the
official guidance now updated to indicate that Web Apps, Mobile Apps, and API apps
are all supported, but not Logic Apps.
Given
that Logic Apps are still in preview, this is perhaps not surprising – and I wouldn’t
be surprised if we find Logic Apps gaining ASE support before the GA of Logic Apps
next year (perhaps even during one of the earlier updates mentioned in the Logic
Apps Roadmap).
Further
Resources
There’s
a wealth of information from Microsoft on ASEs – here’s a partial list, including
a very cool use of geographic scaling using multiple ASEs:
Introduction
to App Service Environment: https://azure.microsoft.com/en-gb/documentation/articles/app-service-app-service-environment-intro/
How
to Create an App Service Environment: https://azure.microsoft.com/en-gb/documentation/articles/app-service-web-how-to-create-an-app-service-environment/
Geo
Distributed Scale with App Service Environments: https://azure.microsoft.com/en-us/documentation/articles/app-service-app-service-environment-geo-distributed-scale/