Eseguire container su Azure significa scegliere tra tre servizi con livelli di astrazione molto diversi. Il criterio guida è sempre lo stesso: quanto controllo serve rispetto a quanto overhead operativo si è disposti a gestire. Come Azure Administrator devi saper mappare uno scenario al servizio giusto, non configurare Kubernetes a mano.

Azure Container Instances (ACI)

ACI è l’opzione serverless più semplice: esegui un container (o un piccolo container group che condivide rete e storage) senza gestire alcuna VM. Paghi al secondo per vCPU e memoria allocate, quindi è ideale per carichi effimeri e burst: job batch, task pianificati, elaborazioni CI/CD, code processing occasionale.

Punti chiave a livello architetturale:

  • Nessun orchestratore: niente self-healing avanzato, niente rolling update automatici, niente autoscaling nativo.
  • Supporta restart policy (Always, OnFailure, Never), integrazione con virtual network per isolamento, e managed identity per accedere ad altre risorse Azure senza credenziali.
  • Può fungere da burst target per AKS tramite Virtual Kubelet / Virtual Nodes, aggiungendo capacità elastica senza aggiungere nodi reali.

Scegli ACI quando il carico è isolato, di breve durata o imprevedibile e non giustifica un cluster.

Azure Container Apps

Azure Container Apps è la piattaforma serverless per microservizi, costruita su Kubernetes e Dapr ma senza esporne la complessità. Non gestisci control plane né node pool: lavori con environment, revisions e ingress.

Caratteristiche distintive:

  • Scale-to-zero e autoscaling event-driven basato su KEDA: puoi scalare su HTTP, su lunghezza di una coda (Service Bus, Storage Queue), su eventi Event Hubs, ecc. Perfetto per API a traffico intermittente e worker guidati da messaggi.
  • Revisions per blue-green e traffic splitting percentuale tra versioni (canary).
  • Dapr integrato per service discovery, pub/sub e state management tra microservizi.

È la scelta d’elezione quando vuoi microservizi containerizzati con operatività minima, ma non ti servono controlli Kubernetes di basso livello (CRD custom, operator, DaemonSet, tuning fine dello scheduler).

Azure Kubernetes Service (AKS)

AKS offre Kubernetes gestito completo: massimo controllo, massima flessibilità. Azure gestisce il control plane (gratuito nella tier base; a pagamento con SLA nel tier Standard), ma tu gestisci i node pool.

Elementi che l’Administrator deve conoscere:

  • System node pool (per i pod di sistema) separato dagli user node pool; scelta della VM size, cluster autoscaler e spot node pool per ridurre i costi.
  • High availability tramite distribuzione su availability zones e più node pool.
  • Networking: Azure CNI (IP dai subnet della VNet, integrazione diretta) vs kubenet (più semplice, meno IP), più network policy per il traffico est-ovest.
  • Integrazione con Microsoft Entra ID per l’autenticazione e Azure RBAC per l’autorizzazione, managed identity e Workload Identity per i pod.

Scegli AKS solo quando servono orchestrazione avanzata, portabilità Kubernetes o competenze specifiche già presenti in team.

Azure Container Registry (ACR)

Tutti e tre i servizi attingono le immagini da un container registry. Azure Container Registry è il registry privato gestito:

  • Tier Basic/Standard/Premium; il Premium abilita geo-replication, private endpoint e maggiore throughput.
  • ACR Tasks per buildare e patchare immagini nel cloud (anche su trigger di commit o CVE base image).
  • Accesso preferibilmente via managed identity, non con admin user/password.

Criteri di scelta

  • Controllo massimo / Kubernetes richiesto → AKS.
  • Microservizi, scale-to-zero, event-driven, poca operatività → Container Apps.
  • Container singolo, task breve, burst → ACI.

Trappole tipiche d’esame

  • Scenario: job batch notturno che gira pochi minuti, nessun bisogno di orchestrazione → ACI, non AKS (evita l’overhead di control plane e node pool).
  • Scenario: microservizi che devono scalare a zero quando la coda è vuota → Azure Container Apps con KEDA; ACI non fa autoscaling event-driven e AKS richiederebbe configurare KEDA manualmente.
  • Scenario: “serve gestire i node pool / patchare i nodi” → indica AKS; se la domanda enfatizza nessuna gestione di infrastruttura, la risposta è ACI o Container Apps.
  • Scenario: ridurre i costi di un cluster AKS per carichi tolleranti alle interruzioni → spot node pool + cluster autoscaler, non ridimensionamento manuale.
  • Scenario: immagini private replicate in più region con private endpoint → ACR tier Premium; Basic/Standard non offrono geo-replication.