I sidecar nell’architettura di microservizi: ruolo, sfide e best practice

In un’architettura basata su microservizi, sono tantissimi i servizi dinamici e distribuiti che passano attraverso i sistemi applicativi. Hanno spesso anche la necessità di comunicare tra loro internamente e con componenti di terze parti esternamente. Le interazioni sono continue e numerose, tanto da diventare un aspetto sfidante.

Per gestire i servizi distribuiti e le comunicazioni tra componenti, si punta spesso al service mesh pattern. Questo metodo, molto noto, si basa sull’utilizzo di un’istanza proxy che intercetta e favorisce la comunicazione tra servizi. Nella maggior parte dei casi questo meccanismo è chiamato sidecar, sidecar proxy o, in alcuni casi, sidecar container.

Partendo dalla sua implementazione all’interno di un’architettura di microservizi, nelle prossime righe se ne illustrano le principali caratteristiche, il funzionamento e i vantaggi derivanti. Ci sono anche alcune criticità di cui sviluppatori e architetti dovrebbero tener conto, ma altrettante best practice che li possono supportare nell’utilizzo di sidecar.

Service mesh e sidecar

I sidecar sono direttamente associati al service mesh pattern, uno strato infrastrutturale a bassa latenza che gestisce grandi volumi di comunicazione tra servizi applicativi. Il suo core è la semplificazione di criticità trasversali come il routing, la resilienza, la sicurezza e l’osservabilità. Alcune delle più note implementazioni proprietarie di service mesh includono Istio, Consul, Nginx Service Mesh e AWS App Mesh.

Il sidecar si collega a ogni servizio all’interno di un’applicazione distribuita e può stabilire connessioni a ogni macchina virtuale o istanza di container necessaria per eseguire operazioni di routine. È molto adatto a gestire tutte quelle tipologie di operazioni che non hanno a che fare con i singoli servizi, come i sistemi di monitoraggio e i controlli del protocollo di sicurezza.

Benefici dei sidecar per i microservizi

Service mesh e sidecar sono diventati parte integrante delle architetture di microservizi perché possono controllare la comunicazione da servizio a servizio, gestire l’instradamento delle richieste, fornire fault tolerance e aiutare a mantenere un’alta disponibilità. I sidecar possono anche fornire un supporto diretto per compiti essenziali di gestione dei microservizi, come il service discovery e il distributed tracing

Il sidecar permette anche ai vari componenti di accedere ai servizi da qualsiasi luogo o utilizzando qualsiasi linguaggio. Come meccanismo di communication proxy, il sidecar può anche agire come un traduttore per la gestione delle dipendenze cross-language. Un vantaggio per le applicazioni distribuite con requisiti di integrazione particolarmente complessi, ma anche per i sistemi applicativi basati su integrazioni aziendali esterne, servizi di gestione e strumenti di sviluppo.

Best practice per implementare sidecar

L’uso dei sidecar nelle architetture di microservizi porta molti vantaggi, ma la retrostante tecnologia non è facile da impostare e mantenere. Quando non è gestita correttamente, la loro presenza può far aumentare la latenza nelle comunicazioni di rete, invece di semplificarle.

Aggiungere sidecar ad ambienti già complessi, inoltre, può complicare lo sviluppo e la gestione delle applicazioni. È essenziale che sviluppatori e team di operation acquisiscano familiarità con questo nuovo livello di servizio, comprendendone funzionamento e impatto sulle applicazioni. Per farlo, devono già saper gestire i container in un sistema distribuito di microservizi, considerando che il service mesh è spesso distribuito su container orchestrator come Kubernetes.

I sidecar possono portare anche dei rischi, ad esempio quando si tratta di meccanismi di retry per le transazioni fallite. Gli architetti del software spesso integrano nei servizi la possibilità di riprovare le transazioni fallite, per evitare di arrestare inutilmente i processi applicativi associati. Molti fornitori di reti di servizi proprietari assegnano ai sidecar questa stessa capacità. Quando più meccanismi di retry vengono eseguiti l’uno accanto all’altro, c’è il rischio di duplicazione delle transazioni. Oltre a prosciugare risorse vitali, questo inconveniente rende problematici i livelli di prestazione dell’applicazione stessa.

Per ottenere il massimo dai sidecar nel mondo dei microservizi (ed evitare alcune delle insidie appena esposte) è consigliabile applicare queste best practice fin dall’inizio:

• Usare i sidecar solo quando è necessario. Se un’applicazione contiene solo pochi servizi di base non soggetti a frequenti errori di comunicazione, non è opportuno puntare su service mesh e sidecar. Aggiungerebbero complessità e spese di gestione senza portare alcun vantaggio
• Creare dashboard centralizzate per il monitoraggio e il request tracing. Dato che i sidecar sono utilizzati in presenza di grandi volumi di traffico distribuito, è necessario fornire al team DevOps dashboard centralizzate per non perdere visibilità su ciò che accade, eseguire un efficiente request tracing e accedere facilmente ai log degli errori.
• Considerare l’aggiunta di misure di network sicurezza extra. La maggior parte dei service mesh sono dotati di un set di base di funzioni di sicurezza, come la gestione dei certificati e gli strumenti di autenticazione e autorizzazione. Può essere opportuno, però, applicare ulteriori restrizioni di rete sui sidecar dedicati alla comunicazione tra servizi sensibili che risiedono in determinati container.