DEV Community: Serverless Italy

Architetture a microservizi, tra hype e casi d’uso — parte 1

Luca Bianchi — Tue, 16 Jun 2020 07:01:01 +0000

Architetture a microservizi, tra hype e casi d’uso — parte 1

Majestic Reflections of Shaik Zayed Grand Mosque. One of the world's most astonishing example of Islamic architecture. Photo by Photo by Farhan Khan.

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.

Progettare la scalabilità di un sistema richiede un’attenta analisi della variazione nel tempo delle differenti componenti dell’architettura

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

Come abilitare la regione italiana di AWS e primi test di connettività

Luca Bianchi — Mon, 01 Jun 2020 12:09:59 +0000

Photo by Cristina Gottardi on Unsplash

Amazon Web Services ha rafforzato la sua presenza in Europa mediante l’introduzione di una region dedicata agli utilizzatori dei servizi AWS in Italia, prevedendo nei prossimi anni uno sviluppo significativo di questo mercato.

La nuova region prende il nome di eu-south-1 oppure AWS Europe (Milan). Sebbene sia disponibile a tutti gli utenti AWS, non è abilitata di default quindi è necessario effettuare alcune semplici operazioni per poter accedere ai servizi localizzati nel nostro paese.

Infatti, selezionando la region eu-south-1 dal menu a discesa si viene portati ad una pagina che ci informa che è necessario chiedere l’abilitazione. Questo processo è totalmente gratuito, ma richiede un’autorizzazione esplicita e qualche minuto di attesa.

Dopo aver cliccato su Continua si viene portati all’elenco delle region attive sul nostro account, tra cui è possibile vedere come Europe (Milan) sia indicata come “Disabilitata”.

Dopo aver cliccato su Enable è necessario confermare una seconda volta la scelta. Completato l’operazione si riceve un messaggio che avvisa che la region sarà disponibile una volta terminata la preparazione delle risorse da parte di AWS.

Il tempo di preparazione può richiedere fino ad alcuni minuti, entro i quali se si prova ad accedere dal menu a discesa si riceve un messaggio di attesa.

Finalmente, al termine dell’operazione potremo accedere alla region eu-south-1, con la garanzia che le nostre risorse cloud siano localizzate in più availability zone (almeno 3) all’interno del territorio italiano.

Non tutti i servizi AWS sono disponibili all’interno di questa nuova region ed i costi delle risorse risultano leggermente più alti di eu-west-1 (ma comunque in media con le altre region AWS e decisamente più contenuti di eu-central-1 ).

Per renderci conto della latenza della nuova region, sperimentiamo il deploy di una API mediante Amazon API Gateway. Nel menu della console selezioniamo il servizio, poi Create new API ed impostiamo le opzioni come segue:

In questo modo effettueremo il deploy della pet store api, una API di test offerta da API Gateway che sarà perfetta per provare i tempi di risposta della nostra region. Dopo aver selezionato Import occorre effettuare il deploy della API, scegliendo New Stage ed assegnando un nome allo stage di deploy.

Completata l’operazione copiamo l’indirizzo riportato accanto a Invoke URL e proviamo una semplice richiesta GET con Postman. L’API PetStore appena generata si comporta come proxy verso una API resa disponibile da AWS nella region (raggiungibile all’url http://petstore.execute-api.eu-south-1.amazonaws.com/petstore/pets), che, essendo realizzata mediante Lambda, potrebbe sperimentare il problema del cold start e quindi tornare tempi maggiori per la prima invocazione (pur sempre nell’ordine di qualche millisecondo). Per i nostri test, ignoriamo questi dati effettuando più chiamate, a distanza di qualche secondo e vediamo i tempi di risposta riportati da Postman:

Il tempo di risposta dell’intera API è 13ms. Non c’è male considerando che alle latenze di rete si sommano anche le latenze dovute alla banda del provider di connettività e la computazione per la generazione della risposta. Test diretti alla semplice latenza collocano la region Milano al primo posto tra quelle in Europa con minore latenza rispetto alla nostra posizione (dal momento che siamo in Italia) e di ben un’ordine di grandezza inferiore alla latenza per region oltreoceano.

Attenzione: questi test sono stati effettuati su connettività fibra, da una posizione relativamente vicina alla region (qualche decina di km a sud di Milano). Le latenze potrebbero variare, restando comunque sempre contenute

Latenze verso le region AWS calcolate utilizzando il sito web https://ping.psa.fun/

Nei prossimi articoli continueremo a sperimentare le risorse disponibili all’interno di questa nuova region, iniziando a pubblicare alcuni servizi serverless ed a realizzare le nostre app con tecnologie all’avanguardia.

Nel frattempo, non mancate giovedì 4 giugno dalle 9:45 al primo evento gratuito interamente in lingua italiana sul mondo serverless. Registrazioni ed agenda su italy.serverlessdays.io

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.

Potete contattare Luca su Twitter, LinkedIn e Medium