Scegliere un'opzione di calcolo di Azure per i microservizi

Questo articolo illustra come scegliere una piattaforma di calcolo di Azure per un carico di lavoro basato su un'architettura di microservizi. Un'architettura di microservizi è costituita da piccoli servizi distribuibili indipendentemente che comunicano in rete. La piattaforma di calcolo deve supportare la scalabilità indipendente, la distribuzione indipendente e la comunicazione affidabile tra più servizi.

Per i fattori decisionali che si applicano a qualsiasi carico di lavoro, ad esempio competenze del team, rete e portabilità, vedere Scegliere un servizio di calcolo di Azure. Questo articolo è incentrato sui fattori importanti in particolare per i microservizi.

Piattaforme di calcolo di Azure per microservizi

Le piattaforme di Azure seguenti supportano i carichi di lavoro dei microservizi. Differiscono nel livello di orchestrazione, comunicazione interservizi e comportamento di scalabilità che offrono.

Il servizio Azure Kubernetes (AKS)

Il servizio Azure Kubernetes è un servizio Kubernetes gestito che fornisce l'accesso diretto alle API Kubernetes e al piano di controllo. Il servizio Azure Kubernetes (AKS) fornisce la gestione dei nodi, l'applicazione di patch e gli aggiornamenti automatici facoltativi. Configuri il cluster, la rete e le politiche di ridimensionamento.

Per i microservizi, il servizio Azure Kubernetes supporta mesh di servizi come Istio per la gestione del traffico e la mutual transport Layer Security (mTLS), il ridimensionamento per distribuzione tramite la scalabilità automatica orizzontale dei pod (HPA) e la scalabilità automatica guidata dagli eventi Kubernetes (KEDA) e le strategie di distribuzione native di Kubernetes, come gli aggiornamenti in sequenza e le versioni canary.

AKS Automatic è una modalità del servizio Azure Kubernetes che preconfigura la gestione dei nodi, il ridimensionamento, la sicurezza e l'osservabilità in base alle raccomandazioni ben strutturate del servizio Azure Kubernetes, in modo che i team ottengano un cluster pronto per la produzione senza una configurazione per funzionalità.

App contenitore di Azure

App Azure Container è un servizio gestito basato su Kubernetes che astrae la gestione dei cluster.

App contenitore offre funzionalità predefinite per i microservizi, tra cui l'individuazione dei servizi, l'integrazione Dapr per l'invocazione da servizio a servizio con mTLS, messaggistica publisher-subscriber e gestione dello stato. La scalabilità automatica basata su KEDA consente il ridimensionamento basato su eventi, inclusa la scalabilità a zero. Le Container Apps supportano anche la funzione di suddivisione del traffico tra le revisioni per distribuzioni canary e i job per attività su richiesta, pianificate o guidate dagli eventi.

Le Container Apps non espongono le API di Kubernetes. Se la configurazione del tooling di distribuzione o della mesh del servizio dipende dalle primitive di Kubernetes, utilizzare invece AKS.

Azure Functions

Funzioni di Azure è un servizio di calcolo basato su eventi serverless adatto per i microservizi che rispondono a trigger come richieste HTTP, messaggi di coda o timer. Le funzioni ridimensionano ogni app per le funzioni in modo indipendente e possono essere ridimensionate a zero. Per i microservizi, distribuisci ogni servizio come un'applicazione di funzione dedicata.

Le funzioni non forniscono l'individuazione dei servizi a livello di piattaforma o la comunicazione tra servizi. Implementare queste funzionalità nel codice dell'applicazione o tramite servizi esterni come Gestione API di Azure.

Funzioni supporta più linguaggi di programmazione. È anche possibile eseguire il modello di programmazione Funzioni nelle App di contenitore, che combina trigger e associazioni di Funzioni con le funzionalità di rete e ridimensionamento delle Container Apps.

Servizio app di Azure

Il servizio app di Azure è adatto ai microservizi basati su HTTP, ad esempio le API Web. Il servizio app supporta la distribuzione come codice o come singolo contenitore. Offre scalabilità automatica predefinita, slot di distribuzione per distribuzioni blu-verde e routing del traffico in percentuale e integrazione con pipeline di integrazione continua e recapito continuo (CI/CD). Il servizio app non fornisce l'individuazione dei servizi, pertanto si adatta ai microservizi che comunicano tramite messaggistica esterna o un gateway API anziché basarsi sulla comunicazione tra servizi a livello di piattaforma.

Azure Red Hat OpenShift

Azure Red Hat OpenShift offre cluster OpenShift completamente gestiti ed estende Kubernetes con un'esperienza di sviluppo opinionata. Red Hat e Microsoft progettano, operano e supportano congiuntamente il servizio. Usare Azure Red Hat OpenShift quando l'organizzazione standardizza in OpenShift.

Confrontare le piattaforme per i microservizi

La tabella seguente confronta il modo in cui ogni piattaforma supporta le funzionalità importanti per un'architettura di microservizi. Per un confronto più dettagliato delle piattaforme di hosting dei contenitori di Azure e delle relative funzionalità, vedere Scegliere un servizio contenitore di Azure.

Il livello dell'app in questa tabella indica che la piattaforma non fornisce la funzionalità come funzionalità predefinita. La si implementa nel codice dell'applicazione tramite un SDK o un servizio esterno, che introduce una dipendenza da tale servizio.

Scegliere la piattaforma

• Inizia con Container Apps quando si vogliono primitive predefinite per microservizi, come l'individuazione dei servizi, Dapr, e la scalabilità delle app, inclusa la scalabilità a zero, senza alcuna gestione del cluster necessaria.

• Scegli AKS quando hai bisogno di accesso diretto all'API Kubernetes, configurazione personalizzata del mesh di servizio, o controllo dettagliato dell'infrastruttura del cluster come pool di nodi, politiche di rete, o vincoli di pianificazione.

• Usare Funzioni per i microservizi orientati agli eventi con modelli di traffico sporadico o con picchi improvvisi che traggono vantaggio dalla fatturazione scalabile fino a zero e dall'esecuzione basata su trigger.

• Usare il servizio app per servizi semplici basati su HTTP che non necessitano di funzionalità di individuazione dei servizi a livello di piattaforma o di comunicazione tra servizi.

Il carico di lavoro dei microservizi non deve essere eseguito in una singola piattaforma. Ad esempio, è possibile eseguire i servizi di base nel servizio Azure Kubernetes o nelle app contenitore, mentre Funzioni gestisce i carichi di lavoro basati sugli eventi. Valutare ogni servizio nella composizione in base al proprio modello di traffico, ai requisiti di scalabilità e alle esigenze di comunicazione. Scegliere la piattaforma adatta al servizio invece di forzare il servizio a adattarsi alla piattaforma.

Fattori decisionali chiave

La tabella di confronto mostra il supporto di ogni piattaforma. Le sezioni seguenti consentono di valutare tali funzionalità in base alle problematiche dei microservizi più importanti per il carico di lavoro.

Comunicazione tra i servizi

I microservizi dipendono dalla comunicazione affidabile da servizio a servizio con funzionalità come l'individuazione dei servizi, le ripetizioni e il mutual TLS (mTLS).

Se l'architettura dipende dalle chiamate sincrone da servizio a servizio in molti servizi, assegnare priorità a una piattaforma con primitive di comunicazione predefinite. Container Apps forniscono queste primitive tramite Dapr senza infrastruttura aggiuntiva. AKS li fornisce tramite mesh di servizio come Istio, che consentono di controllare i criteri di traffico, i tentativi e l'interruzione del circuito a livello di mesh. È possibile gestire il ciclo di vita della mesh, la configurazione e gli aggiornamenti.

Se i servizi comunicano principalmente tramite messaggistica asincrona come code o flussi di eventi, le funzionalità di comunicazione predefinite della piattaforma sono meno importanti perché è necessario interagire con tali servizi tramite un SDK o un'astrazione. Usare il modello asincrono Request-Reply per le operazioni a esecuzione prolungata perché i timeout della piattaforma possono diventare un problema. Ad esempio, Funzioni e Servizio app applicano un timeout di risposta HTTP di 230 secondi a causa dei limiti di Azure Load Balancer.

Scalabilità indipendente

Ogni microservizio in una composizione presenta caratteristiche di carico diverse.

Se i tuoi servizi hanno traffico altamente variabile o improvviso, Container Apps e Funzioni si ridimensionano per servizio e possono ridurre i servizi inattivi a zero. Questo approccio evita addebiti per la capacità inutilizzata. Per le funzioni, ogni function app è l'unità di ridimensionamento, quindi distribuisci ogni microservizio come una propria function app. AKS offre scalabilità a livello di singola distribuzione. Gestisci i pool di nodi condivisi che rimangono forniti, e i pool di nodi utente possono essere ridimensionati a zero.

Le piattaforme a scalabilità zero introducono latenza di avvio a freddo quando un servizio inattivo riceve la prima richiesta. In un'architettura di microservizi, una singola richiesta utente può attraversare più servizi. Se diversi servizi nella catena di chiamate sono inattivi, la latenza si accumula. Per le chiamate interservizie sincrone che richiedono una bassa latenza, usare le funzionalità di mitigazione dell'avvio a freddo della piattaforma o pagare il costo per mantenere attive le istanze minime per evitare l'avvio a freddo.

Se i servizi hanno un carico costante e prevedibile, Azure Kubernetes Service (AKS) o Azure App Service possono ridurre i costi perché si paga per la capacità riservata anziché per la fatturazione basata sul consumo.

Distribuibilità indipendente

È necessario distribuire, aggiornare ed eseguire il rollback di singoli microservizi senza influire sul resto del sistema. Tutte e quattro le piattaforme supportano la distribuibilità indipendente, ma differiscono in base alla modalità di convalida delle modifiche. Le Container Apps e AKS offrono la suddivisione del traffico in modo nativo per le implementazioni graduali. App Service supporta il routing del traffico basato su percentuale tra gli slot di distribuzione. Funzioni supporta gli slot di distribuzione nei piani Premium e Dedicato.

Osservabilità distribuita

Una singola richiesta utente può attraversare molti servizi. Se sono necessarie tracce correlate nella catena di chiamate completa, verificare che gli strumenti di osservabilità della piattaforma si integrino con la strategia di traccia. Container Apps offre un'osservabilità predefinita con il tracciamento Dapr. AKS si integra con OpenTelemetry e strumenti di tracciamento open source, che ti consentono di scegliere il tuo back-end di tracciamento (ad esempio Jaeger, Zipkin o Monitoraggio di Azure), ma richiede la distribuzione e la configurazione della pipeline di raccolta. Funzioni e servizio app si integrano con Application Insights per la traccia delle transazioni end-to-end con una configurazione minima.

Assicurarsi che ogni servizio nella composizione esponga metriche per servizio, ad esempio frequenza delle richieste, frequenza degli errori e latenza. Queste metriche consentono di identificare il servizio danneggiato senza correlare i log nella catena di chiamate completa.

Gestione dello stato

In un'architettura di microservizi, ogni servizio è in genere proprietario dei dati ed esterna lo stato a un database o a una cache dedicata. Questo modello mantiene i servizi distribuibili in modo indipendente e tutte e quattro le piattaforme lo supportano ugualmente perché l'archivio dati è una risorsa di Azure separata.

Le piattaforme differiscono quando un servizio necessita di astrazioni dello stato gestito dalla piattaforma, ad esempio modelli basati su attori, orchestrazione del flusso di lavoro o archiviazione dedicata per ogni istanza:

• AKS offre la massima flessibilità tramite volumi persistenti e StatefulSets, che supportano gli archivi dati nel cluster e l'identità stabile per ogni istanza.

• Container Apps supporta i montaggi di volumi e la gestione dello stato Dapr, inclusi gli attori Dapr.

• Funzioni supporta orchestrazioni ed entità con stato tramite Durable Functions.

• Il Servizio App supporta lo storage condiviso tramite i montaggi di Azure Files, ma non fornisce archiviazione per istanza o astrazione dello stato a livello di piattaforma.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Well-Architected Framework.

Affidabilità

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni assunti dai clienti. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'affidabilità.

In un'architettura di microservizi, il rischio di affidabilità principale è un errore a catena. Un servizio non integro causa l'accumulo di timeout da parte dei chiamanti e il problema si propaga verso l'esterno attraverso la catena di chiamate. La scelta della piattaforma influisce su come attenuare questo rischio.

• Azure Kubernetes Service e le applicazioni container forniscono controlli di stato a livello di piattaforma che rilevano istanze problematiche e le rimuovono automaticamente dalla rotazione.

• Le funzioni ritentano le esecuzioni non riuscite in base al tipo di trigger.

Indipendentemente dalla piattaforma, implementare interruttori, criteri di ripetizione dei tentativi con arretramento e timeout nella comunicazione tra servizi per evitare che il malfunzionamento di un singolo servizio si trasformi in un'interruzione dell'intero sistema.

Distribuire ogni servizio tra zone di disponibilità per proteggersi da errori a livello di data center. In una composizione multipiattaforma, verificare che tutte le piattaforme in uso supportino la ridondanza zonale per l'area di distribuzione.

Per indicazioni sull'affidabilità specifiche della piattaforma, vedere le sezioni sull'affidabilità delle guide al servizio Well-Architected Framework per AKS, Container Apps e Funzioni.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'uso improprio dei dati e dei sistemi preziosi. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per la sicurezza.

I microservizi aumentano la superficie di attacco perché ogni chiamata da servizio a servizio supera un limite di rete. Considerare tutto il traffico interservizio come non attendibile e crittografarlo tramite mTLS. AKS supporta mTLS tramite service mesh come Istio. Le App container forniscono mTLS tramite Dapr o configurazione a livello di ambiente. Le funzioni e il servizio app non forniscono mTLS a livello di piattaforma. Se quelle piattaforme ospitano servizi nella tua architettura, applica la sicurezza del trasporto tramite HTTPS a livello di applicazione, politiche del gateway API o isolamento della rete virtuale.

In una composizione di molti servizi, ogni servizio deve eseguire l'autenticazione solo per le risorse necessarie. Assegnare identità per servizio anziché condividere una singola identità nel carico di lavoro. Per i meccanismi specifici della piattaforma, vedere la riga identity per servizio nella tabella di confronto.

Per indicazioni sulla sicurezza specifiche della piattaforma, vedere le sezioni relative alla sicurezza delle guide dei servizi Well-Architected Framework per AKS, Container Apps e Functions.

Ottimizzazione dei costi

L'ottimizzazione dei costi è incentrata sui modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'ottimizzazione dei costi.

Un'architettura di microservizi può includere decine di servizi e ogni servizio gestisce volumi di traffico diversi. Associare ogni servizio al modello di fatturazione adatto al modello di traffico. Le piattaforme basate sul consumo, come Container Apps e Funzioni, ridimensionano i servizi inattivi a zero, ma risorse di calcolo dedicate come AKS possono essere più convenienti per i servizi che hanno un carico costante. In una composizione multipiattaforma, la flessibilità di fatturazione per servizio è uno dei principali vantaggi dei costi. Tuttavia, tenere conto del sovraccarico legato alla gestione di pipeline di distribuzione separate, configurazioni di monitoraggio e competenze del team su diverse piattaforme.

Per indicazioni sui costi specifiche della piattaforma, vedere le sezioni relative all'ottimizzazione dei costi delle guide al servizio Well-Architected Framework per AKS, Container Apps e Functions.

Architetture di riferimento

Limitare le opzioni a una o due piattaforme applicando i criteri di confronto in questo articolo. Eseguire un modello di verifica distribuendo un sottoinsieme rappresentativo dei servizi e testando le comunicazioni tra servizi, il comportamento di ridimensionamento e i flussi di lavoro di distribuzione in base ai requisiti. Verificare che la piattaforma soddisfi le aspettative operative del team prima di impegnarsi nell'ambiente di produzione. Le architetture seguenti forniscono punti di partenza pronti per la produzione:

• Architettura del servizio Azure Kubernetes:Baseline per un cluster del servizio Azure Kubernetes
• Container Apps:Microservizi con Container Apps e Dapr
• Servizio app:Applicazione web di base con alta disponibilità e ridondanza zonale
• Azure Red Hat OpenShift:Azure Red Hat OpenShift in un ambiente ibrido

Passaggio successivo

Risorse correlate

• Progettare un'architettura di microservizi
• Progettare API per microservizi
• Usare l'analisi del dominio per modellare i microservizi
• Scegliere un servizio di calcolo di Azure
• Scegliere un servizio contenitore di Azure
• Considerazioni sull'architettura per la scelta di un servizio Azure Container