Dall'archivio articoli > Container Apps
Introduzione a Azure Container Apps
- 0
- 0
- 0
Per poter utilizzare questa funzionalità, devi fare il login o iscriverti.
Nella distribuzione delle applicazioni il cloud è ormai diventato di uso quotidiano per i suoi innegabili vantaggi. E' evoluto nel tempo, partendo prima dall'Infrastructure as a Service (IaaS) per offrire macchine virtuali che ci scaricassero dalla gestione fisica. Affianco ad essi sono arrivati i Platform as a Service (PaaS) che, facendo un passo in più, si presentano scaricandoci anche dall'onere della gestione software, quanto meno in buona parte. Poi è arrivato Docker che con la tecnologia dei container ha introdotto quella possibilità di poter distribuire applicativi indipendentemente da dove essi girano, semplificando enormemente questo passaggio. Infine, è arrivato il serverless o Functions as a Service (FaaS), che ha introdotto un modello orientato agli eventi facendoci dimenticare completamente degli aspetti computazionali e di memoria.
Guardando tutte queste funzionalità, però, non si può certo dire che un modello soppianti l'altro. PaaS non ha quella flessibilità di distribuzione e in parte ci obbliga ad accoppiarci alla piattaforma cloud, mentre i container, che risolvono questo problema, in fin dei conti, non sono altro che uno IaaS fatto bene. Tutto semplice quando distribuiamo container state-less, più difficile, invece, quando ospitiamo service broker, database e applicativi state-full. Anche Kubernetes (K8S) usato in molti casi per orchestrare i container, non si può certo dire che sia facile da usare, sebbene allo stesso tempo molto potente. Per questo motivo un approccio ibrido, basato su servizi PaaS per le parti state-full, come i database, può rappresentare la scelta migliore. Infine, il FaaS, putroppo in molte implementazioni ha il difetto di richiedere uno sviluppo specifico per la piattaforma in cui gira ed è utilizzabile principalmente solo per scenari orientati agli eventi.
Azure Container Apps vogliono risolvere tutti questi limiti prendendo allo stesso tempo i pregi di ogni metodologia di distribuzione. In questo articolo vogliamo introdurre come muovere i primi passi con questo nuovo servizio offerto dalla piattaforma Microsoft Azure e capire dove può sostituirsi rispetto agli attuali strumenti di deployment.
Nell'ecosistema di Microsoft Azure sono presenti tipologie diverse di servizi basati sui container. Gli App Service sono un servizio PaaS che oltre al normale deployment consentono di creare container. Tutto viene esposto tramite il gateway di Microsoft e si gestisce tutto autonomamente: scalabilità verticale e orizzontale, spazio di archiviazione e logging. Non permette però di scalare facilmente o di ridurre, se necessario a zero, il costo dell'hosting ed è l'ideale principalmente per applicativi che devono rispondere via HTTP. Container Instances, invece, ci permettono di esporre o meno i nostri container, però non hanno una flessibilità nelle scalabilità, costringendoci ad un dimensionamento fisso delle risorse. Le Functions, supportano anch'esse i container, hanno un ottimo grado di flessibilità, sono orientate agli eventi, ma ci obbligano ad uno sviluppo specifico per la piattaforma, dimostrandosi poco adatte per ospitare applicativi web. Kubernetes Service, richiede la definizione di un cluster e sebbene permetta una certa dinamicità dei nodi virtuali, si presta meno bene ad un approccio ad eventi.
Azure Container Apps vuole porsi come obbiettivo quello di sfruttare tutti i vantaggi dei container, ma allo stesso tempo fornire scalabilità orizzontale, supporto al traffico HTTP e facilitare nella creazione di microservizi. E' l'ideale per distribuire API, per ospitare processi in background, per lavorare ad eventi e in generale per distribuire container ad alta densità, come nelle architetture a microservizi.
La scalabilità è affidata a KEDA (Kubernetes Event-driven Autoscaling) in base al traffico HTTP, al numero di eventi da processare, ai carichi di CPU o di memoria e più in generale ad uno degli scaler supportati dalla piattaforma. Sono quindi consentiti tutti i principali servizi PaaS disponibili su Azure, come database, code e storage, perché, come detto, un approccio ibrido è sicuramente il più vincente.
(fonte: docs.microsoft.com)
Azure Container Apps supporta l'ingress HTTP/HTTPS con la possibilità di suddividere il traffico per supportare eventuali transizioni per i tipici scenari di A/B testing o blue/green deployment. Fornisce un supporto centralizzato al logging, sfruttando Azure Log Analytics, una centralizzazione dei secrets per tenere al sicuro le configurazioni delle app ed infine un'integrazione nativa a Dapr (Distributed Application Runtime). Si tratta di uno progetto open source, sviluppato da Microsoft, che ha lo scopo di semplificare la maggior parte dei task necessari nei microservizi, come il logging e il tracing, la configurazione, la gestione dello stato, il binding verso risorse interne o esterne. Oltre alla semplificazione, essendo uno strumento basato su container, ci permette di scrivere soluzioni che sfruttano i servizi PaaS di Microsoft Azure, ma allo stesso tempo di astrarci permettendoci eventualmente di staccarci e di sfruttare un altro hosting cloud.
(fonte: docs.dapr.io)
Non siamo obbligati ad usare questo runtime/layer aggiuntivo, restando su un approccio tradizionale, basato sugli SDK specifici di ogni servizio, ma sicuramente vale la pena prenderlo in considerazione.
Dopo aver introdotto i concetti fondamentali, partiamo creando una prima app che sfrutti questo servizio.
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.