CH04-02: App Service, Functions, and Managed Hosting

Goal

The previous section introduced compute selection as a responsibility decision. This section looks at two relatively managed Azure options: Azure App Service and Azure Functions.

Both reduce infrastructure management. Both can run application code. They solve different architecture problems.

The durable idea is:

App Service is for managed web and API hosting; Functions is for event-driven units of work.

The Short Version

Azure App Service is a managed hosting service for web applications, mobile back ends, and REST APIs. In plain language, it gives a team a place to deploy a web app or API without managing the underlying web servers directly.

Azure Functions is a serverless compute service for code that runs in response to triggers. A trigger might be an HTTP request, queue message, timer, event, database change, or file upload. In plain language, it is a way to run a focused piece of code when something happens.

These two services often sit near each other in compute discussions because they are both managed. The design question is not which one is more modern. The design question is whether the component is an application host or an event-driven unit of work.

User request -> App Service web/API -> Database or downstream service

Event, schedule, or message -> Azure Function -> Focused action or update

Request-Driven Hosting

App Service is usually a strong fit when the workload has a clear web or API boundary.

Examples include:

A customer portal.
A REST API used by mobile or web clients.
An internal line-of-business web application.
A web app that needs deployment slots, custom domains, managed certificates, authentication integration, or predictable web hosting behavior.

The mental model is simple: the application is always there as an application endpoint. Users or systems send requests to it. The app handles those requests, calls other services, reads or writes data, and returns responses.

App Service reduces the team's need to manage web server infrastructure, but the team still owns important architecture decisions. Configuration, identity, secrets, networking, deployment pipelines, monitoring, scaling rules, and reliability design still matter.

Event-Driven Execution

Functions is usually a strong fit when code should run because something happened.

Examples include:

Generate a receipt after an order message arrives.
Resize an image after a file is uploaded.
Run a cleanup job on a schedule.
Process a queue message.
React to an event from another Azure service.

The mental model is different from web hosting. A function is usually a focused unit of work. It starts from a trigger, does its job, and finishes. Some functions respond to HTTP requests, but that does not automatically make Functions the right host for a full web application.

Function apps can also use different hosting options. Some plans are more consumption-oriented and elastic. Others support always-warm instances, virtual network integration, or more predictable costs. You do not need to memorize those plans right now. The important point is that serverless still has hosting and operating choices.

Comparing the Two

Question	App Service	Azure Functions
What is the main job?	Host a web app or API.	Run code in response to triggers.
What starts the work?	Usually a user or system request to an application endpoint.	An HTTP request, queue message, timer, event, file change, or other trigger.
How does the team think about the unit?	Application or API boundary.	Function, event handler, task, or workflow step.
What is a strong fit?	Portals, APIs, web apps, business applications.	Background processing, automation, integration glue, event reactions.
What can go wrong?	Treating managed hosting as if deployment, monitoring, and reliability are automatic.	Splitting business flows into too many small pieces that are hard to observe and govern.

The same business platform can use both. App Service might host the customer-facing portal and API. Functions might process uploaded documents, send notifications, or handle scheduled maintenance tasks.

Managed Does Not Mean Decision-Free

Managed compute moves some infrastructure responsibility to Azure. It does not remove your responsibility for the workload.

For App Service, you still decide:

How deployments move from development to production.
Whether to use deployment slots or blue-green patterns.
How the app authenticates users or workloads.
How the app reaches databases, storage, and private network dependencies.
How scaling rules, health checks, logs, and alerts work.

For Functions, you still decide:

Which triggers start work.
Whether work should be idempotent so retries do not create duplicate effects.
How failures and poison messages are handled.
Whether cold starts or execution limits matter for the workload.
How state, correlation IDs, logs, and monitoring make the flow visible.

This is the healthy way to think about managed services: they reduce the wrong kind of work so the team can focus on the right architecture decisions.

Example: Customer Portal and Receipt Processing

Imagine a SaaS product with a customer portal. Users sign in, view subscriptions, update billing details, and download receipts.

A practical split could be:

Browser or mobile client
	|
	v
Azure App Service: customer portal and API
	|
	+-- writes order or billing event
		|
		v
	Queue or event source
		|
		v
	Azure Function: generate receipt PDF and store result

The portal is request-driven. It needs a stable application boundary, predictable deployment, user-facing monitoring, and clear API behavior. App Service is a natural fit.

Receipt generation is triggered by an order or billing event. It does not need to run as part of the user's page request. A Function can process it asynchronously, retry when needed, and keep the portal responsive.

The architecture improves because each compute choice follows the job. The portal does not become a collection of tiny functions just because serverless exists. The receipt task does not need to be baked into the web host just because the web app already exists.

Common Mistakes

Using Functions for a full web application because it sounds cheaper.
Using App Service for every background task even when an event trigger would be simpler.
Forgetting cold starts, execution duration, state, retries, and observability when choosing Functions.
Treating managed hosting as a reason to skip deployment and monitoring design.
Putting long-running business processes into isolated functions without a clear orchestration, retry, and visibility model.

If Someone Asks You

When would you use App Service instead of Azure Functions?

A good answer is:

I use App Service when I need managed hosting for a web application or API with a clear application boundary. I use Azure Functions when work is naturally trigger-based, event-driven, or scheduled. Functions are excellent for focused units of work, but I would not turn a full application into many functions unless the architecture really benefits from that model.

What You Should Remember

Match App Service to application hosting and Functions to event-driven work.

Questions to Check Your Understanding

Why is App Service usually a clearer fit for a web application than Functions?
What makes a workload a good candidate for Azure Functions?
Which responsibilities remain with the team when using managed hosting?