Azure Fundamentals for Web Hosting: Hosting with Azure App Service (plans, runtimes, deployment slots)

What Azure App Service Provides for Web Hosting

Azure App Service is a managed hosting platform for web apps and APIs. You deploy your code, choose a runtime (for example .NET, Node.js, Python, Java, PHP), and Azure runs it with built-in features such as TLS/HTTPS, scaling options, deployment slots, and integration with CI/CD tools. The key design idea is that your app runs inside an App Service Plan, which defines the compute resources and pricing tier.

App Service vs. App Service Plan (the relationship)

• App Service (Web App): the application resource (hostname, runtime configuration, app settings, deployment configuration).
• App Service Plan: the underlying compute (CPU/RAM), scaling capabilities, and pricing tier. Multiple web apps can share one plan (and therefore share the plan’s compute resources).

Step-by-Step Build: Create an App Service Plan and Web App

Step 1: Create the App Service Plan

In the Azure portal, create an App Service Plan first (or create it during web app creation). The plan choice affects cost and features, so decide it intentionally.

• Go to Create a resource → search App Service Plan (or create a Web App and create a new plan inline).
• Choose Operating System: Windows or Linux (match your runtime and deployment expectations).
• Choose Region: pick the same region you want your app to run in.
• Choose a Pricing tier (plan size). Start small for dev/test, then scale up when needed.

Understanding plan sizing and pricing tiers (practical guidance)

App Service Plan tiers differ by performance, scaling, and features. The exact names can vary slightly over time, but the practical decision points are consistent:

• Free/Shared: for experiments and demos. Limited resources and features. Not recommended for production.
• Basic: dedicated compute, suitable for small workloads. Limited scaling features.
• Standard: production-friendly baseline; supports features like deployment slots (commonly) and more scaling options.
• Premium: higher performance, more instances, advanced features, better for heavier traffic and stricter requirements.

Key sizing concepts:

• Scale up = choose a bigger SKU (more CPU/RAM per instance).
• Scale out = increase instance count (more servers running your app).
• Cost model: you pay for the plan’s running instances, not per-deployment. If you host multiple apps in one plan, they share the plan’s cost and capacity.

Rule of thumb: If you need safe releases with staging, plan for a tier that supports deployment slots. If you need predictable performance, avoid Free/Shared for anything beyond demos.

Continue in our app.

You can listen to the audiobook with the screen off, receive a free certificate for this course, and also have access to 5,000 other free online courses.

Or continue reading below...

Download the app

Step 2: Create the Web App (App Service)

Now create the web app that will run on the plan.

• Go to Create a resource → Web App.
• Set Name (this becomes part of the default hostname: https://<name>.azurewebsites.net).
• Select Publish: Code (typical) or Docker Container (not the focus here).
• Select Runtime stack (for example: .NET, Node, Python, Java, PHP) and Version.
• Select Operating System (Windows/Linux) consistent with your runtime choice.
• Select the App Service Plan you created.
• Create the resource and wait for deployment to finish.

Selecting Runtime Stacks (and Why It Matters)

The runtime stack determines how Azure starts your application and what language runtime is available. A mismatch between your app and the runtime is one of the most common first-deploy failures.

Examples of correct runtime alignment

• .NET: Choose the matching .NET version. For Linux, you typically deploy a compiled app and Azure runs it with the selected runtime.
• Node.js: Choose a Node version compatible with your app. Ensure your app defines a start script (often via package.json).
• Python: Choose the Python version; ensure dependencies are installed (often via requirements.txt) and the startup command is correct for your framework.
• Java: Choose Java version and server/container options as applicable.

Where to verify runtime after creation

In the Web App resource, go to Configuration (or Settings) and confirm the runtime stack/version. If you change runtime after deploying, you may need to redeploy or adjust startup settings.

Configure Application Settings and Connection Strings

App Service provides a configuration store for environment variables and connection strings. This is where you put values that differ by environment (dev/staging/prod) without hardcoding them in code.

Step-by-step: add app settings

• Open your Web App → Configuration → Application settings.
• Add a new setting (for example APP_ENV = Production).
• Click Save. App Service may restart the app to apply changes.

How your code reads these: Most frameworks read environment variables automatically. For example, Node reads process.env.MY_SETTING; .NET reads from environment-based configuration providers; Python reads from os.environ.

Step-by-step: add connection strings

• Web App → Configuration → Connection strings.
• Add a connection string name (for example DefaultConnection) and value.
• Select the type (SQL Server, PostgreSQL, MySQL, Custom) where applicable.
• Save changes.

Practical guidance: Use App Service configuration for secrets and environment-specific values. Avoid committing secrets into source control. For more advanced secret handling, you would typically integrate a secret store, but the core idea here is: keep secrets out of code and set them per environment.

Deployment Slots for Safe Releases

Deployment slots let you run multiple versions of your app under the same App Service. A common pattern is staging and production. You deploy to staging, validate, then swap staging into production with minimal downtime.

Concept: staging-to-production swap

• Production slot: the live site users access.
• Staging slot: a separate environment with its own hostname (for example https://<app>-staging.azurewebsites.net).
• Swap: Azure exchanges the two slots’ content and (optionally) selected settings, so staging becomes production.

Step-by-step: create a deployment slot

• In your Web App, go to Deployment slots.
• Click Add Slot.
• Name it staging.
• Choose whether to clone settings from production (often yes for a starting point).

Slot settings vs. swapped settings (important for safety)

Some settings should stay with the slot (for example, staging uses a test database). Mark these as slot settings so they do not swap into production.

• In Configuration, for a setting or connection string, enable the Deployment slot setting option when it must remain specific to that slot.
• Typical slot-specific items: non-production connection strings, staging-only API keys, feature flags for testing.

Step-by-step: swap staging into production

• Deploy your new version to the staging slot.
• Test staging using its slot URL.
• Go to Deployment slots → Swap.
• Select Source = staging, Target = production.
• Review which settings will swap and confirm.

Rollback approach with slots: If the swap introduces an issue, you can swap back (production ↔ staging) to quickly revert to the previous version, assuming the previous version is still in the other slot.

Common Deployment Methods

App Service supports multiple deployment approaches. Choose one based on your team workflow and automation needs.

Zip Deploy (simple and fast)

Zip deploy uploads a packaged artifact (ZIP) and App Service deploys it. This is a good option for straightforward deployments and for learning the platform.

• Build your app into a deployable output (for example compiled .NET publish output, or a Node app with required files).
• Create a ZIP of the deployment content.
• Deploy to the target slot (staging or production).

Practical tip: Use zip deploy to staging first, validate, then swap to production.

GitHub Actions / Azure DevOps (CI/CD conceptually)

CI/CD pipelines automate build, test, and deployment. Conceptually, the flow is:

• Developer pushes code to a repository.
• Pipeline builds and runs tests.
• Pipeline produces an artifact and deploys to the staging slot.
• Optional approval step.
• Swap staging to production.

This approach reduces manual steps and makes deployments repeatable. It also makes rollbacks easier because you can redeploy a previous artifact or swap slots back.

Local Git (push to App Service)

App Service can accept Git pushes directly. Conceptually:

• Enable local Git deployment in the App Service deployment settings.
• Add the App Service Git remote to your local repository.
• Push to that remote to trigger a deployment.

When to use: quick demos and small projects. For teams and production, CI/CD pipelines are usually preferred for auditability and repeatability.

Basic Rollback Strategies

Rollback with deployment slots (fastest)

• If you deployed to staging and swapped to production, and production has issues, perform a swap back to revert quickly.

Rollback by redeploying a previous artifact

• Keep build artifacts (ZIPs) or tagged releases.
• Redeploy the last known-good artifact to staging, validate, then swap.

Rollback by reverting source and redeploying

• Revert the commit in your repository.
• Let the pipeline rebuild and redeploy.

Practical guidance: Slot swaps are great for immediate recovery, but you should still fix forward by correcting the issue and redeploying a proper version.

Troubleshooting First-Deploy Issues

Issue: Wrong runtime stack or version

Symptoms: app fails to start, returns 500 errors, or shows a default page instead of your app.

• Verify runtime stack and version in the Web App configuration.
• Confirm OS choice (Windows vs Linux) matches your app and deployment expectations.
• Redeploy after correcting runtime settings if needed.

Issue: Missing application settings / connection strings

Symptoms: app starts but fails when accessing a database or external service; errors indicate missing environment variables.

• Check Configuration for required app settings and connection strings.
• Confirm naming matches what your code expects (case sensitivity can matter depending on stack).
• If using slots, confirm whether a setting is marked as a slot setting appropriately.

Issue: Startup command / entry point errors (common on Linux)

Symptoms: container or runtime starts but your app never binds correctly; repeated restarts; 502/503 errors.

• Check whether your framework requires a startup command (for example, a Node start script or a Python gunicorn command).
• Verify the app listens on the expected port (App Service expects the app to bind correctly; some stacks use environment variables for port binding).
• Review App Service logs to identify the failing command or missing dependency.

Issue: Deployed the wrong folder or missing build output

Symptoms: site loads but shows errors like missing files, or it serves a directory listing/default page.

• Confirm your ZIP contains the correct build output (for example, published .NET output rather than source files).
• For Node/Python, ensure required files are included (such as package.json / requirements.txt and application entry point).
• Redeploy with a corrected artifact.

Issue: App works locally but fails in App Service

Symptoms: local success, cloud failure due to environment differences.

• Compare environment variables locally vs App Service configuration.
• Check runtime version differences (for example Node 18 locally but Node 16 in App Service).
• Enable and review application logging and platform logs in App Service to see the actual error.

Quick checklist for diagnosing

• Confirm the correct slot (staging vs production) is being deployed to.
• Confirm runtime stack/version and OS.
• Confirm app settings/connection strings exist and are correctly marked as slot settings where needed.
• Check startup configuration/entry point.
• Inspect logs for the first error in the startup sequence.