🪴 Quartz 4.0

01 - Explore Azure App Service

5 min read

Explore Azure App Service

Examine Azure App Service

Azure App Service is an HTTP-based service for hosting web applications, REST APIs, and mobile back ends. You can develop in your favorite language, be it .NET, .NET Core, Java, Ruby, Node.js, PHP, or Python. Applications run and scale with ease on both Windows and Linux-based environments.

  • Built in auto scale support
  • Continuous integration/deployment support
  • Deployment slots
    • Standard and Premium plans
    • Switch staging deployment slot with production slot
  • App Service on Linux
    • Host web apps or run custom Linux containers
    • Can’t mix with Windows
    • Not supported on shared pricing tier
    • Portal only shows features currently working for Linux

Examine Azure App Service Plans

  • Always runs in an App Service plan
  • Defines a set of compute resources for a web app to run
  • One or more apps can be configured to run on the same computing resources
  • Azure Functions can also run in an App Service plan

How Does My App Run and Scale?

In the Free and Shared tiers, an app receives CPU minutes on a shared VM instance and can’t scale out. In other tiers:

  • App runs on all VM instances
  • If multiple apps are in the same plan, they all share the same VM instances
  • If there are multiple deployment slots, all deployment slots also run on the same VM instances
  • If logging, backups, or WebJobs are enabled, they also use CPU cycles and memory on the VM instances In this way, the App Service plan is the scale unit of the App Service apps. If the plan is configured to run five VM instances, then all apps in the plan run on all five instances. If the plan is configured for autoscaling, then all apps in the plan are scaled out together based on the autoscale settings.

What if My App Needs More Capabilities or Features?

  • Can easily change the pricing tier of the plan
  • Can separate it out to its own instance
  • Can save money by putting multiple apps into one App Service plan
  • Isolate when resource intensive, want to scale independently, or needs resources in a different geographical region

Deploy to App Service

Automated Deployment

Continuous integration is a process to push out features and bug fixes quickly with minimal impact. Supported through Azure DevOps, GitHub, or Bitbucket.

Manual Deployment

  • Git: pushing to remote will deploy your app
  • CLI: using the CLI, webapp up can package app and deploy, or create a new one
  • Zip deploy: uses curl or similar to send zip of app files to App Service
  • FTP/S: traditional way of pushing code to many hosting environments Use deployment slots whenever possible, as you can deploy to staging environment then swap staging and production for minimal downtime.

Explore Authentication and Authorization in App Service

App Service comes with its own authentication and authorization, that you can use if you choose to. Can be integrated with other identity providers, and it comes built in without requiring any prior knowledge or code. The authentication and authorization module runs in the same sandbox as your application code. When it’s enabled, every incoming HTTP request passes through it before being handled by your application code. It authenticates, manages token and session, and inject identity information into the request headers. The authentication flow differs based on with or without provider SDK. Without, server-directed flow is managed through the App Service on the server side. With, the application submits the authentication token to App Service for validation. The application code manages the side in process, called client-directed flow. This generally applies to browser-less apps, REST APIs, Azure Functions, and mobile apps. For authorization behavior, you can choose to allow unauthenticated requests which defers authorization of unauthenticated traffic to application code. Otherwise, you can require authentication which will reject any unauthenticated traffic to the application. It can also redirect to the identity provider or else returns a 401 or 403.

Discover App Service Networking Features

Multitenant App Service Networking Features

Azure App Service is a distributed system. The roles that handle incoming HTTP or HTTPS requests are called front ends. The roles that host the customer workload are called workers. All the roles in an App Service deployment exist in a multitenant network.

Inbound featuresOutbound features
App-assigned addressHybrid Connections
Access restrictionsGateway-required VNet Integration
Service endpointsVNet Integration
Private endpoints-

Default Networking Behavior

Azure App Service scale units support many customers in each deployment. The Free and Shared SKU plans host customer workloads on multitenant workers. The Basic and higher plans host customer workloads that are dedicated to only one App Service plan. If you have a Standard App Service plan, all the apps in that plan will run on the same worker. If you scale out the worker, all the apps in that App Service plan will be replicated on a new worker for each instance in your App Service plan.

Outbound Addresses

The worker VMs are broken down in large part by the App Service plans. The Free, Shared, Basic, Standard, and Premium plans all use the same worker VM type. The PremiumV2 plan uses another VM type. PremiumV3 uses yet another VM type.

Find Outbound IPs

To find the outbound IP addresses currently used by your app in the Azure portal, click Properties in your app’s left-hand navigation. To see it through the cloud shell, you can use

az webapp show \
    --resource-group <group_name> \
    --name <app_name> \ 
    --query outboundIpAddresses \
    --output tsv

To find all possible outbound IP addresses for your app, regardless of pricing tiers

az webapp show \
    --resource-group <group_name> \ 
    --name <app_name> \ 
    --query possibleOutboundIpAddresses \
    --output tsv

Graph View

Backlinks