Container Apps and AKS solve how to run services that are always available. But a good part of what Contoso Airlines does is not like that. Generating the PDF of a boarding pass takes two seconds and happens when a passenger confirms their booking. Synchronizing the fare catalog happens when a document changes in cosmos-contoso-tarifas-pro. Between one event and the next there is nothing to do, and yet today Contoso pays for a container sitting there waiting.

Azure Functions is the answer: you write a function, you declare what fires it, and Azure takes care of running it when it is due and of it not existing the rest of the time. This lesson goes beyond "hello world": the triggers and bindings model, the hosting plans with their real trade-offs, Contoso's two production functions, orchestration with Durable Functions and the hardest lesson of the model, which is idempotency.

1. What serverless computing is and what you pay for
2. Triggers and bindings: the mental model
3. Hosting plans compared
4. Creating the project and running it locally
5. GenerarTarjetaEmbarque: the queue function
6. SincronizarTarifas: the Cosmos DB change feed
7. Configuration, managed identity and Key Vault
8. Durable Functions and the check-in flow
9. Idempotency, retries, timeouts and limits
10. Testing, deployment and monitoring
11. When NOT to use functions
12. Common Mistakes and Tips
13. Exercises
14. Conclusion

"Serverless" does not mean there are no servers; it means they are not your problem. You do not pick a machine size, you do not patch, you do not size anything: you write a unit of code and the platform runs it and scales it.

What you pay for on the Consumption plan is three things: the number of executions, the gigabyte-second consumption (memory allocated multiplied by execution time) and outbound traffic. There is a generous monthly free grant, and two practical consequences. The first: a function that does not run costs nothing, and that is the saving compared with the container left switched on. The second, less intuitive: cost is proportional to execution time, so a slow function costs more, and a function that sits blocked waiting on an external HTTP call bills you for waiting.

Here is the concept you need to internalize. A function has exactly one trigger — what decides when it runs — and zero or more bindings, input and output, which are declarative connections to other services. The platform takes care of the connection, the authentication, the deserialization and the retries; you receive objects and return objects.

What makes the model valuable is the bindings. Compare:

Six lines of plumbing replaced by one declaration. And it is not only brevity: the connection, the retries and the authentication with a managed identity are all handled by the runtime.

What Contoso chooses and why:

• GenerarTarjetaEmbarque goes on Flex Consumption: it needs a virtual network to reach pe-storage-tarjetas and pe-sql-reservas over a private endpoint, which classic Consumption does not allow, and its load is bursty, with almost zero consumption in the small hours.
• SincronizarTarifas also goes on Flex Consumption and in the same app: it shares networking and configuration, and its volume is low.
• The check-in orchestration with Durable Functions goes on Premium. Its orchestrations run for hours — they wait for the passenger to upload a document — and there both the cold start and the duration limit matter.
• Nothing goes on the App Service plan, unless they wanted to reuse plan-contoso-api-pro to take advantage of capacity already paid for.

The isolated model (dotnet-isolated) is the current one: the function runs in its own process, decoupled from the host version. Local configuration values go in local.settings.json, which is never committed to the repository — it is in .gitignore for a reason; in Azure, those same names are read from the app settings.

When the passenger completes check-in, app-contoso-reservas-pro enqueues a message on cola-emision-tarjetas in stoperacionescontosopro. This function consumes it, generates the PDF and drops it into the tarjetas-embarque container of sttarjetascontosopro.

What you need to understand about this code:

• [QueueTrigger] declares the trigger. The runtime polls the queue, deserializes the message JSON straight into BoardingPassRequest and hands it to you typed. If deserialization fails, the message goes to the poison queue without your code ever running.
• Connection = "AlmacenOperaciones" is not a connection string: it is the prefix of a configuration setting. With AlmacenOperaciones__queueServiceUri pointing at the account and the managed identity assigned, there is no key at all. This is the point most often got wrong.
• [BlobOutput] with the {Localizador}-{Seat}.pdf template: the incoming message's fields are interpolated into the blob path. The file name is deterministic, and the idempotency check falls out of that for free.
• Returning null does not write the blob, the clean way of bailing out without throwing an exception. And dependency injection works as it does in any .NET application: the constructor receives the logger and the PDF generator, which makes the function testable with ordinary unit tests.

When the commercial team updates a fare in the tarifas container of cosmos-contoso-tarifas-pro, the change feed you already know from 03-03 delivers the modified document to this function, which refreshes the search index and notifies the availability engine's cache.

The lease container deserves attention: it is where the trigger records how far it has read in each partition. It lives in the same database, consumes its own RU/s and, if you delete it, the function reprocesses from the beginning. The function receives batches of changes, not individual documents, and the partition key /origenDestino determines the parallelism: each partition is processed in order and independently.

Three ideas: connections with the __queueServiceUri / __blobServiceUri suffix switch on identity-based mode, with no keys; the Key Vault reference with the @Microsoft.KeyVault(...) syntax from 04-03 resolves the secret at runtime and the value is never visible in the portal; and the identity needs its roles — Storage Queue Data Contributor, Storage Blob Data Contributor and Key Vault Secrets User.

Normal functions are stateless and short-lived. What if the process has several steps, takes hours and you need to know how far it got? Durable Functions adds durable state and resumption: an orchestrator describes the flow with ordinary code, and its execution is persisted automatically at every waiting point.

The three patterns, applied:

• Function chaining: ValidarReserva → EmitirTarjeta. Each step uses the previous one's output; if the process crashes at the third step, on resumption it does not repeat the first two.
• Fan-out / fan-in: documentation, seat and baggage are independent; they are launched in parallel and awaited together. It cuts the total time down to that of the slowest step.
• Waiting for an external event: the orchestrator stops at WaitForExternalEvent("DocumentoSubido") with a 24-hour timeout. While it waits it consumes no compute and bills nothing; that is what makes solving this with a normal function unworkable, since those are limited to minutes.

The orchestrator's golden rule: its code must be deterministic. No DateTime.Now, no Guid.NewGuid() and no direct I/O calls, because the orchestrator re-executes from the beginning every time it resumes, replaying its history. Use context.CurrentUtcDateTime and delegate everything non-deterministic to activities.

This is the lesson almost nobody mentions at the start and everybody learns in production: queues guarantee at-least-once delivery, not exactly-once. If the function crashes after generating the PDF but before acknowledging the message, the message reappears and the function runs again with the same data. With no protection, the passenger receives two boarding passes and the accounting record no longer balances.

How to protect yourself, in order of preference:

On retries: the queue retries automatically (five times by default) and then sends the message to the poison queue. A message that always fails — malformed JSON, a nonexistent flight — is called a poison message, and with no poison queue it would block the queue indefinitely. Watch that queue with an alert: if it grows, something is broken.

On timeouts and limits: 5 minutes by default on Consumption (extendable to 10), configurable on Flex and unlimited on Premium, with the value in functionTimeout in host.json. A large queue message does not fit (64 KB), so send references, not payloads: the blob identifier, not the PDF. And maxConcurrentCalls limits the parallelism, which has to be lowered when the function writes to db-reservas, because a thousand instances opening connections exhaust the database's pool.

The logic lives in injected classes — IPdfGenerator, IFareIndex — so it is tested with ordinary unit tests; the function merely orchestrates. For integration, func start with the Storage emulator. Deployment reuses the 05-04 pipeline, with slots: you deploy to preproduccion, warm it up and swap.

Application Insights comes built in and is where you see everything: successful and failed executions, duration, dependency telemetry and the end-to-end trace from the queue to the blob. Exploiting it is 07-03; here it is enough to know that it is enabled when you create the app and that without it a failing function is a black box.

• Long-running processes with in-memory state: use Durable Functions or a container. And constant, heavy load: if the code runs non-stop, a fixed plan or Container Apps works out cheaper than paying per execution.
• Guaranteed minimum latency on the first request: the Consumption plan's cold start is not acceptable on the purchase path.
• Applications with a lot of shared logic and a joint deployment: if the "functions" are a monolith sliced up that is always deployed together, it is an API, and its place is App Service or Container Apps. The same goes for persistent connections or heavy startup dependencies: every new instance pays that startup, and with aggressive scaling the target suffers.

• Not making the function idempotent. It shows up as sporadic duplicates that are impossible to reproduce. Design for it from day one.
• Using key-based connection strings in the Connection settings. Use the __blobServiceUri suffix with a managed identity.
• Putting the full payload in the message. There is a 64 KB limit on Storage queues: send the reference.
• Writing non-deterministic code in an orchestrator. DateTime.Now or Guid.NewGuid() produce inconsistent results on resumption.
• Ignoring the poison queue, where poison messages end up; if nobody looks at it, the errors are invisible. And not limiting concurrency when the function writes to db-reservas: a thousand instances exhaust the connection pool.
• Committing local.settings.json. It contains local credentials. Check for it in the 05-02 review.
• Tip: measure duration in Application Insights; bringing a function down from 4 s to 1.5 s cuts the Consumption bill by almost the same proportion. And one function, one responsibility: if it has three logically distinct triggers, it is three functions.

Exercise 1. Contoso Miles needs a function that, when a passenger completes a flight, adds the corresponding miles to their profile in cosmos-contoso-tarifas-pro. The events arrive on cola-vuelos-completados.

1. Choose the trigger, the bindings and the hosting plan, and justify your choice.
2. On the first day in production, some passengers show up with duplicated miles. Explain the exact cause, give two ways to fix it, and state the resource tags and the alert you would set up from day one.

Exercise 2. Design the ticket refund process with Durable Functions: validate the request, check the penalty and the gateway balance in parallel, wait for a supervisor's approval (72 hours maximum) and, if approved, issue the credit and notify.

1. State which pattern covers each stretch and why it cannot be solved with a normal function on the Consumption plan.
2. Write the supervisor wait with its expiry in pseudocode and say what happens if the orchestrator restarts while it is waiting.

Exercise 3. An HTTP-triggered function queries db-reservas and responds in 200 ms when traffic is light, but when seats go on sale it returns database timeout errors.

1. Explain the mechanism of the failure.
2. Propose three corrective measures.

Solution 1:

1. A Storage queue trigger on cola-vuelos-completados, with a Cosmos DB output binding to the perfiles container. Flex Consumption plan: bursty volume concentrated around flight landings, almost zero cost in the small hours, and it needs a virtual network to reach Cosmos DB's private endpoint.
2. The cause is at-least-once delivery: if the function adds the miles and crashes before acknowledging the message, the message reappears and the miles are added again. Adding is the non-idempotent operation par excellence. Fix (a): store in the profile document the set of flight identifiers already credited and discard the event if it is already there — a check performed inside the same write. Fix (b): record the message identifier in the registroembarques table before adding, and discard if it already exists. (a) is preferable because it adds neither another store nor another failure window. Tags: entorno, proyecto=contoso-millas, centro-coste=CC-2077 and propietario. The day-one alert is on the poison queue length: as soon as it grows, there are poison messages and passengers without their miles.

Solution 2:

1. Validate → check → credit → notify is chaining; penalty and balance in parallel are fan-out / fan-in; the supervisor's approval is waiting for an external event. It does not fit in a normal function because the wait lasts up to 72 hours and the Consumption plan cuts off at 5 or 10 minutes; on top of that you would need to persist the exact point in the process, and a normal function is stateless.
2. var approval = context.WaitForExternalEvent<Decision>("AprobacionSupervisor"); alongside var deadline = context.CreateTimer(context.CurrentUtcDateTime.AddHours(72), cts.Token); and a Task.WhenAny over both; if the deadline wins it is rejected as expired, and if the event wins the timer is cancelled. If the orchestrator restarts while waiting, nothing happens: the instance is not occupying compute, its history is persisted and on resumption it replays up to the waiting point. That is exactly the property the durable model provides.

Solution 3:

1. The function scales out to dozens or hundreds of parallel instances, and each instance opens its own connections to db-reservas. The server's connection pool is exhausted, requests queue up and eventually time out. The symptom appears in the database, but the cause is the function's uncontrolled scaling.
2. (a) Limit concurrency in host.json and set functionAppScaleLimit to a ceiling compatible with the database. (b) Reuse the database client as a static or singleton instead of creating one per invocation, so that connections are pooled. (c) Take the synchrony out of the path: enqueue the request and respond immediately, or put a cache in front for repeated queries. As a reinforcement, review the tier of sql-contoso-reservas-pro (03-02), although scaling the database without fixing the concurrency only moves the limit.

You now know what "serverless" really means: there is no machine to choose or patch, you pay for executions and gigabyte-seconds, an idle function costs zero and a slow function costs more. You have internalized the mental model of triggers and bindings — one trigger that decides when, input and output bindings that remove the plumbing of connecting, authenticating and retrying — and you know the most-used ones and how they fit at Contoso. You know how to compare the hosting plans on cold start, scaling, virtual network, duration and cost, and why Contoso's functions go on Flex Consumption while the check-in orchestration needs Premium.

You have written the two real functions: GenerarTarjetaEmbarque, fired by cola-emision-tarjetas, with an output binding to the tarjetas-embarque container through a deterministic name template that hands you idempotency for free; and SincronizarTarifas, fed by the change feed of cosmos-contoso-tarifas-pro with its lease container and its batch processing. You have configured them with identity-based connections (__blobServiceUri, __queueServiceUri) and references to kv-contoso-pro, without a single key. With Durable Functions you have orchestrated check-in applying chaining, fan-out/fan-in and waiting for an external event for 24 hours without consuming compute, respecting the deterministic orchestrator rule. And you take away the hard lesson: at-least-once, not exactly-once, with its three idempotency strategies, the poison queue that has to be watched, the timeouts, the 64 KB limit and the concurrency that has to be reined in when there is a database behind it. You know how to deploy with slots from the pipeline, monitor with Application Insights (07-03) and, above all, when not to use functions.

One awkward piece remains. When a flight is delayed, Contoso has to find the affected passengers in db-reservas, notify them by email and by text message, post in the operations team's channel and open an incident in the support system. None of that is complex business logic: it is gluing systems together, and writing it as code means maintaining four integrations by hand with their authentication, their retries and their formats. Besides, the person who knows that process is not Diego, it is the operations team, and they do not code. The next lesson, Azure Logic Apps, is exactly for that: visual workflows over a catalog of more than a thousand connectors, with their versionable JSON definition, their flow control, their error handling and their run history, and with the criteria for knowing when a logic app is called for, when a function and when Data Factory.