!M I C R O S E R V I C E S

ASPETTI CHIAVE DA CONSIDERARENELLA PROGETTAZIONE DI

UN'ARCHITETTURA A MICROSERVIZI

INDICE

INTRODUZIONE . . . . . . . . . . . . . . . . . . . . . . . . . .

DEFINIZIONE . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ASPETTI PER LA PROGETTAZIONE DIUN’ARCHITETTURA A MICROSERVIZI . . . . . . . . . . .

INSIEME DI SERVIZI INDIPENDENTI . . . . . . . . .

ORGANIZZARE IN BASE ALLE FUNZIONALITÀ DI BUSINESS . . . . . . . . . . . . . . . . . . . . . . . . . . . PRODOTTI NON PROGETTI . . . . . . . . . . . . . .

ENDPOINT INTELLIGENTI E DUMP PIPES. . . . . .

GESTIONE DECENTRALIZZATA . . . . . . . . . . .

DATA MANAGEMENT DECENTRALIZZATA . . . . . .

INFRASTRUTTURE AUTOMATIZZATE. . . . . . . . .

PROGETTARE PER FALLIRE . . . . . . . . . . . . . . . .

PROGETTAZIONE EVOLUTIVA. . . . . . . . . . . . . . SONO I MICROSERVICES IL FUTURO DELLE ARCHITETTURE SOFTWARE?. . . . . . . . . . . . . . . .

01

02

06

06

09

11

12

14

16

18

19

20

21

INTRODUZIONELo sviluppo di architetture a MicroServices è il nuovotrend di progettazione in ambito Mobile, Internet ofThings, Data analysis e, in generale, nel settore digitale.

Il termine MicroServices non è ancora particolarmenteconosciuto e, per questo motivo, non esistono delle lineeguida pratiche su come realizzare l’architettura ideale.

Lo scopo del Whitepaper è di esplorare questo nuovomondo fornendo una visione ad alto livello degli aspetti daconsiderare quando si vogliono realizzare architetture diquesto tipo.

L’intenzione quindi è di fornire un ibrido tra tecnicismi evisioni ad alto livello per offrire ai manager un riassuntodei benefici e delle problematiche da gestire nel momentoin cui si decide di sviluppare in azienda un progetto diquesto tipo.

PAGINA 1

DEFINIZIONEIl termine “ MicroServices Architecture” (Architettura aMicroServizi) si è affermato negli ultimi anni per descrivereun nuovo approccio di disegno delle soluzioni softwarecome suite di servizi indipendenti.

Attualmente non c’è una definizione precisa di questo stilearchitetturale ma si può fare riferimento a dellecaratteristiche comuni sulle organizzazioni scelte dalleaziende, relativamente a processi di deploy automatici,gestione intelligente degli endpoint e decentralizzazionedei linguaggi di sviluppo e dati.

Spesso gli addetti ai lavori non consideranoparticolarmente lo sviluppo a MicroServices perchéritenuto un nuovo approccio inserito nel contestodinamico dello sviluppo di soluzioni software che richiedeuna rivoluzione dei processi, all’interno di sistemi digitali,già consolidati da anni.

In realtà quello che stiamo vedendo è un approccio moltoattraente e versatile perché permette una rapidaevoluzione dei progetti che possono poi essere inseritifacilmente in processi e soluzioni enterprise esistenti.

In estrema sintesi, lo stile architetturale a MicroServizi èun metodo di sviluppo di una soluzione, come fosse unasuite di piccoli servizi ciascuno in esecuzione nel proprioambiente, che comunica con gli altri attraverso semplicimeccanismi basati su API, tramite protocollo HTTP.

PAGINA 2

I veri MicroServizi sono sviluppati su capacità di businessindipendenti e modelli di deploy automatizzati.

L’indipendenza dei MicroServices è governata però da unsistema centralizzato in modo da garantire ilmantenimento del controllo per non perdere la bussolatra i diversi linguaggi di programmazione e le tecnologieche possono di volta in volta essere utilizzati perrealizzare queste architetture.

Per comprendere meglio il concetto è necessario fare unconfronto tra le soluzioni Software ArchitetturaliMonolitiche, rappresentate da applicativi basati su singolaunità, ed i MicroServices.

Negli ultimi anni si sono affermate soluzioni Enterprisemonolitiche basate su tre componenti:

- Client-Side User Interface: è l’insieme di pagine HTML,Javascript, ecc. eseguite dal browser per fornire agliutilizzatori un’interfaccia di interazione con dati ecomandi.

- Server Side: gestisce le richieste HTTP, esegue le logicheapplicative, recupera ed elabora i dati ed eroga i contenutiper la visualizzazione lato client.La parte di servizi Server Side è la vera e propria partemonolitica in grado di contenere tutte le istruzioni logicheper l’erogazione del servizio.

PAGINA 3

- Database: è la componente tipicamente di relazione(anche se sempre di più si stanno affermando i databaseNoSQL) dove i dati vengono salvati, erogati ed organizzatiin tabelle.

Oggi siamo abituati ad osservare processi aziendali chelavorano a silos in cui lo sviluppo di componenti softwareServer-Side avviene in un’ottica monolitica dove tuttoviene eseguito attraverso un singolo processo persfruttare la possibilità data dal linguaggio diprogrammazione di suddividere l’applicazione in classi,funzioni e namespace.

Questo approccio permette di provare l’applicazione sulPC da parte degli sviluppatori e organizzare una pipelinedi attività e sistemi automatici per essere sicuri che poil’applicazione venga correttamente testata e distribuita inproduzione.

Queste soluzioni permettono una scalabilità orizzontaleanteponendo un bilanciatore di carico per distribuire lerichieste.

Con l’arrivo del Cloud, la scalabilità orizzontale si è rivelataancora più semplice, ma il modello monolita stacominciando ad evidenziare alcuni limiti:

- Riduce la rapidità dei cicli di sviluppo- Piccole modifiche richiedono il deploy di tutto il monolita- Nel corso del tempo è difficile, visti i tempi di svilupposempre più rapidi, mantenere una struttura modulare

PAGINA 4

- La modifica di alcuni moduli potrebbe avere impattianche su altri moduli e quindi richiedere la modifica o larevisione anche di altre parti del monolita per soddisfarele richieste, causando un aumento dei tempi di sviluppo.

PAGINA 5

Fig.1: Confronto scalabilità soluzioni monilitiche e MicroServizi

ASPETTI PER LAPROGETTAZIONE DIUN’ARCHITETTURA AMICROSERVIZICome affermato in precedenza non c’è una vera e propriadefinizione per questo modello di architetture ma loscopo è quello di descrivere, sulla base della nostraesperienza, quali sono gli aspetti da considerare nellaprogettazione e nello sviluppo di un’architettura aMicroServizi.

Trattandosi di un nuovo paradigma, a seconda deiprogetti, potrebbero essere presi in considerazione tuttigli argomenti a seguire o solo una parte di essi.

PAGINA 6

INSIEME DI SERVIZI INDIPENDENTI

L’industria dello sviluppo del software ha sempredesiderato costruire sistemi aggiungendo o togliendo deicomponenti, un po’ come si può fare nella vita reale con ivari componenti di una costruzione Lego.

Nell’ultima decade questo desiderio è stato reso possibiledall’integrazione di librerie come parte delle attività disviluppo software.

Ma che cos’è una componente (components)?

Per componente intendiamo un’unità softwareindipendente, replicabile ed aggiornabile.

Le architetture a MicroServizi usano librerie ma la lorocaratteristica principale è la struttura a serviziindipendenti che dialogano tra di loro tramite appositerichieste.

Infatti, le librerie sono delle componenti collegateall’interno di un programma ed utilizzano chiamate inmemoria per lo scambio di dati e per l’esecuzione dicomandi, mentre i servizi sono componenti out-of-processche dialogano tra di loro con un meccanismo come puòessere una richiesta di servizio web o una proceduraremota.

Una delle principali ragioni per cui è preferibile usare iservizi come componenti (piuttosto che le librerie e crearemonoliti) è che questi sono indipendenti in termini dirisorse, funzionalità e modalità di deploy.

Se invece si dispone di un’applicazione composta da piùlibrerie in un unico processo, il cambiamento di unasingola componente può richiedere il deploy dell’interalibreria.

Scomponendo l’applicazione in più servizi, invece, èpossibile prevedere più aggiornamenti di una singolacomponente senza influenzare gli altri servizi.

PAGINA 7

Questo approccio non è applicabile alla totalità dei casima ci sono situazioni in cui il cambiamento di un serviziosi ripercuote sulla modifica degli altri servizi.

Questo può avvenire, per esempio, quando la modifica diun servizio genera un impatto sulle interfacce provocandoun adattamento degli altri servizi.

Il reale obiettivo di un’architettura a MicroServizi è ridurreal minimo questi problemi lavorando sulla retrocompatibilità delle versioni al fine di consentirel’evoluzione e l’adattamento degli altri servizi secondo leloro dinamiche di evoluzione.

Questo approccio di comunicazione a MicroServizievidenzia quindi la necessità di una gestione efficientedelle API attraverso una corretta documentazione.

Un’altra conseguenza nell’utilizzo di servizi comecomponenti di un’architettura è la necessità diun’interfaccia esplicita.

La maggior parte dei linguaggi di programmazione non hadei buoni meccanismi per definirne e pubblicarne una.

Per questo motivo spesso solo una buonadocumentazione ed il dialogo tra le parti può prevenireproblemi di comunicazione tra i servizi durante il loroprocesso di evoluzione.

PAGINA 8

Sicuramente l’uso di componenti a servizi è più onerosorispetto a chiamate in-process, in quanto si tratta dichiamate remote ma, quando c’è la necessità di ripartire lefunzionalità e le responsabilità, la separazione dellecomponenti offre una maggiore flessibilità e soliditàsoprattutto in contesti moderni dove c’è un forte scambiodi informazioni tra componenti diverse.

PAGINA 9

ORGANIZZARE IN BASE ALLEFUNZIONALITA' DI BUSINESSQuando si vuole suddividere un’applicazione in più partispesso quello che succede è la suddivisione del problemain strati tecnologici come ad esempio User Interface Team,Logics Teams DBA Teams.

Fig.2: Architetture realizzate mediante l’interazione di team funzionali

Quando i team sono così separati, anche un progetto diintegrazione o modifica di piccole dimensioni puòrichiedere attività cross-team con tempi lunghi divalidazione delle attività da parte di ogni team e ladefinizione del budget.

L’approccio a MicroServices ha invece una diversadivisione dei servizi organizzabili in base alle capacità dibusiness.

Questo implica un’implementazione full-stack ( UI, Logic,DB ) per ogni area di business.Per fare questo sono richiesti team cross-funzionali el’intera gamma di competenze necessarie per lo svilupposoftware in termini di User Experience, database egestione dei processi.

PAGINA 10

Fig.3: Team Cross-Funzionali portano ad architetture a MicroServizi

Perciò team cross-funzionali sono responsabili dellacostruzione ed esecuzione di prodotti suddivisi in diversiservizi che comunicano tra di loro tramite bus dimessaggi.

Anche gli applicativi monoliti possono esseremodularizzati attorno alle linee di business ma non senzadifficoltà perché, tipicamente, la dimensione del monolitatende a crescere nascondendo i confini tra i varicomponenti e creando una complessità elevata che nonpermette la corretta separazione delle funzioni ecompetenze.

PAGINA 11

PROGETTI NON PROGETTI

La maggior parte degli sforzi compiuti da un team disviluppo per la realizzazione di un applicativo softwareconsistono nella realizzazione di qualcosa che sia ritenutacompleta e funzionante.Spesso, nelle grandi organizzazioni, la ricerca del prodottocompleto e funzionante porta il trasferimento del softwareal team di supporto e manutenzione mentre il team disviluppo viene destinato ad altre attività.

Lo sviluppo a MicroServizi tende a preferire a questoapproccio dinamiche legate al possesso del prodotto daparte del team per tutto il suo ciclo di vita.

Questo approccio porta gli sviluppatori, giorno dopo giorno,al contatto con gli utenti permettendo loro di conoscerneabitudini e necessità e di migliorare il prodotto durante ilsuo ciclo di vita.

Una mentalità basata sul prodotto genera un particolarerisvolto sui risultati di business in quanto il team,piuttosto che guardare il software come un insieme difunzionalità, tenderà a porsi alcune domande su comepossa assistere i propri utenti nel miglioramento dellecapacità di business.

Ovviamente questo approccio può essere applicato anchealla realizzazione di soluzioni monolitiche ma l’uso diservizi, vista la loro granularità, permette di instaurarerelazioni umane più semplici tra sviluppatori e utenti.

PAGINA 12

ENDPOINT INTELLIGENTI E DUMP PIPES

Quando si costruiscono strutture di comunicazione traprocessi distinti ci sono diversi prodotti e approcci, più omeno strutturati, da considerare per permetterel’interscambio di dati.L’esempio più adeguato sono gli Enterprise Service Bus(ESB).Gli ESB spesso includono sofisticate logiche dimessaggistica, trasformazione ed elaborazione del datoper favorire l’interscambio di informazioni.

Le architetture a MicroServices offrono delle soluzionialternative basate su endpoint intelligenti e dump pipes.Infatti le applicazioni a MicroServices hanno lo scopo diessere il più disaccoppiate possibile e, allo stesso tempo,coese per dare ad ogni servizio il suo dominio diesecuzione utile a ricevere delle richieste, applicarelogiche di business e poi generare la risposta.

Nel mondo dei servizi si predilige l’uso di protocolli httprestful JSON anziché di protocolli complessi.

Il Team di sviluppo di architetture a MicroServizi usa iprotocolli alla base della rete web sfruttando, in alcunicasi, delle cache locali per rendere più efficienti lecomunicazioni.

In alternativa, vengono utilizzati dei semplici bus dimessaggistica come RabbitMQ o ZeroMQ che fornisconoun servizio asincrono di messaggistica lasciando ai singoliservizi l’elaborazione dei dati.

Come affermato in precedenza, le applicazioni monolitichecomunicano tra di loro attraverso chiamate a metodi ofunzioni in-memory.Nel momento in cui si decide di trasformare un monolitain un sistema a servizi è il cambio del modello dicomunicazione che impatta sulla “divisione” dellecomponenti perché il passaggio da chiamate in-memory aprocedure remote spesso e volentieri risulta fortementeinefficiente.

PAGINA 13

PAGINA 14

GESTIONE DECENTRALIZZATA

Una delle conseguenze di un approccio centralizzato è latendenza a standardizzare un’unica tecnologia per tutte lesoluzioni.

La realtà è diversa in quanto servono strumenti differentiper risolvere le varie necessità.La politica alla base delle architetture a MicroServices èquella di usare lo strumento giusto per lo scopo richiesto.Si tratta di un enorme vantaggio per le architetture aMicroServices in termini di performance e flessibilitàrispetto a soluzioni monolitiche.

Questo approccio permette di costruire le variecomponenti con gli strumenti più adeguati, ad esempio dipuò utilizzare Node.JS per una pagina di report oppure illinguaggio di programmazione C++ per realizzare unacomponente in real time. Ovviamente tutte le scelte vannocontestualizzate e va considerata ciascuna possibilità inbase al contesto di progetto.

I team che adottano lo sviluppo a MicroServizipreferiscono un approccio non propriamente standard.Infatti, più che ricorrere a soluzioni già disponibili,tendono a sviluppare servizi utili da mettere adisposizione di altri sviluppatori.Questo approccio prevede la messa a disposizionedell’idea originale di tutti gli altri colleghi e/o sviluppatoriterzi, per facilitarne l’integrazione e/o l’evoluzione.

PAGINA 15

Netflix è un esempio di azienda che segue questa filosofiaspingendo molto sulla condivisione delle informazioni elasciando libere le persone di scegliere se utilizzarelibrerie già disponibili sul mercato o se svilupparesoluzioni nuove a problemi già risolti da altri medianteapprocci diversi.

Le librerie tendono a focalizzarsi nella risoluzione di alcuniaspetti, come l’efficienza di comunicazione o di storagema, come detto in precedenza, in alcuni contestil’approccio più corretto punta alla qualità basata sullaconsapevolezza del problema.

La gestione decentralizzata, unita alla responsabilità deglisviluppatori nel gestire e generare un prodotto chedovranno seguire per l’intero suo ciclo di vita (dalla primariga di codice al supporto al cliente), porta ad unmiglioramento della qualità del codice del prodottostesso.Questo accade perché gli sviluppatori possono scegliere letecnologie più adeguate al problema da risolvere esoprattutto, avendo il contatto con il Cliente, possonocapire meglio le sue necessità nelle fasi di assistenza edevoluzione del prodotto.Questo approccio sicuramente produce un risultatoqualitativamente superiore rispetto alla gestionecentralizzata di sistemi monolitici che realizzano ognifunzione con le medesime tecnologie per poter lavoraresecondo un approccio a silos dove chi è a contatto con ilcliente non realizza nuovi prodotti.

PAGINA 16

DATA MANAGEMENT DECENTRALIZZATA

Nella progettazione di architetture a MicroServices ci sipone spesso il problema della centralizzazione dei dati.Questo problema è comune allo sviluppo di qualsiasisoluzione software ma è di maggiore importanza inapplicazioni separate perché, come avviene nei processidecisionali di business, è fondamentale nella fase diprogettazione decidere se e come decentrare i dati.Le applicazioni monolitche preferiscono un unicodatabase logico per tutti i dati persistenti di uno specificoprogetto, scegliendo altre soluzioni in altri contesti.Spesso però capita che le aziende, anche per motivi legatialle licenze, preferiscano un unico database per tutte lesoluzioni.Al contrario le architetture a MicroServizi preferisconolasciare ad ogni servizio il proprio database sia in terminidi istanze che di tecnologie, questo approccio viene dettosistema di persistenza “poliglotta”.

Fig.4: Lo strato di persistence passa da un unico database a database diversi contecnologie differenti in base al servizio.

PAGINA 17

Ovviamente i vantaggi di avere un sistema di persistenzapoliglotta sono:

- efficienza- indipendenza

ma tale sistema porta con se anche alcune problematicheda gestire, quali l’aggiornamento e la consistenza dei dati.Infatti, in un sistema monolitico si usano le transazioni pergarantire la consistenza del dato.

Le transazioni distribuite sono notoriamente complesse.Su architetture a MicroServices si parla di Transactionlesstra i servizi con il riconoscimento che la coerenza puòessere solo eventualmente consistente e tali problemisono trattati dalle operazioni di compensazione per nonandare a degradare le performance.

La scelta di trattare la consistenza in questo modo è unagrande sfida per i team di sviluppo e molto dipende dalleperformance che si vogliono ottenere dal sistema.

Spesso per sistemi ad alte performance si accettanoconsistenze parziali che poi vengono rese totali daprocessi asincroni.

PAGINA 18

INFRASTRUTTURE AUTOMATIZZATE

Le tecniche di automazione delle infrastrutture si sonoevolute enormemente nel corso degli anni e l’avvento delCloud, in particolare di AWS, ha ridotto la complessitàoperativa di costruzione e distribuzione delle applicazionia MicroServizi operativi.

Molti dei prodotti più recenti vengono sviluppati da teamcon grande esperienza in sistemi di continuous delivery econtinuous integration.

Sempre di più il team di sviluppo fa uso di tecniche diautomazione delle infrastrutture per migliorare la qualitàdel proprio lavoro.Nel seguito riportiamo la pipeline tipica dei processi diautomazione:

Grazie all’evoluzione dei sistemi di automazione, in questiultimi anni, per il team di sviluppo le procedureautomatiche vengono prevalentemente utilizzate per testautomatici che permettono di distribuire in ambiente diproduzione software funzionanti e facilitano i sempre piùveloci cicli di rilascio.

Fig.5: Processo di automazione

PAGINA 19

PROGETTARE PER FALLIRE

Una conseguenza dell'utilizzo di servizi come componentiè che le applicazioni devono essere progettate in modotale da poter essere tolleranti ai fallimenti.Infatti, potrebbero verificarsi delle situazioni in cui unclient contatta un servizio e questo potrebbe non esserein grado, per qualche motivo, di fornire una risposta.Il fatto di avere molteplici servizi aumenta il rischio di unamomentanea indisponibilità di qualcuno di questigenerando uno svantaggio rispetto ad un designmonolitico in quanto si verifica una maggiore complessitàdi gestione a seguito del verificarsi di problematiche diquesto tipo.La progettazione di architetture a MicroServices richiedeal team di sviluppo un’attenta progettazione dellasoluzione per capire come eventuali disservizi si possanoriflettere nell’esperienza dell’utente nell’uso quotidiano delsistema.Anche in questo caso Netflix è un punto di riferimentoperché induce fallimenti costanti nei propri servizi e centridati al fine di verificare il comportamento dell’architetturaed essere sempre pronti a gestire eventuali imprevisti.Poiché i servizi possono fallire in qualsiasi momento, èimportante essere in grado di rilevare i guasti in modorapido e, se possibile, di ripristinare automaticamente ilservizio. E’ fondamentale per chi progetta e sviluppasistemi a MicroServices integrare tools e strumenti per ilmonitoraggio in tempo reale dei servizi.Il monitoraggio è fondamentale per individuarecomportamenti anomali dei servizi e, rapidamente, ilproblema per poi risolverlo.

PAGINA 20

PROGETTAZIONE EVOLUTIVA

Per un team di sviluppo abituato a lavorare in ottica dievoluzione dell’applicativo, progettare e svilupparearchitetture a MicroServices significa consentire aglisviluppatori di controllare l’evoluzione della loroapplicazione senza rallentare il cambiamento.Infatti, con gli atteggiamenti e gli strumenti giusti, èpossibile apportare modifiche frequenti, veloci e bencontrollate al software.

Ogni volta che si tenta realizzare un sistema software acomponenti ci si trova di fronte alla decisione di comedividere i pezzi - quali sono i principi su cui decidiamo ditagliare la nostra applicazione?La proprietà chiave di una componente è la capacità dipoter essere sostituito e/o aggiornato senza influenzare ilcomportamento dei suoi collaboratori.

Spesso un approccio per avvicinarsi allo sviluppo diMicroServices è quello di trasformare il progetto softwaremonolita iniziale in API afficancandovi nuovi serviziindipendenti per erogare nuove funzionalità e, nelprocesso evolutivo, “smontare” il monolita pertrasformarlo in tanti piccoli servizi in grado di offrirenuove funzionalità in modo sempre più efficiente.La modularità e molteplicità di servizi permette poi, nelcorso del tempo, di evolvere o sostituire i singolicomponenti in completa trasparenza verso gli altri servizi.

PAGINA 21

Mettere i componenti in servizi genera l'opportunità diottenere una maggiore pianificazione granulare. Con unmonolita eventuali modifiche richiedono una generazionecompleta e la distribuzione dell'intera applicazione.Con MicroServices, invece, è necessario soltantoridistribuire il servizio che è stato modificato,semplificando e accelerando il processo di rilascio. Ilrovescio della medaglia è che ci si dovrà preoccuparedelle modifiche a un servizio senza interrompere le attivitàdei suoi “consumatori”. L'approccio di integrazionetradizionale è cercare di affrontare questo problemautilizzando il controllo delle versioni ma, nel mondoMicroServices, si preferisce utilizzare solo le risorseall’ultima versione permettendo così ai servizi di essere ilpiù tolleranti possibile ai cambiamenti.

SONO I MICROSERVICES IL FUTURODELLE ARCHITETTURE SOFTWARE?L’obiettivo di questo Whitepaper è di fornire una visionead alto livello di quali sono gli elementi per progettare emantenere un’architettura a MicroServizi.

Esistono molti esempi di aziende che utilizzano in modoefficiente architetture a MicroServices tra queste Amazon,Netflix, The Guardian...Nonostante queste esperienze positive, tuttavia, non èpossibile sostenere con certezza che i MicroServices sianola direzione futura per architetture software.

Sulla base della nostra esperienza, i risultati sono statiestremamente positivi in termini di efficienza di sviluppo,facilità di evoluzione di una soluzione software e gestioneeterogenea dei dati rispetto ad applicazioni monolitiche.

PAGINA 22

Siamo consapevoli però che questo nuovo modello nonsia la soluzione a tutte le necessità ma che in ognicontesto deve essere fatta un’analisi degli effettivivantaggi e svantaggi prima di decidere se adottare unapproccio tradizionale oppure un’architettura aMicroServces.Trattandosi di un nuovo modello di sviluppo, solamentetra qualche anno saremo in grado di identificare i limiti diquesto approccio ma in questo momento, per i risultatiottenuti, un cauto ottimismo ci porta a dire che i vantaggidi un approccio a MicroServices può essere un’ottimachiave su cui costruire le evoluzioni delle soluzioni digitaliper i prossimi anni.

WWW.ZERO12.IT