AUTORI

Martino Zito
Director @Bip xTech

Negli ultimi tempi si sente sempre più parlare di “micro-services” ma cosa sono effettivamente ed in che modo possono essere utilizzati in maniera efficace e proficua?

Negli ultimi tempi si sente sempre più parlare di “micro-services”, il che è molto strano. Mai tanta attenzione era stata dedicata ad uno stile architetturale. Le architetture software, infatti, sono da sempre state appannaggio di specialisti di settore, e vedere tale eco mediatica lascia sicuramente stupiti.

Le architetture a micro-servizi (aka MSA) vengono utilizzate per la realizzazione di strati di servizio applicativi di sistemi o piattaforme. L’architettura, a livello elementare, è costituita da un insieme di processi (micro-servizi) che interagiscono tra di loro. Ogni micro-servizio si comporta in maniera indipendente dagli altri ed è in grado di comunicare via rete per mezzo di interfacce software strutturate sincrone o asincrone (es. REST, Message Queue, …).  Ogni micro-servizio si occupa di gestire una risorsa o una funzionalità di business, ed ha una sua indipendenza tecnologica (linguaggi, framework) ed un suo strato di persistenza. Una buona progettazione in contesti a micro-servizi consente anche di poter dividere il lavoro di implementazione su più team potenzialmente indipendenti.

Visto in quest’ottica, quindi, il singolo micro-servizio non è molto diverso da un classico strato di servizio applicativo su un perimetro ristretto di funzionalità. Come può, quindi, un artefatto tecnico destare tanta eco? È realmente innovativo? È davvero un “game changer”? O è solo un’ennesima rivisitazione di concetti oramai noti?

Dal punto di vista puramente tecnico e relativamente al singolo micro-servizio la risposta alle ultime domande è “non c’e’ grande differenza”.

La chiave del successo è sostanzialmente che le architetture a micro-servizi sono il punto apicale evidente di tutta una serie di altre metodologie e tecnologie: Agile, Api First Design, Behavior Driven Development, Code Infrastructures, DevOps solo per citarne alcune.

In effetti, se valutate in combinata con queste ultime, esse assumono, a tutti gli effetti, delle caratteristiche tali da risultare un “game changer”.

Perché adottare una soluzione basata su MSA?

In rete sono disponibili elenchi infiniti di vantaggi e svantaggi nell’introduzione di una tale architettura. Talmente tanti da confondere. Ne riassumo alcuni significativi che possono giustificarne l’adozione.

Iniziamo a fare un distinguo tra l’acquisto di una soluzione basata su MSA e la realizzazione della stessa. Chiaramente i vantaggi nel caso di acquisto valgono anche successivamente alla realizzazione.

Nel primo caso (acquisto) la soluzione ha “out-of-the-box” le seguenti caratteristiche:

Indipendenza dall’ambiente. È basata sui container, quindi, a patto di avere a disposizione un orchestratore (Kubernetes, OpenShift, Mesos), è installabile “on-client-premises” o su qualsiasi public cloud provider e rilocabile qualora necessario.

Scalabilità indipendente. Ogni micro-servizio può essere scalato (replicato) indipendentemente dagli altri adeguando l’intera soluzione al carico richiesto. Eventualmente, per carichi impulsivi, il singolo micro-servizio, può essere scalato a zero ed attivato solo nel momento dell’effettivo bisogno.

Decadimento funzionale limitato. Essendo i micro-servizi indipendenti tra di loro il fallimento di uno di questi porterebbe ad un malfunzionamento del sistema limitato al micro-servizio impattato.

Upgrade a caldo. Ogni micro-servizio può essere aggiornato indipendentemente dagli altri in una modalità “plug&play”. È altresì possibile aggiornare l’intera soluzione in tempi molto rapidi con un disservizio nullo o limitato (minuti vs ore).

Qualora, nel secondo caso, decideste di realizzare una soluzione ex-novo (o di migrare una soluzione esistente) tale architettura ha le seguenti caratteristiche:

Realizzazione parallela. Essendo i micro-servizi indipendenti è possibile parallelizzare la loro realizzazione diminuendo il Time to Delivery e di conseguenza il Time To Market.

Indipendenza tecnologica e poliglottismo. I singoli micro-servizi possono essere realizzati con linguaggi, framework e tecnologie differenti. Questo permette di utilizzare la tecnologia più in aderenza con il bisogno o di sfruttare competenze già disponibili nei vari team.

Riusabilità degli artefatti.  Alcuni micro-servizi che espongono funzionalità standard (es. logging, auditing, accounting, file storage) potrebbero essere già disponibili e utilizzabili in logica “plug & play” nel contesto della realizzazione.

Manutenibilità. Ogni micro-servizio è sostituibile con una versione differente e migliorata a patto che rispetti la sua interfaccia di servizio. Inoltre, poiché il suo codice sorgente in genere è relativamente piccolo, esso risulta facilmente manutenibile e testabile.

Espandibilità. Qualora fosse necessario espandere le funzionalità del sistema basterebbe aggiungere dei micro-servizi addizionali.

E’ sempre vantaggioso realizzare architetture a microservizi?Non sempre. È dimostrato che una tale architettura risulta efficace per sistemi ricchi di funzionalità o che si pensa di espandere nel futuro. Qualora la realizzazione fosse piccola e perfettamente perimetrata altre architetture risulterebbero più “cost effective”.

Competenze necessarie per la realizzazione di una MSA

Le MSA, come tutte le architetture distribuite, necessitano della presenza di un architetto software per una loro implementazione. Questa figura è sempre più spesso affiancata da figure fino ad ora scarsamente presenti quali DevOps EngineersTesting Engineers Cloud infrastructure Architects.

La complessità si sposta dalla parte di codifica (relativamente semplice una volta definite le interfacce e le funzionalità) alla parte di progettazione e disegno. È necessaria una revisione dei pattern di disegno per andare incontro a problematiche prima aggirabili o inesistenti.

Con il suo avvento, nuovi termini sono stati coniati o reinterpretati. A puro titolo esemplificativo: Event Sourcing, CQRS, Circuit Breaking, Saga, Eventual Consistency, Api Gateway, Service Mesh.

Realizzare un sistema basato su tale architettura introduce una tematica di cambiamento culturale oltre che di up-skilling re-skilling delle risorse di cui bisogna tener conto.

Il principale fattore di successo in una realizzazione MSA è il modo con cui queste vengono messe in opera più che non le tecnologie stesse.

MSA implementation success-cases:

Nel panorama mondiale le MSA sono venute alla luce a livello Enterprise circa 6 anni fa. Uno dei precursori internazionali è stata la piattaforma di streaming video Netflix seguita quasi in contemporanea dal servizio di streaming audio Spotify, dalla piattaforma di prenotazioni AirB&B, dal sito di E-commerce di abbigliamento Zalando. Ognuno di loro ha contribuito al successo dell’architettura diffondendo esperienze e “lesson learnt”.

Il caso forse più emblematico di successo aziendale dovuto all’utilizzo dell’architettura a microservizi è quello di Amazon[1]. L’originario sito web per l’acquisto di libri online era infatti un’applicazione monolitica, in cui aggiungere nuove funzionalità end-user risultava molto complesso sia dal punto di vista tecnico che organizzativo, e che offriva limitata scalabilità in caso di picchi di richieste. Amazon ha quindi intrapreso un percorso di reingegnerizzazione dell’applicazione con microservizi dedicati a singole funzionalità di business (come il carrello), ognuno gestito da un singolo team di sviluppo, e processi di rilascio standardizzati e automatizzati con pratiche di CI/CD.  Questo ha consentito ad Amazon di realizzare ogni anno milioni di nuove funzionalità, e di disporre di nuove e significative competenze nella realizzazione di infrastrutture altamente scalabili, che hanno portato alla fondazione di AWS nel 2006, generando un nuovo Business per l’azienda.

Seguendo questi esempi di successo, attualmente sono innumerevoli le realtà che utilizzano questa tipologia di architettura per la realizzazione di piattaforme ex-novo o per la migrazione da architetture differenti nel settore del B2C/B2B.

Da qualche anno anche grosse realtà italiane stanno migrando alcuni dei loro sistemi aziendali ad uso B2C o B2B a questa architettura riconoscendone l’applicabilità e i benefici e spinti da tematiche di Digital Transformation e di migrazione verso il Cloud.

Le MSA a tutti gli effetti sono divenute lo standard de facto per la realizzazione dello strato di servizio di sistemi e piattaforme.

Bip xTech: un’offerta end-to-end

Bip xTech da anni segue i suoi clienti nell’introduzione e implementazione di tecnologie innovative. Tra queste, relativamente alle architetture software, le architetture a micro-servizi (MSA), le architetture serverless (BaaS, FaaS), le architetture guidate dagli eventi (EDA).

Tra le nostre figure professionali annoveriamo Architetti SoftwareArchitetti di InfrastruttureDevOps EngineerTesting Engineer Developer altamente qualificati che coprono end-to-end il ciclo di realizzazione.

Da circa 4 anni accompagniamo i nostri clienti nel disegno e nella realizzazione di applicazioni enterprise basate su MSA principalmente B2B.

Verso il futuro, insieme

La conoscenza tecnologica e la capacità di fare sono l’ingrediente necessario e indispensabile per qualunque realizzazione tecnologica ma non l’unico.

Da sempre Bip accompagna i suoi clienti nello sviluppo del loro business e aiuta a governare le progettualità su tutte le scale di complessità.

Sono proprio la conoscenza di dominio e la capacità di governo dei progetti unite alla competenza tecnica la chiave del successo delle progettualità, sempre volte al massimo beneficio per i nostri clienti.


Se sei interessato a saperne di più sulla nostra offerta o vuoi avere una conversazione con uno dei nostri esperti, invia un’e-mail a [email protected] con “Microservices” come oggetto, e sarai contattato prontamente.


Arrivederci al prossimo articolo che tratterà l’ambito delle “architetture serverless”!

[1] Werner Vogels “Modern applications at AWS”, https://www.allthingsdistributed.com/2019/08/modern-applications-at-aws.html

Leggi più approfondimenti

red lines

Contattaci

Milano, Italia | BIP xTech Head Office

Torre Liberty Building
Galleria de Cristoforis 1, Milan, 20121

[email protected]

    This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.