I vantaggi dei microservizi sono molti e vari e principalmente legati ad un sistema distri- buito. I microservizi, tuttavia, tendono a raggiungere questi benefici in misura maggiore principalmente a causa della misura in cui adottano i concetti relativi ai sistemi distribuiti e all’architettura orientata ai servizi.
7.2.1
Eterogeneità delle Tecnologie
Con un sistema composto da più servizi collaborativi, possiamo decidere di utilizzare diver- se tecnologie all’interno di ciascuno di essi. Questo ci permette di scegliere lo strumento giusto per ogni lavoro, piuttosto che dover selezionare un approccio più standardizzato, a taglia unica, che spesso finisce per essere il minimo comune denominatore.
Se una parte del nostro sistema ha bisogno di migliorare le sue prestazioni, potremmo deci- dere di utilizzare un diverso stack tecnologico che sia maggiormente in grado di raggiungere i livelli di prestazioni richiesti. Potremmo anche decidere che il modo in cui archiviamo i nostri dati deve cambiare per diverse parti del nostro sistema.
Ad esempio, per un social network, potremmo memorizzare i nostri utenti interazioni in un database graph-oriented per riflettere la natura altamente interconnessa di un grafico sociale, ma forse i post che gli utenti fanno potrebbero essere archiviati in un database
Figura 7.2: I Microservices possono permetterti di sfuttare diverse tecnologie più facilmente Con i microservizi, siamo anche in grado di adottare la tecnologia più rapidamente e capire in che modo i nuovi progressi possono aiutarci. Con un’applicazione monolitica, se voglio provare un nuovo linguaggio di programmazione, database o framework, qualsiasi modifica avrà un impatto su gran parte del mio sistema. Con un sistema composto da più servizi, ho molti nuovi posti in cui provare un nuovo pezzo di tecnologia. Posso scegliere un servizio che è forse a basso rischio e utilizzare la tecnologia lì, sapendo che posso limitare qualsiasi potenziale impatto negativo. Molte organizzazioni ritengono che questa capacità di assorbi- re più rapidamente le nuove tecnologie sia un vero vantaggio per loro.
Abbracciando più tecnologie non viene senza un overhead, naturalmente. Alcune organiz- zazioni scelgono di porre alcuni vincoli sulle scelte linguistiche. Netflix e Twitter, ad esempio, utilizza principalmente Java Virtual Machine (JVM) come piattaforma, in quanto ha un’ottima conoscenza dell’affidabilità e delle prestazioni di quel sistema. Sviluppano inoltre librerie e strumenti per la JVM che rendono operativo su vasta scala molto più facile, ma rende più difficile per i servizi o client non basati su Java. Ma Né Twitter né Netflix utilizzano solo uno stack tecnologico per tutti i lavori.
Un altro contrappunto alle preoccupazioni sulla miscelazione in diverse tecnologie è la di- mensione. Se riesco davvero a riscrivere il mio microservizio in due settimane, potresti tranquillamente mitigare i rischi legati all’adozione della nuova tecnologia.
7.2.2
Robustezza
In un servizio monolitico, se il servizio fallisce, tutto smette di funzionare. Con un sistema monolitico, possiamo eseguire l’applicativo su più macchine per ridurre le nostre possibilità di fallimento, ma con i microservizi possiamo costruire sistemi che gestiscono il fallimento
24 MicroServices
totale dei servizi..
Dobbiamo stare attenti, tuttavia. Per garantire che i nostri sistemi di microservizi possano appropriarsi adeguatamente di questa maggiore resilienza, è necessario comprendere le nuove fonti di insuccesso che i sistemi distribuiti devono affrontare. Le reti possono e falli- ranno, così come le macchine. Abbiamo bisogno di sapere come gestirlo e quale impatto (se esiste) dovrebbe avere sull’utente finale del nostro software.
7.2.3
Scaling
Con un servizio ampio e monolitico, dobbiamo ridimensionare tutto insieme. Una piccola parte del nostro sistema generale è limitata nelle prestazioni, ma se quel comportamento è bloccato in una gigantesca applicazione monolitica, dobbiamo gestire il ridimensionamento di tutto come un pezzo. Con servizi più piccoli, possiamo semplicemente scalare quei servizi che necessitano di ridimensionamento, permettendoci di eseguire altre parti del sistema su hardware più piccolo e meno potente, come nella Figura 7.3.
Figura 7.3: È possibile scegliere di ridimensionare solo per quei microservizi che ne hanno bisogno
7.2.4
Ease of Deployment
Una modifica di una riga a un’applicazione monolitica di milioni di righe richiede che l’intera applicazione venga distribuita per rilasciare la modifica. Potrebbe essere una distribuzione di grande impatto e ad alto rischio. In pratica, le distribuzioni a impatto elevato e a rischio elevato finiscono per accadere raramente a causa di timori comprensibili. Sfortunatamente,
Con i microservizi, possiamo apportare una modifica a un singolo servizio e distribuirlo indi- pendentemente dal resto del sistema. Questo ci consente di implementare il nostro codice più velocemente. Se si verifica un problema, può essere isolato rapidamente per un sin- golo servizio, rendendo facile il rollback veloce. Significa anche che possiamo portare le nostre nuove funzionalità ai clienti più velocemente. Questo è uno dei motivi principali per cui organizzazioni come Amazon e Netflix utilizzano queste architetture, per garantire che rimuovano il maggior numero di impedimenti possibili per far uscire il software.
7.2.5
Organizational Alignment
Molti di noi hanno riscontrato problemi associati a team di grandi dimensioni e codebase di grandi dimensioni. Questi problemi possono essere eliminati quando il team viene distribui- to. Sappiamo anche che i team più piccoli che lavorano su codebase più piccoli tendono ad essere più produttivi. I microservizi ci consentono di allineare meglio la nostra architettura alla nostra organizzazione, aiutandoci a ridurre al minimo il numero di persone che lavora- no su qualsiasi codebase per raggiungere il sweet spot delle dimensioni e della produttività della squadra. Possiamo anche spostare la proprietà dei servizi tra i team per cercare di mantenere le persone che lavorano su un unico servizio.
7.2.6
Composability
Una delle promesse chiave dei sistemi distribuiti e delle architetture orientate ai servizi è che apriamo nuove opportunità per il riutilizzo delle funzionalità. Con i microservizi, consen- tiamo di consumare le nostre funzionalità in modi diversi per scopi diversi.
Questo può essere particolarmente importante quando pensiamo a come i nostri consu- matori utilizzano il nostro software. È finito il momento in cui potevamo pensare in modo restrittivo al nostro sito Web desktop o all’applicazione mobile. Ora dobbiamo pensare alla miriade di modi in cui potremmo voler intrecciare funzionalità per il Web, l’applicazione nati- va, il Web mobile, l’app per tablet o il dispositivo indossabile.
Man mano che le organizzazioni si allontanano dal pensare in termini di canali ristretti a concetti più olistici di coinvolgimento dei clienti, abbiamo bisogno di architetture che possano tenere il passo.
26 MicroServices
7.2.7
Optimizing for Replaceability
Se lavori in un’organizzazione di dimensioni medie o grandi, è probabile che tu sia a co- noscenza di qualche grande e sfortunato sistema legacy seduto nell’angolo. Quello che nessuno vuole toccare. Quello che è vitale per come funziona la tua azienda, ma che sem- bra essere scritto in qualche strana variante di Fortran e funziona solo su hardware che ha raggiunto la fine della vita di 25 anni fa. Perché non è stato sostituito? Sai perché: è un lavoro troppo grande e rischioso.
Con i nostri singoli servizi di dimensioni ridotte, il costo per sostituirli con un’implementa- zione migliore, o addirittura eliminarli del tutto, è molto più facile da gestire. Quante volte hai cancellato più di cento linee di codice in un solo giorno e non ti preoccupi troppo? Poi- ché i microservizi spesso hanno dimensioni simili, le barriere che cancellano o eliminano completamente i servizi sono molto basse.
I team che utilizzano approcci di microservizio sono a loro agio con servizi di riscrittura completamente necessari quando richiesto e semplicemente uccidendo un servizio quando non è più necessario. Quando una codebase è lunga solo poche centinaia di righe, è difficile per le persone essere attaccate a livello emotivo e il costo per sostituirlo è piuttosto ridotto.