So far everything in the Kladde runs all the time: the web application and the worker for the import from module 3.5, both as Container Apps with at least one replica or, when scaling to zero, with an ingress that wakes them. Serverless turns the view around: you write functions that react to an event (a request, a message, a time of day), and the platform starts as many instances as there are events at the moment, even none. You pay for the execution. Azure Functions is this service in Azure. In this module you build the import of the tenders a second time, as Functions, and at the end you decide which way is the better one for the Kladde.
New in this lesson:
| Tool or package | Version | what for |
|---|---|---|
Azure Functions Core Tools (func) |
4.16.0 | the Functions host locally; installation as on Learn, for example with winget or npm |
| Azurite | 3.37.0 | the storage emulator for blob, queue and table that the host needs locally; open source from Microsoft, with npm or as a container |
Azure.Functions.Sdk |
1.0.2 | the project SDK of a function app |
Microsoft.Azure.Functions.Worker |
2.52.0 | the worker in its own process |
Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore |
2.1.1 | HTTP trigger with the types of ASP.NET Core |
Microsoft.Extensions.TimeProvider.Testing |
10.11.0 | FakeTimeProvider in the test, as in module 3.8 |
What serverless means
Three properties make a service "serverless":
- Billing by execution. You pay for the time and the memory in which your functions run, and for the number of calls, not for machines standing ready. What that comes to in money, the price calculator tells you; lesson 3.13.4 works it out for the Kladde.
- Scaling to zero and back. Without events no instance runs. When many come, the platform starts many, in Flex Consumption up to 1,000. When and how far it scales is decided by a scale controller that watches the sources (the length of a queue, the number of requests).
- Cold start. If no instance is running, the first request has to wait until one has started and your code has loaded. For a nightly import that doesn't matter, for a page that a person is waiting for it does. Lesson 3.13.4 measures it and mitigates it.
That fits work that comes in bursts and reacts to events: a nightly import, messages from a queue, a new file in Blob Storage, a workflow with waiting times. It fits poorly for work that runs all the time, holds a lot of memory in the process or needs long connections.