The previous lesson ended with an implicit question: if having an available, elastic API means building a scale set, a balancer, probes, autoscale rules, operating system patches and certificates by hand… isn't there something that does all of that for you? There is, and it is called Azure App Service.

Contoso Airlines has two new applications that carry no debt from the past: Contoso Bookings, the public website where customers search for flights and buy their tickets, and the Availability API, the internal service that queries seats and prices. Both are modern code (Java for the API, Node.js for the website) that Diego Salas can package and deploy without depending on the operating system. For them, maintaining virtual machines would be unpaid work: patches, agents, certificates and manual deployments that do not add a cent to the business.

In this lesson you will learn what App Service is, how its plans work and why the plan is billed, not the application, how to deploy code with Azure CLI, how to configure the application with app settings and connection strings, how to put Contoso's own domain in place with a managed certificate, and how to publish new versions without interrupting the service using deployment slots. Remember that module 1 already announced the app-contoso-reservas-pro application: here we create it for real.

Cost warning: the Free (F1) tier costs nothing and is enough for almost all the exercises. The Basic, Standard and Premium tiers are billed by the hour as long as the plan exists, even if the application never receives a single request. The cleanup is at the end.

1. What App Service is and why Contoso chooses it
2. App Service plans: tiers, Linux and Windows
3. Supported runtime stacks
4. Creating the plan and the applications with Azure CLI
5. Deploying code: ZIP deploy and deployment from Git
6. Configuration: app settings and connection strings
7. Custom domains and managed TLS certificates
8. Deployment slots and swap with warm-up
9. Vertical, horizontal and automatic scaling
10. Diagnostics: logs, log stream and SSH console
11. Virtual network integration (an introduction)
12. Cleanup
13. Common Mistakes and Tips
14. Exercises
15. Conclusion

Azure App Service is a platform as a service (PaaS) for hosting web applications, APIs and mobile back-end applications. You hand over the code or the artifact; Azure takes care of the operating system, the web server, the runtime, the balancing between instances and the TLS certificate.

Compared with what you built in the previous lesson:

The last row is the trade-off: in App Service there is no administrator access to the server, you cannot install arbitrary daemons or depend on paths outside your application's space. That is why the legacy availability engine stays on a VM (lesson 02-01) and the new applications go here.

Contoso Airlines' recorded decision:

• app-contoso-reservas-pro: the public sales website, Node.js on Linux.
• app-contoso-api-disponibilidad-pro: the internal seats-and-prices API, Java on Linux.
• Both on the same production plan to begin with; the API moves to its own plan when the season-opening peak justifies it (you will see this in exercise 1).

The most important concept, and the one that causes the most surprise bills: the App Service plan is the set of machines your applications run on. The plan is billed, not the application.

Direct consequences:

• Ten applications on one plan cost the same as one: what you pay for is the plan.
• A stopped application on a paid plan still costs money, because the plan still exists. To stop paying you have to delete the plan (or drop it to Free).
• The applications on the same plan share CPU, memory and instances. If one eats the CPU, the others feel it.

What each jump unlocks, put bluntly:

• From Free to Basic: dedicated instances, your own domain and TLS, and an application that does not fall asleep.
• From Basic to Standard: deployment slots and autoscaling. This is the jump that turns a toy into a production service.
• From Standard to Premium v3: faster hardware, more instances, zone redundancy and better network limits. It is the tier Contoso's policy of keeping critical components in two zones requires.

Contoso chooses Linux for both applications: there is no classic .NET Framework anywhere, the price is lower and the Node and Java stacks are perfectly supported.

App Service runs your code on a runtime stack that you choose when creating the application and can change later. Check the available ones with:

An abbreviated output and how to read it:

The format is STACK:VERSION. Two important warnings:

• Versions reach end of support: when a Node or Java version leaves community support, Azure removes it from the list, with prior notice. Plan your upgrades; do not discover the end of support on the day a deployment fails.
• If your stack or version is not on the list (for example, Go or one very specific old version), the way out is a custom container, and that is covered in lesson 06-01.

We start with the development environment, on the free tier, so that you can follow the lesson at no cost.

Details that matter:

• --is-linux defines the operating system of the plan, not of the application. It cannot be changed afterwards: if you get it wrong, you have to create another plan.
• The application name is globally unique, because it generates the app-contoso-reservas-dev.azurewebsites.net host name. If somebody in the world has taken it, it fails. That is why Contoso uses an organization-specific prefix.
• The two applications share a plan: the cost does not change by adding the second one.
• On the F1 tier you cannot turn on --https-only… actually you can, and you should:

The *.azurewebsites.net domain already comes with a valid TLS certificate, so your application is reachable over HTTPS from the very first second.

It is the most used one in scripts and pipelines: you package the application and upload it.

Three fundamental things about this code, because they are what trips everybody up the first time:

1. The port comes in process.env.PORT. App Service injects that variable and expects your application to listen there. If you listen on a fixed port, you will see the "Application Error" message with no further clue.
2. The application must listen on every interface, not only on 127.0.0.1.
3. App Service needs to know how to start it. With Node it uses npm start or index.js; if your entry point is something else, define it:

For Java, the artifact is a .jar or a .war:

App Service includes a local Git repository you can push code to; each git push triggers a build and a deployment.

It can also connect to GitHub to deploy on every commit to a branch. That is convenient for getting started, but for production the right path is Azure Pipelines, with its environments and approvals: that is module 5, and we do not develop it here.

Check the result:

A well-built application does not carry its configuration inside the code. In App Service there are two mechanisms, and both reach your process as environment variables.

Key points to remember:

• Changing a setting restarts the application. It is neither instantaneous nor transparent: group them and apply them together.
• Settings override the ones in your application's configuration file with the same name. It is the mechanism that lets you use the same artifact in development and production.
• Each deployment slot can have its own settings; you can mark them as slot settings so that they do not travel on a swap (section 8).

App settings are encrypted at rest and do not appear in the code, which is already better than the usual alternative. But:

• Anyone with Contributor permission on the application can read them in clear text from the portal or with az webapp config appsettings list.
• They are exposed in template exports and configuration dumps.
• There is no automatic rotation, no expiry and no per-secret access audit.

The correct solution in Azure is Azure Key Vault, with references from the application that point to the secret instead of containing it:

For this to work, the application needs a managed identity with read permission on the vault. Managed identities and RBAC are lesson 04-02; Key Vault, lesson 04-03. Contoso keeps the payment gateway key and the production connection string there, in rg-contoso-seguridad-pro. Here you only need to take away the rule: in development, settings; in production, Key Vault references.

Nobody sells tickets at app-contoso-reservas-pro.azurewebsites.net. Contoso uses the contosoairlines.example domain and wants the website at www.contosoairlines.example.

The process has three steps:

Step 1: prove that the domain is yours. Two DNS records are created at your provider (Azure DNS is covered in lesson 02-06):

Step 2: associate the domain with the application.

Step 3: a managed TLS certificate, free and automatically renewed.

What you should know about the managed certificate: it is free, it renews itself, it requires the Basic tier or above, and it does not cover some cases (wildcards in certain configurations, domains without public verification). For those cases you upload your own certificate or use an App Service Certificate. The operational advantage is enormous: outages caused by expired certificates simply stop happening.

Here is, probably, the feature that most justifies paying for the Standard tier.

A deployment slot is an additional instance of the application, within the same plan, with its own host name and its own configuration. The swap exchanges the contents of two slots… without restarting the process or interrupting traffic.

The swap does not copy files: it changes the routing between two sets of workers that are already running. Before switching over, Azure runs a warm-up:

1. It applies the destination slot's settings (the ones not marked as slot settings) to the source slot.
2. It restarts the slot's workers with that configuration and waits for them to respond.
3. Only when they respond correctly does it switch the routing.

This eliminates the cold start the first customer would suffer after a classic deployment. You can control the warm-up with specific settings:

Some values must not travel on the swap: the test database connection string cannot end up in production. They are marked as slot settings:

• Rolling back means swapping again: the previous version is still alive in the other slot. It is the fastest rollback there is.
• Progressive (canary) deployment: you can send a percentage of real traffic to the slot before swapping.

One important warning: slots share the plan, meaning they share CPU and memory with production. A load test against the slot affects real customers. For serious load testing, use a separate plan.

In App Service you scale the plan, not the application.

Autoscaling, with the same rule mechanics you saw in 02-02 but with no scale set to administer:

The same golden rules apply: scale out fast, scale in slowly, a wide dead band and a scheduled profile for the season opening. And the same requirement: the application cannot hold local state. Since every instance on a plan shares the application's file system (mounted from storage), writing to it in the hot path is slow and fragile: the boarding passes go to Blob Storage (lesson 02-04) and the data to the database (module 3).

Two other plan features worth knowing:

• Always On: keeps the application awake. On Free and Basic the application is unloaded after a while without traffic and the next request suffers a cold start. Turn it on in production (--always-on true, requires Basic or above).
• Zone redundancy: available on Premium v3, it distributes the instances across availability zones. It is the option that satisfies Contoso's policy for critical components.

az webapp log tail is App Service's most profitable diagnostic tool: it shows live whatever your application writes to standard output. If your application does not start, that is where you will see the real reason (a missing dependency, the wrong port, a non-existent environment variable).

A console inside the application's container:

Inside you will find your code in /home/site/wwwroot. Remember: whatever you write outside /home is lost on a restart or when the application moves instance; it is the equivalent of a VM's temporary disk.

Other tools of the service, so that you know they exist:

• Diagnose and solve problems in the portal: automatic detectors for crashes, restarts, memory usage and HTTP errors.
• Kudu (https://<app>.scm.azurewebsites.net): the service's advanced console, with a file explorer, processes and deployment logs.
• Application Insights: the application's real telemetry (requests, dependencies, exceptions, performance). It is lesson 07-03 and it is what Contoso ends up using daily.

By default, a Web App lives outside your virtual network: it receives traffic from the internet and goes out to the internet. Contoso needs the opposite in two directions:

• Outbound: the website and the API must reach the sql-contoso-reservas-pro database without going through the internet. That is solved with virtual network integration, which connects the application's outbound traffic to a delegated subnet (snet-app).
• Inbound: the Availability API should not be reachable from the internet, only from the network. That is solved with access restrictions or with a private endpoint.

We deliberately leave it here: the design of vnet-contoso-pro, its subnets, the delegation, the network security groups and the private endpoints are the complete content of lesson 02-05, which comes in two lessons' time.

We insist because it is the typical cost mistake: deleting the application does not delete the plan. A forgotten P1v3 plan costs more than a hundred euros a month without serving a single request.

• Believing that the application is billed. The plan is billed. Stopping the application saves nothing; deleting the plan (or dropping it to Free) does.
• Deleting applications and leaving the plan alive. It is App Service's most common phantom bill.
• Not listening on process.env.PORT. It produces an unexplained "Application Error". It is the number one failure when deploying Node or Python for the first time.
• Choosing the wrong operating system for the plan. Linux and Windows do not mix and a plan cannot be converted: you have to create another one.
• Putting secrets in app settings in production. Any contributor reads them in clear text. Use Key Vault references (04-03) with a managed identity (04-02).
• Changing settings one at a time in production. Each change restarts the application. Group them.
• Trying zero-downtime deployment on the Basic tier. There are no slots until Standard. It is the main reason to move up a tier.
• Forgetting to mark environment-specific settings as slot settings. On the swap, the pre-production configuration ends up in production. It happens, and it hurts.
• Load testing against a slot on the production plan. They share CPU: you harm real customers.
• Leaving Always On turned off in production. The first customer after a quiet spell pays for the cold start.
• Tip: turn on --https-only true and --min-tls-version 1.2 on every application, including development ones. It costs two commands and it avoids a finding in the module 4 security review.
• Tip: name your applications with an organization prefix (app-contoso-…). The name is global and the generic ones are already taken.

Contoso has four applications: the Contoso Bookings website (public, high and seasonal traffic), the Availability API (internal, high traffic at the peak), the ground staff's operations dashboard (internal, 40 users, office hours) and a test portal that Diego uses for demos.

1. How many App Service plans would you create and which applications would you put on each one? Justify it.
2. Which tier would you assign to each plan and what does that tier unlock?
3. What configuration would you add to the production plan to comply with Contoso's policy on critical components?

Write the complete sequence of Azure CLI commands to publish version 1.5.0 of Contoso Bookings without any customer seeing an error:

1. Create the preproduccion slot by cloning the production configuration.
2. Mark ENTORNO as a setting that does not travel on the swap.
3. Configure the warm-up against /salud.
4. Deploy the ZIP to the slot and verify it.
5. Send 10% of real traffic to the slot during the validation.
6. Swap, and explain how you would roll back if something goes wrong.

Diego deploys the Availability API and https://app-contoso-api-disponibilidad-dev.azurewebsites.net returns "Application Error". List, in order, the steps and commands you would use to find the cause, and mention at least three probable causes with their fix.

Solution 1:

1. Three plans:
   • plan-contoso-reservas-pro: the bookings website. It is kept separate because its traffic is the highest and the most seasonal and we do not want its peak to affect anything else.
   • plan-contoso-api-pro: the Availability API. It scales on a different profile (the API's peak is sharper than the website's) and it is worth isolating so that a load test or a website failure does not degrade it.
   • plan-contoso-interno-pro: the operations dashboard and the test portal. Low, predictable traffic; they share a plan because the cost is the cost of the plan and this way only one is paid for.
2. Tiers:
   • The two public plans, Premium v3 (P1v3): deployment slots, autoscaling, zone redundancy and better per-instance performance.
   • The internal plan, Standard (S1): enough for 40 users and it already includes slots and autoscaling.
3. Zone redundancy on the production plans (available on Premium v3), with at least 2 instances, to comply with the "critical components in at least two availability zones" policy. On top of that, always-on enabled and https-only on all of them.

Solution 2:

Rollback: run the same swap command again. After the first swap, version 1.4.0 was left in preproduccion, alive and warmed up, so going back takes seconds and requires no redeployment.

Solution 3:

Three probable causes and their fix:

You now know how to publish applications in Azure without administering servers. You understand what App Service is and why Contoso puts Contoso Bookings and the Availability API there while the legacy engine stays on a VM. You have mastered the concept that costs the most money to ignore: the plan is billed, not the application, with its table of tiers and what each jump unlocks — Basic for a custom domain and TLS, Standard for slots and autoscaling, Premium v3 for zone redundancy. You know how to choose a runtime stack, create the plan and the applications with the CLI, and deploy code with ZIP deploy and Git, with the three first-deployment traps solved (port, interface and startup command). You configure the application with app settings and connection strings as environment variables, and you know why production secrets go to Key Vault by reference. You have set up a custom domain with a managed, auto-renewing certificate, you have published with no downtime using slots, warm-up, progressive deployment and immediate rollback, you know how to scale the plan vertically, horizontally and automatically, and you have the diagnostic tools (live log stream, log download, SSH and Kudu) for when something does not start.

There is one loose end left, and it has a name. Your application cannot store anything locally: not the session, not the files, and not the boarding passes in PDF that Contoso generates every time somebody buys a ticket. In module 1 you created sttarjetascontosodev and its tarjetas-embarque container, and you left one decision pending: which redundancy to use in development and which one in production.

The next lesson, Azure Storage: Blobs, Files, Queues and Tables, picks up that loose end and settles it completely: the four services of a storage account, the blob types and the Hot, Cool, Cold and Archive access tiers with their lifecycle rules — applied to boarding passes that get downloaded a lot in the first week and almost never afterwards — the full LRS, ZRS, GRS, GZRS and RA-GRS redundancy table with Contoso's final decision, and how to grant secure access to a file through temporary shared access signatures instead of handing out the account key.