2. App Service

resources

Overview

Web is deployed to the sk-app-web-primary-dev and sk-app-web-secondary-dev Web App resources. Each of them is in a different region. Since an App Service Plan cannot run Web Apps in different regions, each Web App resource has its own App Service Plan. Web instances are configured as endpoints of the sk-traf-dev Traffic Manager using a Performance routing method. In order to support this integration, the App Service plans running the Web instances were configured with a Standard pricing tier. Additionally, sk-app-web-primary-dev has a sk-app-web-primary-dev/staging deployment slot.

Public Api is deployed to a Web App resource running in its own App Service Plan (Standard) with autoscale rules configured. This allows it to scale independently of the Web instances. It has the necessary CORS configuration to support using the Blazor Admin panel from both the Web instance URLs and the Traffic Manager Url

All Web and Public API instances run with an in-memory Database.

Web is deployed to sk-app-web-primary-dev and sk-app-web-secondary-dev

Resources are defined using Bicep and provisioned with Azure Developer CLI. This proved to be an important tool for reducing costs because it allows to quickly provision the whole environment, deploy all apps and then tear it down.

Relevant changes can be found here See Code Changes

Public API autoscaling

The Public API runs in a separate App Service Plan that has scaling rules.

If Average CPU Percentage goes above 70% => increase instances by one
If Average CPU Percentage goes below 30% => decrease instances by one

In order to test the scaling it was necessary to somehow generate load for the Public API. As suggested in the task I used a k6 script with 1000 VUs that send requests to /api/catalog-items over 15 minutes

The scaling rules were triggered successfully and the Public API was scaled out to the maximum of 3 instances After the k6 script finished execution it was scaled in to 1 instance.

api-autoscale-setting-run-history

autoscale-plan-cpu-percentage

Web with Deployment Slots

sk-app-web-primary-dev supports a staging deployment slot.

To test it I modified the text in the footer in _Layout.cshtml to contain [Beta]

        <footer class="esh-app-footer footer">
            <div class="container">
                <article class="row">
                    <section class="col-sm-6"></section>
                    <section class="col-sm-6">
                        <div class="esh-app-footer-text hidden-xs"> e-ShopOnWeb [Beta]. All rights reserved </div>
                    </section>
                </article>
            </div>
        </footer>

Deployed the modified version to the Staging slot

// Prepare a zip with the new version of Web
dotnet publish ./src/Web/Web.csproj -o ./publish/
cd ./publish 
zip -r web.zip *

// Deploy to the staging slot via zip deploy
az webapp deployment source config-zip --resource-group eShopOnWeb-rg-dev --name sk-app-web-primary-dev --src ./publish/web.zip --slot staging

change-deployed-to-staging-slot

Then swapped it with the production slot

// Swap staging and production
az webapp deployment slot swap --resource-group eShopOnWeb-rg-dev --name sk-app-web-primary-dev --slot staging --target-slot production

staging-slot-swapped

Resources

sk-traf-dev

Traffic Manager resource Bicep definition

sk-traf-dev - Overview

sk-traf-dev Configuration

sk-traf-dev - Endpoint sk-app-web-primary-dev

sk-traf-dev - Endpoint sk-app-web-secondary-dev

sk-app-web-primary-dev

Web App resource running Web in the primary region. It is hosted within the plan-web-primary-dev App Service Plan. Supports a staging deployment slot. Bicep definition

sk-app-web-primary-dev - Overview