Microservizi nell’ambito della programmazione significa una nuova architettura di sviluppo software che rivoluziona il modo di progettare le applicazioni. Grazie a logiche di programmazione granularizzate, infatti, gli sviluppatori acquisiscono maggiore controllo sulle loro applicazioni. Possono creare e aggiornare contemporaneamente i servizi in modo molto più rapido e possono apportare modifiche mirate senza doversi preoccupare del loro impatto sulle prestazioni.
A fronte di questi vantaggi, troppi team di software commettono degli errori durante la fase di migrazione che possono essere fatali. Gli esperti offrono alcuni consigli per aiutare i programmatori a spostare le loro applicazioni da un ambiente monolitico all’universo dei microservizi.
Ecco le cinque trappole più comuni che i team di software devono evitare nel passaggio a un’architettura microservices.
1. Muoversi troppo velocemente
La rapida adozione dei microservizi è uno degli errori più comuni da evitare assolutamente. Anche se i microservizi offrono la possibilità di distribuire rapidamente nuove applicazioni e aggiornamenti, la complessità intrinseca dell’architettura distribuita non è sempre e necessariamente la risposta giusta per determinati tipi di organizzazioni o applicazioni. Innanzitutto, i team di programmazione dovrebbero valutare bene la loro cultura di sviluppo per capire se esistono le giuste competenze a livello di gestione. Inoltre, dovrebbero analizzare le applicazioni esistenti per determinare se sono adatte e pronte per la migrazione ai microservizi. Tutto questo, partendo dal presupposto di lavorare attraverso i principi Agile e DevOps, dal momento che i microservizi non lavorano molto bene con un approccio di sviluppo a cascata.
I team hanno anche bisogno di una formazione mirata e dell’accesso alla documentazione prima di iniziare una migrazione di carichi di lavoro basati su monoliti.
Quando inizia la migrazione ai microservizi gli esperti sottolineano anche come, senza un piano adeguato e investimenti infrastrutturali adeguati, possono insorgere problemi di prestazioni. I team possono mitigare questi problemi solo se i servizi sono davvero sviluppati in modo indipendente l’uno dall’altro, pur comunicando normalmente.
2. Rendere i servizi troppo piccoli
Lavorare con i microservizi richiede una notevole competenza a livello di dominio. Ciascun microservizio è distribuito in un contenitore separato per cui è importante un dimensionamento adeguato, il che significa che ogni funzione aziendale deve gestire un singolo servizio. L’errore, quando i servizi sono troppo piccoli, è che i team finiscono per ritrovarsi con più servizi di quanti ne possano effettivamente gestire. Nonostante i container siano generalmente più leggeri nel consumo di risorse rispetto alle VM, possono comunque generare un notevole sovraccarico dei servizi. L’impatto di un sovraccarico di servizi isolati nei container è quello di ostacolare l’automazione delle attività chiave, ad esempio quando i team distribuiscono aggiornamenti, ridimensionano il carico e impostano la comunicazione asincrona.
Non esiste uno standard sul dimensionamento dei microservizi. Durante la migrazione delle funzionalità monolitiche ai microservizi, prendere decisioni sulle dimensioni dei servizi aiuta a supportare le applicazioni specifiche. Una buona pratica è iniziare con servizi più grandi che gli sviluppatori vanno poi ad articolare gradualmente in servizi più piccoli quando hanno maturato maggiore esperienza nello sviluppare le giuste alberature rispetto alle operazioni del mondo reale. Trovare l’equilibrio è spesso solo una questione di tempo e sperimentazione.
3. Servizi di accoppiamento troppo stretti
Il concetto alla base dei microservizi è quello di sviluppare servizi indipendenti che non hanno bisogno l’uno dell’altro per funzionare. Il che significa che ciascuno di questi servizi può essere modificato senza registrare tempi di inattività in altre parti dell’applicazione. Tuttavia, i team tendono a commettere l’errore di mantenere i servizi strettamente accoppiati analogamente a quanto avviene in un approccio monolitico. Dal momento che le applicazioni monolitiche si basano su forti connessioni tra i componenti, in fase di migrazione è frequente non considerare il cambio di passo e le modalità di intervento necessarie a disaccoppiare le interdipendenze.
Quando si suddividono le applicazioni monolitiche in servizi, gli sviluppatori devono stare molto attenti a intervenire in modo diretto nel disaggregare le connessioni, per evitare l’errore di realizzare quello che si chiama modello monolitico distribuito. Il rischio, infatti, è di ottenere un’applicazione che è ancora monolitica in natura e che richiederà complessi sforzi di gestione nella sua granularizzazione in chiave di microservizio.
Per evitare questa trappola i team devono imparare a creare servizi che siano accoppiati il più liberamente possibile. Come? Progettando ogni singolo servizio in modo che possa funzionare senza alcun aiuto da parte di altri servizi. I servizi più piccoli, che richiedono regolarmente ridimensionamenti o aggiornamenti, dovrebbero essere progettati in modo completamente indipendente.
4. Archiviazione dei log nei container
Le applicazioni monolitiche archiviano i log in una posizione centralizzata, in grado di risalire a qualsiasi componente all’interno dell’architettura. La registrazione diventa complicata nei microservizi, specialmente quando gli sviluppatori scelgono di posizionare i log all’interno delle singole istanze del contenitore. In poco tempo, infatti, queste istanze diventano difficili da trovare in tempi rapidi. Senza contare che tutti i registri archiviati in un contenitore di breve durata vengono eliminati una volta esaurita la funzione del container.
Per evitare questo problema, i team devono archiviare i log in un database centralizzato o in una piattaforma di analisi dei log in grado di connettersi ai contenitori distribuiti. Solo in questo modo gli sviluppatori possono accedere facilmente ai log e mappare gli errori ai rispettivi servizi e risolverli.
5. Mancata considerazione del monitoraggio
La migrazione ai microservizi introduce uno scenario di monitoraggio complesso e sconosciuto ai team IT abituati alla produzione delle app monolitiche. Questo perché i componenti dei microservizi spesso sono sviluppati su stack tecnologici completamente diversi, distribuiti e comunicanti, che rendono difficile individuare esattamente l’origine di un problema. Nonostante i migliori sforzi compiuti per abilitare l’indipendenza di un servizio, può comunque capitare che si scatenino delle conseguenze imprevedibili su uno o altri servizi. Ecco perché è importante introdurre sistemi di monitoraggio centralizzati che assicurano il presidio delle applicazioni. Solo grazie a questo tipo di investimenti è possibile assicurarsi del comportamento corretto delle applicazioni: qualsiasi anomalia non prevista sarà registrata e messa a sistema, aiutando i team a ripristinare e indirizzare al meglio i microservizi problematici.
Attenzione alla memorizzazione nella cache
Gli esperti suggeriscono alcune linee guida da seguire per una corretta gestione della cache: in particolare quando si tratta di quali e quanti dati vengono memorizzati. Per mantenere elevate le prestazioni dei microservizi, infatti, è molto importante evitare di sovraccaricare una cache con dati obsoleti o ridondati.
Prima di tutto bisogna determinare cosa tenere in memoria e questo dipende dalla tipologia di applicazione cui afferisce il microservizio: ad esempio, un’applicazione di e-commerce potrebbe dover precaricare gli articoli utilizzati di frequente nella cache in modo che un nuovo ordine venga elaborato utilizzando un articolo già memorizzato. Tuttavia, è possibile che le applicazioni che non necessitano di accedere ai dati in questo modo possano essere lasciate nella cache a caricamento lento per evitare sovraccarichi di dati.
Quindi bisogna impostare la condivisione di memoria. Nella cache condivisa i dati sono condivisi tra le istanze dell’applicazione e tutti i servizi accedono alla stessa cache. Questo approccio è facilmente scalabile, dal momento che è possibile scalare i server in base alle effettive esigenze. In genere, questa cache è ospitata come un servizio separato.
Infine bisogna decidere per quanto tempo conservare i dati nella cache.
