Lo chassis di microservizi è un modello di progettazione che consente di gestire tutta una serie di criticità associate ai servizi distribuiti.
Durante la creazione dei vari servizi applicativi, gli sviluppatori devono incorporare meccanismi di gestione specifici per ogni singolo servizio. Questi requisiti sono spesso indicati come problemi trasversali (cross-cutting concerns), definizione che fa riferimento a diverse attività di sistema legate a più servizi e livelli applicativi come, per esempio:
- la raccolta di metriche
- la progettazione della sicurezza
- la creazione dei log delle applicazioni
- l’individuazione dei servizi
Chassis di microservizi: che cos’è e perché è importante
In un’architettura di microservizi, in cui un gran numero di servizi distribuiti affollano i sistemi applicativi, la gestione dei problemi trasversali non è banale e nemmeno scontata. Sebbene esistano diversi modi per risolvere le complessità, lo chassis dei microservizi è un modo efficace per alleggerire gli oneri dei programmatori. In questa guida gli esperti di TechTarget esaminano nel dettaglio il framework dello chassis dei microservizi, spiegando come implementarlo ma anche quali siano i pro e i contro.
I problemi trasversali dei microservices
Sebbene l’indipendenza sia un fondamentale dei microservices, che si tratti di un’applicazione o di un sistema, gli sviluppatori spesso devono risolvere una serie di attività correlate al loro sviluppo. Gestirle manualmente su ogni singolo micro-servizio non ha senso, dal momento che significherebbe riscrivere continuamente codice con enormi investimenti in termini di lavoro e di tempo.
Senza contare il fatto che ci sono situazioni in cui i singoli servizi condividono alcune criticità ma non altre. Per esempio, si può avere a che fare con un servizio che riguarda solo la registrazione, mentre un altro servizio riguarda la registrazione, ma anche la sicurezza e la configurazione. Indipendentemente dal fatto che si necessiti o meno di supporto per un processo, progettare un’applicazione in modo tale da avere problemi trasversali per ciascun servizio comporta sempre ridondanze di codice che risulteranno problematiche.
Aspect-Oriented Programming e chassis di microservizi: le differenze
Nello sviluppo di applicazioni aziendali, il più tradizionale metodo di riferimento per la gestione dei problemi trasversali è la programmazione orientata agli aspetti (Aspect-Oriented Programming – AOP). Questo approccio di sviluppo, invece di codificare la logica della funzionalità in ciascuno dei componenti dell’applicazione, si concentra sul mantenere la logica relativa a determinate funzionalità dell’applicazione limitata ai moduli di codice.
Il modello dello chassis di microservizi va a consolidare la logica funzionale sottostante in un unico modulo, preparandolo al riutilizzo per diversi servizi. Proprio come l’AOP divide le funzionalità dell’applicazione esterna in singole unità di codice, lo schema dello chassis crea moduli individuali per tutte le funzioni operative di back-end che proliferano nell’ecosistema dei microservices. Qualche esempio?
- configurazioni di comunicazione esterna
- routine di rilevamento dei servizi dinamici
- gestione automatizzata delle eccezioni
- gestione del registro degli errori
- traccia distribuita e aggiunta di meccanismi di ripetizione che si attivano durante gli errori intermittenti
Come implementare il modello di chassis dei microservizi
Per implementare il modello dello chassis dei microservizi, bisogna iniziare dalla creazione di librerie condivise per ogni problema trasversale associato ai servizi. Utilizzando un’API o un altro componente dell’applicazione dedicato, è poi necessario esporre tutte le funzioni relative a questo tipo di problemi, trasferendo tutte le preoccupazioni trasversali alle singole raccolte di biblioteche riutilizzabili a cui i servizi possono accedere in base alle necessità.
Come sottolineano gli esperti, è possibile che la centralizzazione dei problemi trasversali possa causare colli di bottiglia per i servizi che condividono le librerie. Per evitare che questo possa accadere le modifiche allo chassis del servizio dovrebbero essere solo occasionali, in modo che le dipendenze non possano causare problemi significativi. Se si riscontrano accoppiamenti e dipendenze problematiche, meglio tornare indietro ed esaminare se le librerie funzionali esposte sono state analizzate adeguatamente.
Progettazione di uno chassis per microservizi: le cose da sapere
Di seguito sono riportati alcuni punti aggiuntivi da tenere a mente durante la progettazione di uno chassis per microservizi:
- Mantenere il codice dello chassis il più leggero possibile, cercando attentamente eventuali ridondanze.
- Spostare le funzionalità non necessarie in una libreria di archivio separata.
- Considerare l’utilizzo di un proxy sidecar (un modello di progettazione che astrae determinate funzionalità dall’architettura principale per facilitare il monitoraggio e la manutenzione dell’applicazione nel suo insieme – ndr) per mitigare la natura agnostica dalla lingua dello chassis nel caso l’architettura dei microservizi incorpori più linguaggi.
- Evitare di testare ripetutamente lo chassis a meno di non aver alterato in modo significativo il framework sottostante.
- Garantire che la struttura dello chassis non introduca accoppiamenti o dipendenze di componenti aggiuntivi che possono influire in modo significativo sull’intero sistema.
Chassis di microservizi: i possibili svantaggi
La creazione e l’implementazione dello chassis dei microservizi impone una notevole quantità di lavoro e costi iniziali. Il vantaggio è la capacità del modello di evitare la duplicazione del codice e ottimizzare le prestazioni delle applicazioni. Detto questo, ci sono alcune questioni che vale la pena considerare prima di passare alla sua adozione:
- #1 Nell’adottare uno chassis di microservizi uno svantaggio è che in genere il modello non è indipendente dalla lingua o dalla piattaforma. Spesso gli sviluppatori devono implementare un meccanismo di chassis per ogni linguaggio e piattaforma utilizzati all’interno di un’unica architettura di microservizi. Se è vero che uno chassis di microservizi fornisce un modo elegante per gestire le preoccupazioni trasversali, è anche vero che per i servizi scritti nella stessa lingua o distribuiti dalla stessa piattaforma, il potenziale requisito per creare più chassis è uno svantaggio.
- #2 Un altro potenziale svantaggio dello chassis di microservizi è che la piattaforma globale di sviluppo o distribuzione di applicazioni di un team può già includere molte delle utilità del modello, soprattutto quando si tratta di scenari aziendali su larga scala. Per esempio, molti ambienti e piattaforme di distribuzione esistenti, come AWS e CloudBees, gestiscono già il rilevamento dei servizi. Allo stesso modo, gli odierni strumenti di service mesh spesso eseguono molte delle operazioni relative alla rete gestite da uno chassis di microservizi.
