Create and Use Azure App Service

You’ve built apps, containerized them, maybe even pushed images to a registry — but now you face the real question: how do I get this thing on the internet without babysitting a VM at 3 a.m.? That’s the pain this lesson kills. Azure App Service is a fully managed platform for hosting web apps, REST APIs, and background jobs — you deploy your code, Azure handles the servers, patching, load balancing, and TLS. By the end of this lesson, you’ll create an App Service plan, deploy a sample Python app, and know exactly when App Service beats other Azure hosting options.

The problem this lesson solves

Every developer hits the same wall: you’ve written clean code, tested it locally, but now you need to put it on the internet. The old way — rent a VM, install the OS, run apt-get update, configure Nginx, manage SSL certs, and pray the instance doesn’t die — is slow, error-prone, and eats hours of your week. You don’t want to be a sysadmin; you want to ship features.

Azure App Service solves this by abstracting away the server. You don’t see the VM, the OS, or the web server. You provide your code (or a container), and Azure runs it on a managed infrastructure that automatically scales, patches, and load balances. It’s the difference between buying a car engine and driving a car.

Pro tip: App Service is perfect for production web apps and APIs that don’t need fine-grained control over the OS. If you need custom kernel modules or low-level networking, you’re back to VMs or Azure Kubernetes Service.

The real pain points this lesson addresses:

• Time waste — spinning up and maintaining a VM takes hours; App Service takes minutes.
• Scaling anxiety — App Service supports auto-scaling based on CPU, memory, or HTTP traffic.
• Deployment complexity — App Service integrates with GitHub Actions, Azure DevOps, and even local Git pushes.
• Cost surprises — App Service has a free tier, so you can learn without burning money.

Core concept / mental model

Think of App Service as a managed web server with a control plane. You define three things:

1. App Service plan — the capacity you pay for (compute, RAM, scaling). It’s the “engine.”
2. App Service (the web app) — the container for your code. It’s the “car body.”
3. Deployment slot — a staging area to test before swapping to production (optional but powerful).

A mental picture: The plan is like renting a plot of land; the app is the building you put on it; deployment slots are extra building levels you can test before making them the main entrance.

Key definitions:

• App Service plan: A set of virtual machines (or serverless units) that host one or more apps. You pay for the plan, not per app.
• Web App: The actual running instance of your application (Python, Node, .NET, etc.).
• Deployment: The act of pushing your code or container to the Web App — from Git, ZIP, container registry, or local workspace.
• Scaling: The plan’s ability to add/remove instances based on load. Manual or automatic.

Why not just a VM?

The mental model boils down to: App Service = serverless-ish web hosting with full HTTP/HTTPS support, minus the cold-start latency of Azure Functions.

How it works step by step

The flow to create and use an App Service in Azure is logically sequence:

1. Create a resource group — a logical container for all your related Azure resources.
2. Create an App Service plan — choose the tier (Free, Basic, Standard, Premium) and region.
3. Create the Web App — attach it to the plan, pick the runtime (Python 3.12, Node, etc.), and deployment method.
4. Deploy your code — via GitHub, local Git, ZIP, or container.
5. Access the app — get the default URL (https://<app-name>.azurewebsites.net).
6. Scale or configure — modify plan tiers, add custom domains (optional), enable diagnostics.

Each step causes the next: the plan defines compute limits; the app runs inside that plan; deployment updates the app’s code; the URL exposes it.

Under the hood: Azure App Service runs your app in a sandboxed environment. For Linux apps, it runs in a Docker container with your chosen runtime. The platform handles OS patches, reboots, and health checks — if your app crashes, Kudu (the deployment engine) restarts it (with limits).

Hands-on walkthrough

We’ll use the Azure CLI (or Cloud Shell) — no GUI needed. Prerequisites: an Azure subscription (you can start free) and the az CLI installed.

Step 1 — Login and create a resource group

# Login (opens browser or uses device code)
az login

# Create a resource group in a region near you
az group create --name ryan-appsvc-rg --location eastus

Output (abridged):

{
  "id": "/subscriptions/.../resourceGroups/ryan-appsvc-rg",
  "location": "eastus",
  "name": "ryan-appsvc-rg",
  "type": "Microsoft.Resources/resourceGroups"
}

Step 2 — Create the App Service plan

az appservice plan create \
  --name my-cool-plan \
  --resource-group ryan-appsvc-rg \
  --sku B1 \
  --is-linux

• --sku B1 = Basic tier (supports custom domains, small scale).
• --is-linux = runs Linux containers. Skip for Windows.

Output shows provisioningState: Succeeded.

Step 3 — Create the Web App

az webapp create \
  --name my-unique-python-app \
  --resource-group ryan-appsvc-rg \
  --plan my-cool-plan \
  --runtime "PYTHON:3.12" \
  --deployment-local-git

Note: App name must be globally unique (used in the URL). --deployment-local-git enables Git push deployments.

Output includes defaultHostName: https://my-unique-python-app.azurewebsites.net.

Step 4 — Deploy a simple Python app

Create a local folder with these files:

app.py

from flask import Flask
import os

app = Flask(__name__)

@app.route('/')
def home():
    return '<h1>Hello from Azure App Service!</h1>'

if __name__ == '__main__':
    port = int(os.environ.get('PORT', 8000))
    app.run(host='0.0.0.0', port=port)

requirements.txt

flask==3.0.*

Deploy via Git

# Initialize a repo and commit
git init
git add .
git commit -m "Initial commit"

# Add Azure remote (URL from output)
git remote add azure https://<username>@my-unique-python-app.scm.azurewebsites.net/my-unique-python-app.git

# Push to deploy
git push azure main

During the push, Azure detects the Python app, runs pip install -r requirements.txt, and starts the server. You’ll see logs like Deployment successful.

Step 5 — Verify it works

Open the URL in a browser: https://my-unique-python-app.azurewebsites.net. You should see “Hello from Azure App Service!”

Pro tip: If you see the default Azure page, your deployment didn’t trigger. Check the log stream: az webapp log tail --name my-unique-python-app --resource-group ryan-appsvc-rg.

Compare options / when to choose what

App Service is one of several Azure hosting choices. Use the table to decide:

When to choose App Service:

• You need a reliable web app or REST API with minimal ops.
• You want to scale up/down without rewriting your app.
• You already use Git and want CI/CD built in.

When to avoid:

• You need to control the underlying OS or install custom system packages.
• You need long-running background tasks that exceed App Service’s time limits (use Azure Functions or a VM).
• You have a complex microservices architecture — AKS is better.

Variations worth knowing:

• Deployment slots: Create a staging slot, deploy there, test, then swap with production — zero downtime.
• Container deployment: If your app is already a Docker image, deploy directly to App Service (Linux plans only).
• GitHub Actions: Automate deployments every time you push to your repo — more robust than Git push.

Troubleshooting & edge cases

1. App returns default Azure page after deployment

• Cause: The deployment didn’t complete, or the app didn’t restart.
• Fix: Check the deployment status: az webapp deployment list-published-profile .... Also ensure your code is in the root, not a subfolder.

2. 502 Bad Gateway

• Cause: The app crashed or is listening on the wrong port.
• Fix: Ensure your app reads the PORT environment variable (Azure sets it) and binds to 0.0.0.0. For Flask, use port=int(os.environ.get('PORT', 8000)).

3. Deployment succeeds but app uses old code

• Cause: App Service caches. Sometimes you need to restart the app.
• Fix: Run az webapp restart --name <app> --resource-group <rg>.

4. Internal Server Error (500)

• Cause: Python dependency missing or syntax error.
• Fix: Check the logs: az webapp log tail. Also, ensure requirements.txt is in the root.

5. Out of memory (OOM) on free tier

• Cause: Free tier has limited RAM (1 GB).
• Fix: Upgrade to a paid tier or optimize your app (e.g., use a lighter web framework).

6. App doesn’t start because of missing startup command

• Cause: For custom containers, you need a startup command.
• Fix: Set az webapp config set --resource-group <rg> --name <app> --startup-file "gunicorn app:app".

Pro tip: Always check the log stream first. It shows real-time stdout/stderr and deployment errors.

What you learned & what's next

You now know the core concept behind Create and use Azure App Service — you can explain its role as a managed web host, its relationship with App Service plans, and its place among Azure hosting options. You also completed a practical exercise: you created a resource group, an App Service plan, a Web App, and deployed a Python app via Git — then verified it live.

Key takeaways:

• App Service is fully managed — you don’t patch servers.
• The plan is the compute billing unit; the app is your code.
• Deployment is as easy as git push — CI/CD friendly.
• Use deployment slots for zero-downtime updates.
• Free tier exists — perfect for learning.

What’s next: You’re ready to dive into Azure Container Apps (ACA) — they offer serverless containers with more flexibility than App Service. Compare how ACA scales to App Service, and you’ll start seeing the full container landscape. In the next lesson, you’ll build a containerized microservice and deploy it to ACA — you’ll reuse the deployment patterns you just practiced.

Continue to the next lesson in the Azure Tutorial track: Azure Container Apps orientation.