Il problema di design: quanto controllo, a quale costo operativo

Nella progettazione di soluzioni Azure, la scelta del servizio di compute non è una questione di preferenza tecnologica ma di allineamento tra requisiti non funzionali e modello di responsabilità. L’asse decisionale principale è il compromesso tra livello di controllo (accesso all’OS, al runtime, all’orchestrazione) e overhead operativo (patching, scaling, gestione del cluster). Nel linguaggio dell’Azure Well-Architected Framework, questo è il punto di frizione tra il pilastro Operational Excellence e le esigenze di portabilità o personalizzazione. In parallelo, il pilastro Cost Optimization impone di considerare non solo il costo di calcolo ma il costo totale di proprietà, inclusi tempo del team e complessità.

La regola guida da architetto: scendi di astrazione solo quando un requisito concreto lo impone. Ogni livello di controllo aggiuntivo è debito operativo che qualcuno dovrà ripagare.

Il decision tree

1. Serve accesso completo all’OS, driver custom, software legacy o GPU con configurazione specifica? → Azure Virtual Machines (o VM Scale Sets per scaling). Massimo controllo, massimo overhead: sei responsabile di patching, hardening e scaling. Sceglila per lift-and-shift, workload stateful non containerizzabili, licenze legate all’host. Costo ottimizzabile con Reserved Instances, Savings Plans e Spot per carichi interrompibili.

2. È un’applicazione web o API standard (stack supportato: .NET, Java, Node, Python), senza necessità di controllare l’infrastruttura? → Azure App Service. PaaS maturo con deployment slot, autoscale, backup e certificati gestiti. Overhead operativo minimo. È la scelta di default per web app “classiche” quando non servono container avanzati.

3. Il workload è containerizzato ma non richiede l’ecosistema Kubernetes completo? → Azure Container Apps. Costruito su Kubernetes e KEDA ma senza esporre il piano di controllo: microservizi, event-driven, scale-to-zero, revisioni e traffic splitting nativi. È il punto di equilibrio moderno tra controllo e semplicità, e la risposta corretta nella maggior parte degli scenari containerizzati greenfield.

4. Serve controllo granulare su networking, service mesh, operatori custom, scheduling avanzato o multi-tenancy complessa? → Azure Kubernetes Service (AKS). Massima flessibilità sui container, ma erediti la gestione di node pool, upgrade, CNI, RBAC del cluster. Giustificata solo da complessità reale o competenze Kubernetes già presenti in azienda.

5. È logica event-driven, short-lived, con esecuzione a burst e trigger discreti (HTTP, queue, timer)? → Azure Functions. FaaS con consumption plan che paga per esecuzione e scala a zero. Ideale per integrazione, elaborazione asincrona e automazioni. Il Premium plan risolve cold start e VNet integration quando la latenza conta.

Collegamento ai pilastri WAF

  • Cost Optimization: i modelli con scale-to-zero (Functions Consumption, Container Apps) eliminano il costo dell’idle e sono imbattibili su carichi intermittenti. Ma con traffico costante e alto volume, un piano dedicato o VMSS reserved può risultare più economico del consumo. Non confondere “serverless” con “sempre più economico”.
  • Operational Excellence: più il servizio è gestito, più il team si concentra sul valore applicativo. AKS massimizza il controllo ma introduce un onere di Day-2 operations (upgrade cluster, sicurezza dei nodi, osservabilità) che va quantificato in FTE, non ignorato.

Trappole tipiche d’esame

  • Scenario: microservizi containerizzati, event-driven, team piccolo senza esperienza Kubernetes → NON AKS, scegli Azure Container Apps. L’errore classico è adottare AKS quando Container Apps copre già scaling, revisioni e networking senza esporre il cluster. AKS aggiunge overhead operativo non giustificato.
  • Scenario: web app .NET standard con requisito di deployment slot e minimo effort operativo → Azure App Service, non VM né AKS. Introdurre container qui è over-engineering.
  • Scenario: elaborazione a burst innescata da messaggi in coda, idle per lunghi periodi, requisito di costo minimo → Azure Functions su Consumption plan (scale-to-zero). Una VM o un App Service sempre attivo paga l’idle.
  • Scenario: applicazione con carico costante 24/7 e alto throughput, requisito “minimizzare il costo” → attenzione al serverless. Con utilizzo prossimo al 100% un piano dedicato con Reserved Instances batte spesso il modello a consumo: qui il costo per esecuzione non conviene.
  • Scenario: software legacy che richiede accesso all’OS, driver kernel o licenze legate all’hardware → Virtual Machines, non PaaS. Nessun servizio gestito espone questo livello di controllo.
  • Scenario: requisito esplicito di service mesh custom, operatori Kubernetes specifici o controllo del CNI → allora sì, AKS. Se il requisito non nomina nessuna di queste esigenze, AKS è quasi sempre la risposta sbagliata perché sottostima il costo operativo di gestire i cluster.

Principio riassuntivo: parti dal livello di astrazione più alto e scendi solo quando un requisito documentato lo richiede. In sede d’esame, la risposta “corretta” è tipicamente quella che soddisfa il requisito con il minor overhead operativo e costo totale, non quella tecnicamente più potente.