Create Azure App Service Web Apps

App Service

Azure App Service not only adds the power of Microsoft Azure to your application, such as security, load balancing, autoscaling, and automated management. You can also take advantage of its DevOps capabilities, such as continuous deployment from VSTS, GitHub, Docker Hub, and other sources; and package management, staging environments, custom domain, and SSL certificates.

With App Service, you pay for the Azure compute resources that you use. The compute resources you use are determined by the App Service plan that you run your apps on.

Scalable hosting for web applications:

• Provides a quick way to host your web application in the cloud
• Allows you to scale your web app without being required to redesign for scalability
• Integrates with Visual Studio
• Provides an open platform for many different programming languages

Advantages:

• Near instant deployment
• SSL and Custom Domain Names available in some tiers
• WebJobs provide background processing for independent scaling
• Can scale to larger machines without redeploying applications

Creating a Web App with Azure PowerShell

Creating a Web App with Azure PowerShell

Creating an App Service plan with Azure PowerShell

Creating an App Service plan with Azure PowerShell

Diagnostic Log

View article from Microsoft with full breakdown on how to create a diagnostic log

App Service settings

For ASP.NET developers, configuring app settings in App Service is similar to configuring them in <appSettings> in Web.config or appsettings.json. The difference is that the values in App Service override the values in Web.config or appsettings.json. You can keep development settings in Web.config or appsettings.json (for example, local MySQL password), but keeping production secrets (such as Azure MySQL database password) in App Service is ideal. This is because the same code uses your development settings when you debug locally, and it uses your production secrets when deployed to Azure.

žYou can configure:

Path mappings

žWindows: ž

• Custom IIS handler mappings
• žVirtual applications/directories

žContainerized: ž

• Custom-mounted storage

Updating app runtimes

When adding a new version (major or minor), it installs side-by-side with existing versions. You can also manually upgrade your app to the new version. If you configured the runtime version in a configuration file (such as web.config and package.json), you need to upgrade by using the same method. If you used an App Service setting to configure your runtime version, you can change it in the Azure portal or by running an Azure CLI command in the Cloud Shell.

To update the application runtime, use the az webapp config set command with the appropriate parameter for your runtime.

OS and runtime patching

App Service is a platform as a service (PaaS), which means that the OS and application stack are managed for you by Azure; you only manage your application and its data.

Azure manages OS patching on two levels, the physical servers and the guest virtual machines (VMs) that run the App Service resources. Both are updated monthly. These updates are applied automatically, in a way that guarantees the high availability SLA of Azure services.

Inbound and outbound IP addresses

Each app has a single inbound IP address:

• Regardless of scale-out quantity

Inbound IP address can change:

• Delete an app and re-create it in a new resource group
• Delete the last app in a resource group + region combination and re-create it
• Delete an existing SSL binding

You can opt to use a state inbound IP

Each app has a set number of outbound IP addresses:

• The set and quantity changes as you scale your app between tiers

When IP addresses change

Regardless of the number of scaled-out instances, each app has a single inbound IP address.

The inbound IP address might change when you perform one of the following actions:

• Delete an app and recreate it in a different resource group.
• Delete the last app in a resource group and region combination and recreate it.
• Delete an existing SSL binding, such as during certificate renewal

Find outbound IP addresses

Autoscale

Autoscale is a built-in feature of Azure Cloud Services, Mobile Services, Virtual Machines, and websites that helps applications perform their best when demand changes. Of course, performance means different things for different applications. Some apps are CPU bound, others memory bound. For example, you could have a web app that handles millions of requests during the day and none at night. Autoscale can scale your service by any of these—or by a custom metric you define.

Autoscale metrics

Autoscale patterns

• žScale based on CPU ž
• Scale differently on weekdays vs. weekends
• žScale differently during holidays ž
• Scale based on custom metrics

Autoscale concepts

Each resource can have one autoscale setting:

• Autoscale settings can have one-to-many profiles
• Profiles can have one-to-many rules

Autoscale increases instances horizontally within bounds:

• Bounds are set by using the minimum, maximum, and default values

Thresholds are calculated at an instance level

• Autoscale successful actions and failures are logged to the Activity Log

Autoscale workflow

1.Metrics are measured for a resource

2.When conditions are met (threshold surpassed), autoscale triggers:

a.Perform scale actions

b.Send notifications (alerts)

c.Send messages to webhooks for external automation

Develop solutions that use Cosmos DB storage

Develop solutions that use blob storage

Implement user authentication and authorization

Implement secure cloud solutions

Integrate caching and content delivery within solutions

Instrument solutions to support monitoring and logging

Develop an App Service Logic App

Implement API Management

Develop message-based solutions

Develop event-based solutions