Design di soluzioni serverless ed event-driven

Compute serverless: Azure Functions vs Logic Apps

Il primo bivio di design è codice vs orchestrazione visuale. Azure Functions è la scelta quando il requisito è esecuzione di logica custom event-driven, con billing al consumo (Consumption plan) o latenza garantita (Premium/Dedicated). Logic Apps è un motore di integration low-code: eccelle quando devi connettere SaaS e sistemi enterprise tramite i connettori gestiti (Office 365, SAP, Salesforce, circa 1400 connettori) senza scrivere codice di autenticazione e retry.

Regola pratica d’esame: se lo scenario cita “connect”, “workflow”, “approval”, “B2B/EDI/AS2” o “integrare sistemi esistenti senza sviluppo”, raccomanda Logic Apps. Se cita “process each message”, “trasforma il payload”, “esegui logica di business” o serve controllo fine su performance e dipendenze, raccomanda Functions. Spesso la risposta ottimale li combina: Logic App come orchestratore, Functions per gli step computazionali.

Il trade-off del cold start

Sul Consumption plan le Functions soffrono di cold start: la prima invocazione dopo un periodo di inattività può aggiungere secondi di latenza. Dato un requisito di latenza costante e prevedibile (API sincrone rivolte all’utente), la raccomandazione è il Premium plan con istanze pre-riscaldate (always-ready/pre-warmed), non il Consumption. È il classico bilanciamento tra il pilastro Cost Optimization (paghi solo l’esecuzione) e Performance Efficiency (elimini il cold start) del Azure Well-Architected Framework.

Scegliere il broker di messaging

Qui si concentrano la maggior parte delle domande AZ-305. Tre servizi, tre semantiche diverse. La scelta si guida su tre assi: ordering, delivery guarantee e throughput.

Service Bus — messaging transazionale

Azure Service Bus è un broker di messaggi enterprise. Sceglilo quando ti servono garanzie forti:

• FIFO ordering garantito tramite sessions.
• At-least-once (e effettivamente exactly-once locale via duplicate detection + PeekLock).
• Transazioni, dead-letter queue (DLQ) native, scheduled delivery, TTL.
• Pattern competing consumers (queue) e publish/subscribe (topics + subscriptions con filtri).

È la risposta corretta per ordini, pagamenti, workflow di business dove perdere o duplicare un messaggio ha impatto economico. Throughput moderato ma affidabilità massima.

Event Grid — eventi discreti e reattivi

Azure Event Grid è un router di eventi discreti (notifiche di stato: “blob creato”, “risorsa deployata”, evento custom). Modello push reattivo, latenza sub-secondo, retry con backoff e dead-lettering verso Storage. Sceglilo per architetture reactive/serverless dove diversi handler reagiscono a un cambiamento di stato. Non conserva uno stream: trasporta il fatto che qualcosa è accaduto, non un flusso continuo di dati.

Event Hubs — stream ad alto volume

Azure Event Hubs è una piattaforma di event streaming / big-data ingestion (milioni di eventi/secondo): telemetria IoT, log, click-stream, feed analytics. Modello partizionato con ordering garantito solo all’interno della singola partizione, consumo tramite consumer group e offset/checkpoint (i consumer rileggono lo stream, non “consumano ed eliminano”). Compatibile con protocollo Kafka. Sceglilo quando il requisito è throughput elevato + retention temporale + analytics (spesso verso Stream Analytics, Fabric o Databricks).

Matrice decisionale

Trappole tipiche d’esame

• Messaging transazionale affidabile (ordini/pagamenti) → NON Event Hubs. Event Hubs è streaming ad alto volume senza DLQ né gestione per-messaggio: la risposta corretta è Service Bus (sessions per l’ordering, dead-letter per i fallimenti).
• Latenza API costante richiesta, ma piano Consumption proposto → cold start. Con requisito di performance prevedibile raccomanda Functions Premium plan (pre-warmed), non Consumption.
• “Reagire a un blob/evento risorsa” con polling di una coda → sovradimensionato. Per eventi discreti reattivi la scelta idiomatica è Event Grid (push, retry integrato), non un consumer che fa polling su Service Bus.
• Nessuna gestione dei messaggi non processabili → assenza di dead-lettering. Se lo scenario chiede resilienza ai “poison message”, verifica che la soluzione usi DLQ di Service Bus o il dead-lettering di Event Grid; Event Hubs da solo non risolve.
• “Integrare SaaS/on-prem senza scrivere codice” → Logic Apps, non Functions. Quando il valore è nei connettori gestiti e nell’orchestrazione visuale, Logic Apps riduce codice e superficie di manutenzione (pilastro Operational Excellence).
• Ordering globale preteso su Event Hubs → impossibile. L’ordine è garantito solo per partizione: se serve ordine totale su un’entità, usa la partition key coerente o passa a Service Bus sessions.