Group 3: Serverless / Event Compute
This group handles event-driven execution. You PAY ~ proportional to events × duration. Goal: minimize idle infrastructure. Members: Azure Functions, Durable Functions (extension), Logic Apps.
Services & Core Identity
Azure Functions
Code-first functions triggered by events. Fine control over runtime, languages (.NET, Node, Python, etc.). Low cold-start (Premium/ASE). Stateless per invocation.
- Best when: custom logic, high concurrency, varied triggers.
- Scaling: event-driven; Consumption, Premium, Dedicated.
- State: external (Storage, Redis, DB) unless using Durable extension.
Durable Functions
Extension adding stateful orchestration, fan‑out/fan‑in, retries, sagas using code patterns (orchestrator + activity functions).
- Best when: complex workflows, checkpoints, human interaction.
- Patterns: Chaining, Fan-Out, Async HTTP, Monitor, Eternal.
- State persistence: orchestrator history (storage table + queues).
Logic Apps
Designer + connectors. Low-code integration, B2B (EDI/X12), SaaS orchestration. Visual workflow, managed connectors billing.
- Best when: many SaaS/API connectors, business process mapping.
- Pricing: per action/connector; Standard plan adds single-tenant.
- State & retries: built-in; visual change tracking.
Key Differences (Compact Table)
| Dimension | Functions | Durable Functions | Logic Apps |
|---|---|---|---|
| Primary Model | Stateless code units | Stateful orchestration (code) | Visual workflow / connectors |
| Orchestration Complexity | Manual | Native patterns | Visual steps |
| State Mgmt | External store | History replay + storage | Managed workflow state |
| Connector Breadth | Custom binding dev | Same as Functions | Hundreds built-in |
| Latency (median) | Low | Low–Mod (orchestrator overhead) | Mod (action overhead) |
| Long Running | Needs custom logic | Durable pattern out-of-box | Supported with runs |
| Debug Style | Code debugger | Code debugger + history | Run history & replays |
| Fan-Out Scale | Parallel via tasks | Deterministic orchestrator | Parallel branches (less granular) |
| Billing Granularity | GB-s + executions | Functions cost + storage overhead | Per action/connector (Standard = plan) |
| Vendor Lock | Code portable | Extension semantics | Connector model lock-in |
Mathematical Selection Model
Set criteria in [0..10]. Scoring functions produce preference score per service. Higher score → better fit.
Formulas
Score_Functions = 0.25*C_code + 0.20*C_volume + 0.20*C_latency + 0.15*C_state + 0.10*(10 - C_connectors) + 0.10*(10 - C_visual)
Score_Durable = 0.30*C_orchestration + 0.25*C_state + 0.15*C_code + 0.10*C_volume + 0.10*C_latency + 0.10*(10 - C_visual)
Score_LogicApps = 0.30*C_connectors + 0.20*C_visual + 0.15*C_state + 0.15*(10 - C_code) + 0.10*(10 - C_latency) + 0.10*C_orchestration
Functions {{vm.scores.functions | number:2}}
Durable {{vm.scores.durable | number:2}}
Logic Apps {{vm.scores.logicapps | number:2}}
Recommended: {{vm.recommended.name}} ({{vm.recommended.score | number:2}})
Interpretation Rules
- If C_connectors ≥ 7 AND C_code ≤ 4 → Logic Apps tends to dominate.
- If C_orchestration ≥ 6 AND (C_state ≥ 6 OR C_longrun ≥ 6) → Durable Functions wins.
- If latency critical (C_latency ≥ 7) AND volume high (C_volume ≥ 6) → Base Functions likely best.
- If all criteria mid (~5) differences are marginal; optimize for team skill.
When NOT to Use This Group
- Need constant CPU for > 30 min sustained loops → consider container or App Service.
- Need high throughput streaming analytics → see Stream Analytics / Data Explorer.
- Need heavy GPU / HPC parallel jobs → Batch / AKS.
Decision Summary (Plain English)
Use Functions when you want fast code triggers and minimal ceremony. Use Durable Functions when the process has multiple steps and you need automatic state + retry + fan-out + compensation. Use Logic Apps when integration connectors and visual workflow speed matter more than raw latency or pure code flexibility.