Creating Web Apps

Module: Deploy and Manage Azure Compute Resources

Lesson: Creating and Configuring Azure App Service Web Apps

Introduction: Why Azure App Service Matters

In the modern landscape of software development, the ability to deploy applications quickly and manage them with minimal overhead is a primary concern for engineering teams. Azure App Service is a Platform-as-a-Service (PaaS) offering that allows you to build, deploy, and scale web applications, mobile backends, and RESTful APIs without worrying about the underlying server infrastructure. Instead of managing operating systems, patching servers, or configuring complex load balancers, you focus entirely on your code.

This lesson explores how to create and configure Azure App Service Web Apps. We will move beyond the basic "click and deploy" approach to understand the underlying architecture, the configuration settings that dictate performance and cost, and the operational best practices that ensure your applications remain reliable in a production environment. Whether you are migrating a legacy application to the cloud or building a new microservice, understanding the nuances of App Service is essential for any professional working within the Azure ecosystem.

Understanding the App Service Architecture

Before we dive into the creation process, it is important to understand what happens under the hood when you create a Web App. An App Service environment consists of a Plan and an App. The App Service Plan acts as the "container" for your applications. It defines the compute resources—CPU, RAM, and disk space—that your apps share.

When you create an App Service Plan, you select a pricing tier (e.g., Free, Shared, Basic, Standard, Premium). This tier dictates the features available to your app, such as custom domains, SSL certificates, auto-scaling, and staging slots. Multiple apps can run within a single App Service Plan, which makes it an efficient way to host multiple related services while sharing costs.

Callout: The Relationship Between App Service Plans and Web Apps Think of the App Service Plan as a physical server or a virtual machine cluster that you have provisioned. The Web App itself is the software process running inside that environment. If you scale up your Plan, every application running on that Plan benefits from the increased compute resources. If you isolate your apps into separate Plans, you gain greater control over resource allocation, though this typically results in higher costs.

Step-by-Step: Creating Your First Web App

You can create an Azure Web App using the Azure Portal, the Azure CLI, or PowerShell. For this demonstration, we will focus on the Azure CLI, as it provides a repeatable and scriptable way to manage your infrastructure.

1. Prerequisites and Environment Setup

Ensure you have the Azure CLI installed and that you are logged into your subscription. You should also have a Resource Group created to house your resources.

# Log in to your Azure account
az login

# Create a resource group
az group create --name MyWebResourceGroup --location eastus

2. Creating an App Service Plan

The plan defines the tier and the compute power. For production applications, you generally want to avoid the Free or Shared tiers, as they do not support custom domains or advanced scaling.

# Create an App Service Plan (B1 is a cost-effective choice for development)
az appservice plan create --name MyPlan --resource-group MyWebResourceGroup --sku B1

3. Creating the Web App

Once the plan exists, you can deploy the web app. You must specify a unique name, as this will be part of the default URL (e.g., myappname.azurewebsites.net).

# Create the web app
az webapp create --name MyUniqueAppName --resource-group MyWebResourceGroup --plan MyPlan --runtime "NODE|18-lts"

Note: The --runtime parameter is critical. It tells Azure which stack to use. Common options include NODE|18-lts, PYTHON|3.11, DOTNETCORE|8.0, or JAVA|17. Ensure your selection matches the framework your code is built upon.

Configuring Your Web App for Production

Creating the resource is only the first step. To make an application "production-ready," you must configure it to handle traffic, security, and environment-specific settings.

Application Settings

Environment variables are the industry standard for managing application secrets and configuration without hardcoding them into your source code. In Azure App Service, these are known as "App Settings."

You can set these via the CLI:

az webapp config appsettings set --name MyUniqueAppName --resource-group MyWebResourceGroup --settings DB_CONNECTION_STRING="server=prod-db;..." API_KEY="secret-value"

Custom Domains and SSL

By default, your app is accessible via *.azurewebsites.net. For professional applications, you will want to map a custom domain (e.g., www.yourcompany.com). This involves two steps:

1. Creating a DNS CNAME record pointing your domain to the Azure Web App URL.
2. Adding the custom domain to the App Service configuration.

After adding the domain, you must bind an SSL/TLS certificate. Azure provides App Service Managed Certificates, which are a simple, cost-effective way to secure your traffic without manually managing renewals.

Scaling Settings

Scaling is the process of adjusting your compute resources to meet demand. App Service supports two types of scaling:

• Scale Up (Vertical): Changing the tier of your App Service Plan (e.g., moving from B1 to P1v2). This provides more CPU and RAM to your existing instances.
• Scale Out (Horizontal): Increasing the number of instances running your app. This is typically managed via "Autoscale" rules based on metrics like CPU percentage or memory usage.

Warning: Be careful with manual scaling. If you set your instance count to a high number, you will be billed for every instance continuously. Always prefer Autoscale rules that can scale down during off-peak hours to save costs.

Deployment Methods

How you get your code into the App Service is just as important as how you configure it. Manual FTP uploads are prone to error and should be avoided in modern workflows.

1. Deployment from Git

You can connect your App Service directly to a repository (GitHub, Bitbucket, or Azure DevOps). When you push code to a specific branch, Azure automatically triggers a build and deployment process.

2. Deployment Slots (Staging)

Deployment slots are one of the most powerful features of App Service. A slot is a separate instance of your web app that shares the same App Service Plan. You can deploy code to a "Staging" slot, perform final testing, and then "swap" that code into the "Production" slot.

This provides a zero-downtime deployment experience. If the new code has an issue, you can simply swap back to the previous version instantly.

# Create a staging slot
az webapp deployment slot create --name MyUniqueAppName --resource-group MyWebResourceGroup --slot staging

# Perform a swap
az webapp deployment slot swap --name MyUniqueAppName --resource-group MyWebResourceGroup --slot staging --target-slot production

Comparison of App Service Plans

The choice of App Service Plan significantly impacts your application's behavior. Below is a summary of the most common tiers.

Best Practices for App Service Management

Managing web apps effectively requires a proactive mindset. Below are the industry-standard practices for maintaining a healthy environment.

Use Managed Identities

Never store database connection strings or storage account keys in your configuration settings if you can avoid it. Use Managed Identities to give your Web App a secret-less way to authenticate with other Azure resources (like SQL Database or Key Vault). This eliminates the risk of credentials being leaked in configuration files.

Implement Health Checks

Azure App Service can monitor your application's health by pinging a specific path (e.g., /health). If the application stops responding, Azure will automatically restart the instance. Configure this in the "Health Check" section of your Web App settings.

Centralized Logging

By default, logs are stored on the local disk of the App Service instance. This is problematic because if the instance is recycled, your logs disappear. Enable "Diagnostic Settings" to send your logs to an Azure Log Analytics workspace. This allows you to query logs across multiple instances and set up alerts for errors.

Networking Security

For sensitive applications, use "VNET Integration." This allows your Web App to communicate with private resources (like a database in a private subnet) as if it were on the same internal network. Combine this with "Private Endpoints" to ensure your Web App is not exposed to the public internet at all.

Common Pitfalls and How to Avoid Them

Even experienced engineers run into issues when managing Web Apps. Here are the most frequent mistakes and how to prevent them.

1. Over-provisioning: Many teams select "Premium" tiers for simple internal tools. Always start with a lower tier and monitor your metrics. You can always scale up later without downtime.
2. Ignoring Cold Starts: If you use the "Consumption" plan (often associated with Functions or specific App Service configurations), you may face cold starts. If low latency is critical, ensure your App Service Plan has "Always On" enabled.
3. Hardcoding Configuration: Never put environment-specific settings in your web.config or appsettings.json files. Use Azure App Settings, which override local files at runtime.
4. Forgetting Backups: While Azure is reliable, human error is real. Always configure automated daily backups to a storage account. The cost is negligible compared to the cost of losing production data.
5. Scaling Misconfiguration: Setting an autoscale rule that is too aggressive can lead to "flapping," where the system constantly adds and removes instances. Use a buffer (e.g., scale out at 70% CPU, scale in at 30% CPU) to prevent this.

Callout: Staging Slots and Warm-up When you swap a staging slot to production, the application might experience a brief moment of slowness as it initializes. Use the applicationInitialization configuration in your web.config or custom startup scripts to "warm up" the app before the swap completes. This ensures that users never experience a cold start during a deployment.

Advanced Configuration: Custom Containers

While the built-in runtimes (Node, Python, Java) cover most use cases, some applications require specific OS-level dependencies or custom configurations. Azure App Service allows you to deploy your application as a Docker container.

When you deploy a container, you provide the image name and the registry credentials. Azure handles the pulling, starting, and monitoring of your container. This provides complete control over the runtime environment while still benefiting from the managed nature of App Service.

# Create a web app using a custom container image
az webapp create --name MyContainerApp --resource-group MyWebResourceGroup --plan MyPlan --deployment-container-image-name myregistry.azurecr.io/myapp:latest

When using containers, ensure you follow the "One Process per Container" rule and use environment variables for all configuration. You should also ensure your container image is stored in a private Azure Container Registry (ACR) to maintain security.

Monitoring and Troubleshooting

When an application fails, the most important tool is the "Diagnose and solve problems" blade in the Azure Portal. This tool runs automated checks against your app, looking for common issues like high memory usage, failed requests, or configuration errors.

For deeper analysis, use "Log Stream." This allows you to see the real-time output of your application's stdout and stderr. If you are running a Node.js or Python application, ensure you have enabled "App Service Logs" in the portal settings to see your application-level error traces.

If you suspect a performance issue, use the "Application Insights" integration. This is an Application Performance Management (APM) tool that tracks every request, database query, and dependency call. It provides a visual map of your application, showing exactly where the bottleneck is occurring.

Security Considerations

Security in the cloud is a shared responsibility. While Microsoft secures the physical infrastructure, you are responsible for securing your application code and configuration.

• HTTPS Only: Always enforce HTTPS for your web app. This is a toggle in the "Configuration" settings.
• IP Restrictions: If your application is internal, use "Access Restrictions" to allow traffic only from specific IP ranges or Virtual Networks.
• Managed Identities: As mentioned earlier, this is the most effective way to eliminate hardcoded secrets.
• Key Vault Integration: For secrets that must be stored (like API keys for third-party services), use Azure Key Vault and reference the secrets in your App Settings.

Quick Reference: Deployment Checklist

Before you declare your Web App "ready for production," run through this checklist:

• Plan Selection: Does the tier match the traffic requirements?
• Custom Domain: Is a CNAME record set and an SSL certificate bound?
• Environment Variables: Are all secrets stored in App Settings or Key Vault?
• Deployment Strategy: Are you using Deployment Slots for zero-downtime updates?
• Monitoring: Is Application Insights configured for error tracking?
• Security: Is "HTTPS Only" enabled and are Managed Identities in use?
• Backups: Is the automated backup feature enabled?

Key Takeaways

1. Understand the Plan-App Relationship: Azure App Service Plans define the compute resources, while the Web App is the logical application running within those resources. Efficiently sharing plans can significantly reduce costs.
2. Infrastructure as Code: Always use the Azure CLI or Infrastructure-as-Code (IaC) tools like Terraform to create your resources. This ensures consistency across environments and eliminates manual configuration errors.
3. Leverage Deployment Slots: Use slots to enable staging and production environments within a single App Service. This is the industry standard for ensuring zero-downtime deployments and providing a safety net for rollbacks.
4. Prioritize Security: Move away from hardcoded secrets. Utilize Managed Identities and Azure Key Vault to handle authentication and sensitive data. Always enforce HTTPS and limit network access to known sources.
5. Monitor Proactively: Do not wait for a user to report an error. Use Application Insights to monitor performance and set up alerts for high error rates or latency.
6. Scale Intelligently: Use Autoscale rules rather than static instances. This ensures your app has enough power during peak times but remains cost-effective during quiet periods.
7. Keep it Simple: Start with the smallest necessary configuration and scale out as your data shows a need. Avoid premature over-provisioning of compute resources.

By mastering these concepts, you transition from simply "hosting" an application to "managing a platform." Azure App Service is a powerful tool, but its true value is unlocked when you apply these architectural and operational best practices. As you continue your journey, focus on automating your deployment pipelines and refining your monitoring strategy, as these are the hallmarks of a professional cloud engineer.