Part 1: Azure Stack – App Service High Level Overview

Ahoy there folks! Since my last GUIDE, I’ve managed to get a little hands-on time with the App Service RP. It’s changed a fair bit since I last looked at it, so I’ve decided to go through a few of my learnings, this will be fairly high level and is really geared toward giving a little context before we go and scale up a Worker tier in Part 2 of the guide.

Let’s crack on.

App Service Overview

The first thing you’ll want to do is log into https://adminportal.local.azurestack.external as a Global Admin

Now let’s have a look at the App Service, from the dashboard:

• Select “More Services”, then “App Service”

Roles

Let’s have a look at the roles provisioned during the RP deployment:

Here’s table giving a quick overview of each roles purpose:

App Service Role	Purpose
Controller	This VM manages and maintains the health of your ASDK App Service cloud. You can log onto this VM and fire up the "Web Cloud Management Console" to view various details about your App Service deployment (Screenshot A)
Management Server	This VM manages the ARM and API endpoints, portal extensions (Admin, Tenant and Functions portal) and the data service.
Front End	This VM routes requests to the App Service web workers depending on their availability.
Publisher	This VM is responsible for managing publishing content via FTP and web deployment and as such only handles FTP/FTPS traffic.
Web Worker (Small, Medium and Large)	These VMs are dedicated (to a tenant) worker roles for hosting tenant web or API applications.
Web Worker (Shared)	This VM provides the same as above but is shared between tenants, it's also a requirement for providing compute for Azure Functions for those using Consumption Plans (See Subscription Quotas section below)
File Server	In the latest version of the ASDK, this is a requirement. This VM houses all of the content and app files for user web sites.

Screenshot A

Worker Tiers

Next, let’s have a look at the “Worker Tiers” blade:

This blade provides you with the following useful information:

• Worker Tiers created
• Size of VM that is/will be deployed
• Image used when creating worker roles within the given tier
• Worker roles within a tier that are available for use and the total number of roles deployed in the tier
• The current “State” of the Worker Tier

By default, the App Service RP deployment should have provisioned a single “Shared” Worker role in the “Shared Worker Tier” only. You should also see a “Small”, “Medium” and “Large” Worker Tier with no “Worker Roles” currently deployed. The reason these show despite having no roles deployed into them is because the App Service deployment created “VM Scale Sets” for them, this will allow for easy deployment of these roles but we’ll pick that up in Part 2…nice!

SKUs

As you can imagine, SKUs are where you can control the features, quotas and site resources available the “Worker Tiers” you create.

This blade provides you with the following useful information:

• Created SKUs and their current state – Enabled or Disabled
• The “Family” the SKU belongs to, configured at the point of SKU creation and denoted by a single upper case letter
• The “Mode” the SKU operates in, this is configured at the point of SKU creation and is either “Shared” or “Dedicated”
• How many “Worker Tiers” are currently associated with a SKU

The screenshot below shows some of the configurable options within the SKU “Features” blade…there is a lot going on there:

The screenshot below shows some of the configurable “Quotas” within a SKU, you can also choose what action to take when one of these Quotas is “Exceeded”.

Pricing Tiers

Not a whole lot to go over in this blade, it’s where you’ll be able to assign an estimated monthly cost to your “SKUs” and their associated “Worker Tier” in a production environment.

Subscription Quotas

Another fairly straightforward blade here, it allows you to create Quotas for your App Service. When creating a new plan and adding Microsoft.Web (The App Service) as an available service, you can specify one of the Quotas from this blade, that Quota will then apply to each user subscription attached to that plan.

NOTE:  “Consumption Plan Enabled” in the above screenshot relates to Azure Functions. You can find out more about the different Functions models HERE, but it’s basically the difference between consuming from dedicated web workers which are running all the time, or being charged for what you use and making use of the shared web workers for it. I do suggest you look at the above link for more information if you’re interested though.

Custom Software

I really like this feature! It lets you create a new “Custom Software” object which you can then attach to a “Worker Tier”. This piece of software will then be installed on any new Worker Roles that are deployed into that tier. Here is a list of information required when creating a new “Custom Software” object:

• Product ID – Specified by user
• Installer Type – Select from MSI, ZIP, EXE and DLL
• URI to software installer – This would be a location on the file server deployed with the App Service
• Install Arguments – An example of an install argument for a .MSI would be /q for supressing the UI

NOTE:  Software “Title” and “Version” number will be populated automatically when pulled in from the installer.

As I stated at the top of this post, this content is meant to give a little context to the App Service so we can carry on into part two where we’re going to scale up an existing “Web Worker Tier”. Hope you see you in Part 2