Architetture a microservizi, tra hype e casi d’uso — parte 1
Il mondo IT non è esente dal fascino delle “mode del momento”: soluzioni che magari sono state adottate da aziende considerate punti di riferimento e che assumono nell’immaginario collettivo il ruolo di “no brainer” diventando il nuovo status quo, almeno per alcuni mesi, in attesa che la nuova “moda” prenda il posto della precedente. Il più delle volte si tratta di soluzioni che hanno più di un razionale forte nella loro adozione da parte delle aziende che le hanno proposte per prime. Si tratta, più in generale, di metodologie, architetture o tecnologie che vale la pena prendere in considerazione, ma è necessario avere ben chiari i problemi che si desidera risolvere ed il rapporto costi/benefici offerto da queste tecnologie.
Nessuna scelta tecnologica è esente da “costi”: compito di un buon architect è valutarne l’impatto in relazione ai benefici che si desidera ottenere.
Perché sono interessanti le architetture microservizi?
In questo scenario è opportuno valutare adeguatamente l’impatto delle cosiddette architetture a microservizi. Vediamo cosa caratterizza le scelte tecnologiche alla base di questa metodologia per la definizione di architetture. In particolare un fattore fondamentale di queste soluzioni è legato alla scalabilità intrinseca a queste architetture, soprattutto in presenza di pattern di scalabilità differenti per le diverse componenti del nostro sistema. Consideriamo, ad esempio, un portale e-commerce. Sappiamo ormai da quasi un decennio che il primo passo per garantire una buona scalabilità è la separazione quantomeno della componente client dalla parte backend dell’architettura. Questa scelta che oggi appare intuitiva, non lo era affatto solo pochi anni fa: numerose tecnologie affermatesi nel tempo, incentrate sulla semplicità ed il rapido time-to-market hanno invece proposto un approccio diametralmente opposto. Si tratta di framework come Django, Rails e soluzioni analoghe che solo recentemente hanno abbracciato quantomeno un’architettura multi-tenant, separando il client (ormai sempre più una Single Page App o “SPA”) dalle componenti relative al backend, richiedendo lo sviluppo di endpoint. In questo scenario si è affermato sempre più lo standard di sviluppo di backend che espongano verso i client, endpoint REST. Non si tratta ancora di architetture a microservizi, ma di una prima suddivisione di componenti con requisiti e molteplicità profondamente diversi: grazie all’avvento del mobile, oggi si considera sempre più spesso lo sviluppo di differenti client, magari costruiti con la medesima tecnologia, ma rivolti ad utenze diverse. Il sistema backend, in questo contesto diventa un oggetto software che ha il compito di esporre degli endpoint verso i client attraverso cui inviare o ricevere informazioni utili al soddisfacimento dei nostri requisiti. Tornando all’esempio del sto e-commerce, il backend offrirà ai client quantomeno endpoint relativi al catalogo, al carrello ed alla procedura di pagamento dei prodotti acquistati.
Ovviamente dal punto di vista della scalabilità questi insiemi di endpoint avranno requisiti molto diversi tra loro: il catalogo subirà un traffico legato ad eventuali campagne promozionali, mentre il carrello (oppure un’eventuale wish list) avranno traffico necessariamente minore. In molti casi si sperimenta non solo un differente volume di chiamate, ma anche pattern tra loro alquanto diversi, soggetti alle iniziative del business che hanno lo scopo di servire: ad esempio offerte “flash” da Black Friday generano traffico molto diverso da normali periodi di esercizio. Supportare differenti pattern di accesso con una medesima architettura impone di trovare un minimum comune denominatore tra le varie esigenze. Le architetture a microservizi consentono di separare i vari endpoint, in base alle necessità imposte dai requisiti business per meglio soddisfarle. Si accetta quindi un maggiore costo “gestionale” giungendo a differenti configurazioni di deploy, così da consentire una gestione più efficiente del sistema con un migliore profilo di costi. L’impatto di queste scelte risulta ancora più evidente quando si considera la persistenza dei dati relative alla soluzione realizzata.
A ciascun servizio la sua persistenza
La separazione delle varie componenti di un’architettura in microservizi offre la possibilità di valutare per ciascuna di esse il miglior database disponibile in base alla struttura dati. Si tratta di un cambiamento quasi epocale nella gestione dei dati, poiché per quasi tre decadi l’unico approccio disponibile, considerato da molti un vero e proprio “silver bullet”, è stato l’utilizzo di modelli di dati strutturati, che venivano poi calati su database relazionali (spesso impropriamente detti SQL per via del linguaggio di query utilizzato da questi DBMS). Prodotti di mercato del calibro di Oracle, IBM DB2 e Microsoft SQL Server, affiancati negli anni da soluzioni open source come MySQL e PostgreSQL, hanno suggerito come unica soluzione alla gestione della persistenza dei dati la riduzione del modello nella cosiddetta “forma normale” così da minimizzarne la ridondanza informativa. Questi database provengono da un’epoca in cui lo storage aveva costi decisamente maggiori della potenza computazionale che, nella maggior parte dei casi applicativi, si trovava ad essere largamente sotto-utilizzata. L’avvento del cloud e la comparsa dei primi servizi di computazione on-demand, unitamente alla disponibilità di memorie a basso costo, ha ribaltato questa prospettiva.
Non si tratta però di un solo fattore economico: negli ultimi vent’anni l’adozione in modo pervasivo di tecnologie mobile e la digitalizzazione di interi comparti industriali hanno portato alla nascita di casi d’uso che mettevano in crisi il modello unico relazionale su temi di scalabilità e consistenza di dati spesso acceduti e modificati da varie parti del globo. In particolare la pubblicazione nel 2000 del teorema CAP ha dimostrato come un sistema software sia sempre il risultato di una serie di compromessi che ne determinano l’architettura e l’impatto che tali scelte hanno sulla persistenza dei dati rischia di essere non trascurabile. In particolare negli ultimi anni, si è affermato il modello dei purpose-built database, contrapposti alla scelta di un solo DBMS per tutto il nostro applicativo. In questo scenario diventa puerile la diatriba SQL vs NoSQL che ha appassionato architect e developer per quasi un decennio: il database migliore dipende dai requisiti di un sistema che deve soddisfare un determinato caso d’uso e, nel caso di architetture a microservizi, non esiste una risposta univoca. In particolare queste architetture offrono la possibilità di scegliere il miglior database per un determinato insieme di endpoint, incoraggiando quindi una pluralità di modelli dati all’interno della stessa soluzione. All’interno del perimetro di ciascun servizio, è possibile valutare le esigenze degli specifici schemi di accesso ai dati ed in base alle esigenze della logica di business, scegliere la persistenza più adatta.
Cicli di vita e rilasci incrementali
Un beneficio interessante spesso sottovalutato delle architetture a microservizi è la capacità di parallelismo del ciclo di vita delle varie componenti: ciascun team è in buona parte indipendente dagli altri e quindi può procedere con iterazioni di sviluppo più brevi e minori rischi di regression poichè la base di codice da manutenere risulta più piccola. Questo significa che i componenti del team non devono necessariamente conoscere il dettaglio di tutti gli aspetti del sistema, mentre un maggiore valore è dato al ruolo dell’architect che svolge una funzione importante della condivisione del know-how necessario alla realizzazione dei macro-requisiti di business.
Questo aspetto evidenzia anche alcuni punti di attenzione che le architetture a microservizi presentano: la separation of concern è garantita by design da questa metodologia richiede ovviamente un’attenzione particolare alla gestione della comunicazione tra i vari microservizi.
Nella seconda parte..
Nella seconda parte di questo articolo vedremo quali criticità pongono le architetture a microservizi e come possono essere superate mediante l’adozione di tecniche quali API Façade e comunicazione event-based.
Informazioni sull’autore
Sviluppatore e Cloud Architect da oltre un decennio, Luca Bianchi segue in qualità di CTO, lo sviluppo della tecnologia e dei prodotti Neosperience, Technology partner AWS, con particolare focus su serverless e machine learning.
Dal 2015 è co-organizer del Serverless Italy Meetup e dal 2016 collabora all’organizzazione del capitolo italiano di ServerlessDays. Autore di numerose pubblicazioni, talk e video è da sempre appassionato di tecnologia, con particolare attenzione allo sviluppo di applicativi serverless, ai modelli di machine learning e al mondo IoT.
Potete contattare Luca su Twitter, LinkedIn e Medium
Top comments (0)