The App Service Resource Provider in Azure Stack offers the same deployment and management experience for Web, Mobile, and API apps as is available in Public Azure, while also extending the provider with capabilities which are unique to Azure Stack.
In addition to the expected Azure consistent capabilities, the App Service in Azure Stack allows customisation of shared and dedicated web worker VMs which host tenant applications, as well as the associated pricing SKUs, in order to most efficiently meet the needs of on-premises and hosted customers, both computationally and financially.
Azure Stack administrators can deploy multiple shared worker instances, and define and deploy multiple different tiers of worker which do not exist in Public Azure. Different worker instances can have different core and memory counts, different operating systems, and custom software available.
The ability to deploy custom software is unique to Azure Stack and is not available within Public Azure, where you are limited to pre-defined options. Custom software can be made available for deployment via MSI, Zip, Exe, or DLL, and is packaged for consumption within custom worker tiers.
In true PaaS fashion, these capabilities and the underlying compute resources are abstracted away from tenants and presented as easy to digest SKUs, which are again fully customisable to an Azure Stack admin’s customer requirements.
Notes from Testing in Azure Stack TP2 Refresh 1
Hardware in operation:
Dell R630 13G Server
2x 10 Core E5-2650 Processors
2x 800GB SSD, 6x 1.2TB 15k HDD
Deployment of Web Workers
One of the ten Web Workers (WW3) took significantly longer than the others to deploy – around 25 minutes extra, which is probably not an issue but just noting it for rigour The first nine VMs deployed in 45 minutes, with WW3 finishing after 70 minutes.
Specs for a Large Web Worker are 4 Core, 4 GB RAM, however all Large Web Workers deployed at Shared instance specs of 1 Core, 1.75GB RAM. This repeated when deploying a custom Web Worker of 8 Cores, 8GB RAM. All Web Workers in TP2 Refresh 1 deploy at Shared tier spec for now it seems.
Repair of all roles works as expected, other than on the controller instance which fails with the following error:
Deployment of a WebApp
Most WebApp deployments succeed as expected, however there are instances where it has failed.
Two thoughts as to why this could happen were:
Only one Instance was updating at the time, deleting it to bring all Instances to a Ready state had no impact, the deployment still failed.
The Admin portal reports that none of the Instances have any running sites on them, which should make them available for placement…
… however, there are in fact currently two webapps deployed in the Dedicated Large tier, and another in the Shared tier, and not a single instance is reporting any WebApps deployed into them.
Conclusion: The Admin Portal does not accurately report the number of running WebApps in an instance yet, and all of the dedicated instances were indeed in use at this time.
Backup of WebApp
When configuring the Storage for backup of a WebApp, I accidentally left the storage endpoint as core.windows.net rather than specifying the local Azure Stack endpoint. This naturally caused the backup to fail. After correcting the issue, backups still failed for ~10 minutes as it believed an existing backup is in progress.
Once the infrastructure timed out the initial backup, subsequent backups to Azure Stack storage were able to proceed as expected, and completed successfully.
Scale Up of an App Service Plan
Initial testing of Scale Up of an App Service Plan failed with a non-specific error.
Deploying a new WebApp and testing scale up of it worked as expected, so cause of the initial failure is currently unknown.
Scale Out of an App Service
Initial test of Scale Out of an App Service fails with an error ‘Failed to save scale settings’.
As with Scale Up, creating a new WebApp resolved this as well and Scale Out reported as completing successfully.
All other tests/integrations currently tried worked as expected. For completeness, these are:
Deploy an existing Web App into App Service