Microsoft Azure services
5 / 24
Microsoft Azure

Serverless — Azure Functions

Run event-triggered code with automatic scaling and consumption-based billing.

A function has one trigger and runs when it fires. There is no server to size or patch.

A vending machine wired to the building: a coin (trigger) makes it act, and chutes connect it directly to supply and delivery (bindings) so it does not need its own plumbing. It powers down completely between customers and costs nothing while idle.

Key Concepts

1
    HTTP request          -> handle the call
    Timer (CRON)          -> nightly job
    Queue / Service Bus   -> process a message
    Blob created          -> resize the image
    Cosmos DB change feed -> react to a row change
2
Bindings are the distinguishing feature. A trigger plus declarative input and output bindings remove most of the SDK boilerplate:
3
    [FunctionName("Thumbnail")]
    public static void Run(
      [BlobTrigger("uploads/{name}")] Stream input,
      [Blob("thumbs/{name}", FileAccess.Write)] Stream output)
    {
      Resize(input, output);
    }
4
No storage client, no connection string in code — the platform wires both ends.
5
Hosting plans are the real decision.
    Consumption   scales to zero, pay per execution and GB-second.
                  Cold starts. 10-minute max (5 by default).
    Premium       pre-warmed instances: no cold start, VNet
                  integration, longer runs. Always paying for one.
    Dedicated     runs on an App Service plan you already have
    Flex Consumption  newer: scale-to-zero WITH VNet and
                  configurable always-ready instances
6
Cold start is the limitation to be honest about. A Consumption function idle for a while must start a worker and load the runtime — hundreds of milliseconds to seconds, worst on .NET and Java, better on Node and Python. Premium or Flex removes it, at a cost.
7
Durable Functions adds state. Chaining, fan-out/fan-in, waiting for human approval — covered separately, and the reason Azure's serverless story differs from a plain function runtime.
8
Scaling is per-trigger. HTTP scales on request volume; queue triggers on queue length. Watch downstream limits: a function scaling to 200 instances will exhaust a database connection pool long before it exhausts itself.
9
Functions are stateless. Anything that must persist goes to storage, and local disk survives only while the instance does.
10
What the interviewer is probing.1. "What is the trigger and binding model?" Probing: the Azure-specific feature. Stalls: "It runs on events." Moves up: one trigger plus declarative input and output bindings, so the platform wires the storage or queue client rather than your code doing it.
11
2. "Consumption or Premium plan?" Probing: cold starts against cost. Stalls: "Consumption, it is cheaper." Moves up: Consumption scales to zero but has cold starts and no VNet; Premium keeps instances warm and adds VNet integration, at the cost of always paying for one.
12
3. "Your function scales to 200 instances and the database falls over. What happened?" Probing: downstream limits. Stalls: "The database is too small." Moves up: the function scaled on its own trigger with no regard for the connection pool; cap it with concurrency limits or use a proxy.
13
4. "What do Durable Functions add?" Probing: state. Stalls: "Nothing, they are the same." Moves up: orchestration with chaining, fan-out/fan-in and waiting for human approval, with state rebuilt by replaying history.
Use cases:azure-functionsserverlessbindingsdurable-functions