Container su Azure non è (solo) sinonimo di AKS!
viviamo in un’epoca post-apocalittica (post monolitica) dove gli esseri umani vivono solo di container inseguendo la chimera dell’architettura “perfetta” (mah!). Coloro che si avvicinano nelle lande desolate (e immense) di Azure cercano riparo tra le mura di AKS, oggetto misterioso quanto pericoloso. Ma siamo sicuri che solo AKS possa dare riparo ai nostri container su Azure? Non ci sono alternative? In realtà c’è sempre almeno un motivo per NON usare AKS.. vediamo perchè
-incipit-
Mi sono sempre chiesto “perchè mai un Cloud Architect debba avere a che fare con Kubernetes? Che male ha fatto? Soprattutto quando la scelta è nata solo per “sfizio” e con la scusa tipica del “prima o poi tanto tutti lo useranno.. è meglio iniziare”. Non sono per nulla d’accordo, ma vediamo con criterio le ragioni del mio “dubbio”.
- La vera domanda è “Ho veramente bisogno di Kubernetes per i miei container?”
- La maggior parte delle volte la rispsota è: NO, A meno che tu non abbia esigenze specifiche, le soluzioni più semplici sono spesso migliori
ma soprattutto pensiamo alla vera domanda
Anche in questo caso la maggior parte delle volte la risposta è: NO Se già questo non è sufficiente a farti tornare sui tuoi passi, allora proseguiamo nell’articolo per capire perchè possiamo farne a meno.
Breve Storia delle opzioni per i nostri container su Azure
- Nel 2017 compare “Azure App Service for Containers”: PaaS per app web containerizzate, AKS è ancora in “preview”
- Nel 2018 arrivano in GA
- Azure Kubernetes Service (AKS): Kubernetes gestito, orchestrazione di livello enterprise
- Azure Container Instances (ACI): Serverless, veloce, ideale per carichi di lavoro temporanei
- Nel 2022, infine Azure Container Apps: Microservizi serverless, basati su Kubernetes
Il percorso decisionale
1. Web App for Containers
- Nato per supportare workload che prediligono sistemi operativi linux
- Consentono di utilizzare una immagine «custom» Docker per eseguire la WebApp
- Supporta tutte le funzionalità tipiche dell’AppService: Backup, Kudu, Deployment Slots, Autoscale
- Immediatamente utilizzabile da tutti i dev che sono già abituati a App Service
- Supporta dei sidecar «built-in» AI (SLM, Redis, Datadog» (fino a 9 per linux)
- Nessuna necessità di conoscere K8s!!
Limiti:
- L’utilizzo di più container con Docker Compose è deprecato
- Non ho modo di scalare orizzontalmente un singolo container -> Scalo tutti insieme
- Complica l’interazione col container in quanto è «incapsulato» nel container degli app service
- Non gestisco «revision»
- Non supporta «init» containers
- Supporta solo Applicazioni HTTP
- Tutti i container condividono lo stesse risorse compute/ram
2. Azure Container Apps
- Supporta un numero elevate di repliche
- Sotto il «cofano» ci sono tutti le tecnologie che alimentano Kubernetes: KEDA, Dapr e envoy
- Visto il supporto per KEDA, consente di scalare in base a numerose metriche, fino a gestire uno stato di «scale-to-zero» (modello «consumption»)
- Supporta l’esecuzione di «jobs» basato su eventi
- Supporta la gestione di molteplici versioni
- Custom domains e Ingress disponibili
- Gestione certificati integrata
- Esperienza Kubernetes «full-managed»
- Nessuna necessità di conoscere K8s!!
Limiti:
- Non consente l’accesso diretto alle API del K8s sottostante
- Non supporta lo «scale-up»
- Il numero di repliche è un «target» senza garanzie
- Gli ambienti vengono automaticamente eliminati dopo 90 giorni (se «idle»)
- Si applicano dei limiti per CPU e RAM per ogni container (e meno male!)
- Supporta solo Azure Container Registry e Container di tipo Main, Sidecar e init
- Supporta solo applicazioni HTTP
- Richiede di ottimizzare la dimensione delle immagini per migliorare i tempi di «startup»
3. Azure Container Instances
- Consente di gestire numerosi aspetti dei «nodi» del cluster sottostante quali volumi, rete e sicurezza
- Sotto il «cofano» c’è un pod di Hyper-V come container isolato
- Limiti di CPU e RAM ben superiori (32/256 – che ci devi fare?) e disponibilità di GPU (preview)
- E’ rapidissimo nell’avvio proprio perché lo strato sottostante condivide il kernel del sistema operativo e non deve attendere la creazione della vm
- Mantiene una cache delle immagini OS
- Supporta l’utilizzo di pool in «stand-by» per una ancor maggiore reattività
- Supporta l’utilizzo di Applicazioni NON-HTTP
- Nessuna necessità di conoscere K8s!!
Limiti:
- Supporta solo 1 Container di tipo Windows, 60 per linux
- E’ pensato per l’isolamento dei pool e quindi predilige container singoli
- Non consente di scalare se non creando manualmente diverse istanze
- Non fornisce bilanciamento o certificati
- Non è gestito da alcun orchestratore
- E’ pensato per workload temporanei/burst non per carichi continuativi
4. Azure Kubernetes Service (AKS)
Controllo completo su rete, nodi, scalabilità e ingress Orchestrazione di livello enterprise, scalabilità avanzata e personalizzazione Richiede: Team esperto, profonda conoscenza di Kubernetes
attenzione: AKS è “gestito” ma gran parte della responsabilità (come sempre) è vostra!
Elementi per poter decidere
Web App for Containers:
Container Apps:
Container Instances:
AKS:
CHIUSA
C’è sempre un motivo per non usare Kubernetes, a meno che tu non abbia davvero bisogno della sua potenza e flessibilità. Usa consapevolmente ciascun servizio di container di Azure, scegliendo la soluzione in base alle reali esigenze, e non solo per il gusto di usare Kubernetes.
a si biri
Scrivi un commento