Le architetture a microservizi sono sempre più diffuse all’interno delle organizzazioni in quanto consentono di ottenere grande agilità con servizi più piccoli e mirati rispetto a un’architettura monolitica difficile da sviluppare e da gestire. Tuttavia, tale tipologia di architettura non è priva di sfide.
Via via che le organizzazioni creano più microservizi, la complessità aumenta. Le considerazioni relative alla governance e alla sicurezza alla base delle interazioni tra microservizi sono spesso codificate in modo personalizzato all’interno di una logica di servizio.
I team IT sviluppano in differenti linguaggi ed effettuano deploy in più ambienti, e i servizi di un’organizzazione sono in genere raccolti in silos con una gestione decentralizzata.
Il concetto di service mesh è stato introdotto per affrontare le sfide relative all’implementazione di microservizi. Una service mesh può astrarre le considerazioni sulla governance alla base dei microservizi che interagiscono principalmente tra loro.
Cos’è una Service Mesh?
Una service mesh è un modello di architettura software utilizzato per i deploy di microservizi che utilizza un proxy per consentire comunicazioni service-to-service sicure, veloci e affidabili. La maggior parte delle offerte di service mesh, come Istio, sono distribuite all’interno di un cluster Kubernetes.
Sebbene siano disponibili molti progetti di service mesh open source e altre offerte commerciali, Istio è emerso come lo standard di mercato de facto.
Il Ruolo di una Service Mesh
Storicamente, le organizzazioni che desideravano implementare funzionalità condivise dovevano scegliere tra il collegamento di librerie condivise ai propri microservizi o l'inserimento di un proxy centralizzato nell'architettura.
Le librerie potevano rivelarsi un problema per la gestione delle modifiche, mentre il proxy poteva portare a una maggiore latenza.
Un modello sidecar consente a un'organizzazione di avere un proxy locale non vincolato a un servizio, fornendo una separazione più chiara e una migliore manutenibilità nel tempo.
Utilizzando tale modello, i microservizi all'interno di una determinata distribuzione o cluster interagiscono tra loro tramite proxy sidecar. Si tratta di processi di reverse-proxy leggeri distribuiti insieme a ciascun processo di servizio in un containter separato.
I sidecar intercettano il traffico in entrata e in uscita di ogni servizio e agiscono secondo le regole di sicurezza e comunicazione specificate da un piano di controllo.
Lo sviluppatore può configurare e aggiungere policy all’interno del piano di controllo ed astrarre le considerazioni sulla governance alla base dei microservizi dal codice del servizio, indipendentemente dalla tecnologia utilizzata per crearlo.
Le policy comuni includono circuit breaker, implementazione del timeout, load balancing, rilevamento dei servizi e sicurezza (sicurezza a livello di trasporto e autenticazione reciproca).
Il concetto di service mesh si è evoluto nel tempo. Inizialmente, coloro che adottavano i microservizi abbracciavano il principio "smart endpoint and dumb pipes" per tutte le funzionalità. Ben presto hanno capito che aveva più senso fornire policy a livello di sistema per funzionalità comuni come routing, limitazione della velocità e sicurezza.
Netflix è stato il primo a separare il livello di application network, creando il famoso stack OSS che include Hystrix, Eureka e Ribbon tra gli altri. Questo è stato seguito da Envoy, un proxy distribuito ad alte prestazioni sviluppato originariamente da Lyft. Tali tecnologie hanno fornito le basi per il service mesh.
Microservizi: Le Sfide da Affrontare
Prima di passare ai microservizi, le aziende utilizzavano un approccio monolitico per sviluppare applicazioni - creando applicazioni più lente e meno affidabili e programmi di sviluppo più lunghi.
Ciò ha portato molte organizzazioni ad evolversi adottando un’architettura basata sui microservizi per scalare le proprie applicazioni in base alle esigenze aziendali.
Utilizzando un approccio a microservizi, le applicazioni più grandi e complesse sono suddivise in blocchi predefiniti più piccoli che interagiscono per offrire la funzionalità di un'applicazione altamente complessa. Applicazioni e servizi sono suddivisi in servizi più piccoli e indipendenti con forti perimetri di rete.
Sebbene sia chiaro che l’archittettura a microservizi porti molti vantaggi rispetto allo sviluppo di software con un approccio monolitico, presenta comunque delle sfide:
1. Comunicazioni Sicure tra Servizi - affinché una soluzione basata su microservizi funzioni, tutti i servizi devono comunicare tra loro tramite chiamate di rete. Ciascuna di queste chiamate di rete richiede il livello appropriato di accesso, autenticazione e autorizzazione (AAA). Per complicare ulteriormente la situazione, le esigenze di AAA possono variare da una chiamata di rete all'altra;
2. Controllo del Traffico e Tolleranza agli Errori - è necessaria una forma di gestione del traffico per dare la priorità a tutte le chiamate di rete tra i servizi. Per una serie di motivi, alcuni percorsi tra i servizi potrebbero non essere disponibili. In queste situazioni, la rete deve soddisfare le situazioni di errore o la tolleranza agli errori;
3. Gestione e Monitoraggio - in un’architettura a microservizi, i servizi sono gestiti da più team. Questi silos spesso si traducono in un’applicazione e governance delle policy in maniera incoerente. Inoltre, ognuno di questi team potrebbe utilizzare un set di strumenti DevOps per la gestione e il monitoraggio.
Per risolvere tali sfide, molte organizzazioni sono costrette a personalizzare le considerazioni sulla governance del codice dietro i microservizi nel codice del servizio stesso. Tale complessità può compromettere innovazione e agilità.
I Benefici di una Service Mesh
La service mesh è già vista come una componente cruciale per aiutare a risolvere le sfide operative nella gestione dei microservizi. Secondo Gartner e IDC, le aziende che distribuiscono microservizi alla produzione richiederanno una qualche forma di funzionalità di service mesh per scalare.
Una service mesh è utilizzata per astrarre queste considerazioni sulla governance, indipendentemente dalla tecnologia utilizzata per la creazione. La service mesh è un livello architetturale indipendente che consente:
- Governance centrale e affidabilità sulla comunicazione tra i servizi, con policy per gestire il controllo del traffico;
- protezione coerente con i criteri di autenticazione e autorizzazione;
- scoperta dei servizi in qualsiasi sviluppo di app esistente e strumenti di monitoraggio scelti.
Service Mesh e Gestione delle API
La service mesh non risolve da sola le sfide all’interno del ciclo di vita dei microservizi. Le aziende necessitano anche una modalità per pubblicare facilmente e riutilizzare i microservizi tra i team.
Inoltre, una service mesh fornisce questi vantaggi solo al set di microservizi all'interno di una distribuzione specifica. Le organizzazioni hanno bisogno di una modalità per visualizzare e gestire centralmente tutti i loro servizi, indipendentemente dalla lingua o dal modello di implementazione.
Con la piattaforma Anypoint Service Mesh, le aziende possono scoprire, gestire e proteggere tutti i servizi all'interno di qualsiasi cluster Kubernetes direttamente all'interno di Anypoint Platform.
Estendendo Anypoint Platform a qualsiasi microservizio, Anypoint Service Mesh consente di espandere il proprio appplication network a qualsiasi servizio, Mule e non Mule. Grazie all'unico piano di controllo di Anypoint Platform, è possibile:
Scoprire e Sfruttare Qualsiasi Servizio in Qualsiasi Architettura
- Comprendere le dipendenze dei microservizi utilizzando il grafico di rete dell'applicazione;
- Massimizzare l'adozione e il riutilizzo aggiungendo microservizi ad Anypoint Exchange.
Avere una Gestione Centralizzata e Garantire Scalabilità
- Garantire la resilienza tra i servizi con le policy di controllo del traffico Istio;
- Misurare ed ottimizzare le prestazioni su tutti i microservizi con l'analisi delle API.
Abilitare la Sicurezza “By Default”
- Garantire una sicurezza zero trust con policy di autenticazione e autorizzazione Istio ed Envoy.
- Aggiungere ulteriori livelli di sicurezza per i servizi rivolti ai consumatori.
Dubbi, Domande, Maggiori Informazioni?
Se vuoi avere maggiori informazioni sulla Service Mesh e su MuleSoft Anypoint Platform invia una mail a cio@florence-consulting.it o chiama lo (055) 538-3250. Visita la pagina dedicata sul nostro sito per ricevere ulteriore materiale informativo o per richiedere una demo gratuita.
In alternativa, puoi compilare il form sottostante con la tua domanda.
