I Microservice sono diventati molto popolari in questi ultimi anni, si tratta di una variante dell'approccio SOA (Service-Oriented Architecture) che va a strutturare un'applicazione come una raccolta di servizi liberamente associati tra loro. Il vantaggio di scomporre un'applicazione in diversi servizi più piccoli sta proprio nella modularità che rende l'applicazione più leggera, più facile da gestire, da capire, da sviluppare e ovviamente da testare.
Oggi vi vogliamo proporre un'analisi del developer Dave Kerr che, durante la sua carriera, si è occupano di numerosi progetti basati sui microservizi. In un suo recente articolo pubblicato sul suo blog personale il developer afferma che esistono moltissimi casi in cui tale architettura ha portato benefici, tuttavia spesso può capitare il contrario.
Molti progetti infatti hanno intrapreso la via dei Microservice traendone più svantaggi che vantaggi. Nel post Kerr spiega in modo dettagliato perché i Microservice possono diventare un problema.
Aumentano la complessità per i developer e i devops
I Microservice possono incrementare la produttività di uno o più team, ma dover sviluppare e gestire un'architettura complessa può rilevarsi molto difficile. Anche solo eseguire un test del codice durante il debug può rivelarsi faticoso. Un conto è eseguire il test di una singola applicazione, un altro è farlo per ogni microservizio creato, i tempi e la complessità di gestione lievitano notevolmente.
Richiedono una buona dose di competenza
Sviluppare e mantenere un'architettura del genere richiede una certa dose di skill che non tutti i team hanno a disposizione. Si deve essere sempre molto cauti quando si inizia a creare un progetto basato sui microservizi e non un sistema monolitico che, per ovvie ragioni pratiche, risulta essere più facile da mantenere malgrado (sulla carta) risulti meno accattivante rispetto ad un sistema Microservice.
I sistemi reali spesso hanno confini labili
I Microservice sono basati su un'architettura di componenti indipendenti, tuttavia spesso capita che al termine della fase di sviluppo tali processi risultino per nulla indipendenti. Sulla carta risulta tutto molto più definito, mentre quando si va a scrivere il codice i confini tra processi indipendenti non possono che essere deboli, con il risultato che si può finire per generare, senza volerlo, un sistema di servizi che in realtà dipendono l'uno dall'altro.
Difficoltà nel versioning
Gestire le dipendenze di un sistema non è facile, il fatto che un sistema sia modulare e che ogni modulo richieda determinate librerie aumenta la complessità, con possibili conflitti tra i vari componenti. Oppure si rischia di dover far girare più versioni di un servizio o di una libreria per evitare problemi, andando dunque a perdere uno dei vantaggi di un sistema di Microservice.
In conclusione, è sempre bene valutare con attenzione l'uso di un modello di sviluppo basato sui Microservice. Ad alcuni progetti e team di sviluppo esso può portare un effettivo beneficio, mentre per altri può essere causa di problemi rilevati, sopratutto se si tratta di sviluppatori con un'esperienza limitata.
Via Dave Kerr