Questo articolo non vuole essere un altro documento tecnico sui Microservice e su tutte le tecnologie correlate. Il nostro obiettivo è in realtà più limitato ed è quello di spiegarvi nel modo più semplice possibile il nostro punto di vista su questo argomento, facendo capire perché questa tecnologia, oggi tanto di moda, possa essere il modo migliore per proiettare Sme.UP verso il futuro.

 

La rete è piena di documenti di ogni livello che spiegano per filo e per segno cosa sono i Microservice e come possano essere implementati nella miriade di tecnologie oggi disponibili e quindi non ci sembra il caso di ripetere qui le stesse cose.

Inevitabilmente una breve introduzione sui Microservice è comunque necessaria, almeno per capire di cosa stiamo parlando. Un buon punto di partenza può essere la figura riportata qui sotto, che vuole rappresentare a grandi linee l’evoluzione del software nel tempo.

La situazione è quindi passata da uno stadio iniziale in cui si concepiva il software come un grosso contenitore in cui le funzionalità non venivano pensate o mantenute indipendenti finendo, col passare del tempo, per avvinghiarsi le une alle altre, ad un secondo stadio in cui si poneva l’accento sulla suddivisione delle funzionalità più rigida sebbene ospitate su uno strato unico che fornisce funzionalità condivise.

L’evoluzione porta ora a pensare il software come un insieme di entità specializzate e completamente indipendenti nell’esecuzione dei propri servizi: sono moduli software totalmente autosufficienti, indipendenti, installabili ovunque, detti Microservice

Per i più curiosi rimandiamo all’approfondimento in calce all’articolo per qualche informazione in più su questo tema.

Sme.UP Way

Proviamo ora a capire perchè una architettura a Microservice può rappresentare la base ideale per lo sviluppo futuro del gestionale Sme.UP.

Sme.UP SOA

Sme.UP non è mai stato un software monolitico, visto che sin dalla sua nascita ha introdotto e fatti suoi dei concetti di modularità e di programmazione funzionale tipici di architetture SOA. Tutto questo in un periodo dove i software concorrenti erano rigidamente monolitici e per di più lavorando su una architettura, l’OS400, sicuramente apprezzata per l’affidabilità e per le prestazioni ma da molti ritenuta (erroneamente) inadatta allo sviluppo di applicazioni SOA.

Il vero limite di Sme.UP è quello di essere un sistema completamente modulare e fortemente orientato ai servizi, costretto però a subire i limiti architetturali di una piattaforma legacy. Questa situazione porta al rischio concreto di essere ingiustamente considerato un software AS400 (inteso come sinonimo, sbagliato, di cosa vecchia) dimenticando, o ignorando, la capacità di questo gestionale di essere un fornitore di servizi di alto livello capace di interagire con il resto del mondo con tutte le modalità oggi richieste ad un software di ultima generazione.

I Microservice potrebbero quindi rappresentare la soluzione architetturale ideale perchè Sme.UP possa diventare un sistema SOA di ultima generazione, pronto per il cloud, il multipiattaforma e la computazione distribuita. I servizi ci sono e sono davvero tanti e di ottimo livello, la scommessa è liberarli dai limiti del loro substrato legacy e renderli disponibili in modo naturale a qualsiasi contesto operativo.

Evolvere e progredire

Ovviamente il processo di migrazione non è semplice e nemmeno immediato, anche tenendo conto della molteplicità di funzioni svolte da un prodotto complesso come Sme.UP; per questo è importante procedere per gradi, prendere decisioni ben ponderate e non dimenticare mai che una scelta sbagliata presa in fase di impostazione del progetto potrà avere effetti catastrofici sulla qualità del prodotto finale.

Per questo motivo, all’interno dello Sme.UP LAB si è deciso di iniziare un percorso graduale di avvicinamento alle architetture Microservice avviando un nuovo progetto di sviluppo. L’obiettivo, nemmeno tanto nascosto, è quello di ottenere i classici “due piccioni con una fava”: Sviluppare un nuovo prodotto che copra una necessità esistente e al tempo stesso accumulare preziose esperienze sulle architetture Microservice da spendere poi nell’ottica di un software multipiattaforma.

The choosen one

L’idea di creare un primo progetto che permettesse di approcciare le tematiche relative ai microservice aveva bisogno di identificare un contesto consono a quanto intendevamo fare.

Abbiamo quindi identificato in uno degli ambiti in cui si muoveva Sme.UP Provider il luogo in cui far nascere questo nuovo software. Il percorso evolutivo di Sme.UP Provider stava infatti ponendo la necessità di una rottura di continuità nella sua evoluzione per far fronte alle sfide future.

Si è dunque deciso di realizzare un nuovo prodotto, che abbiamo chiamato Sme.UP Gateway, che superasse le limitazioni tecniche del prodotto esistente e fornisse migliori prestazioni, maggior stabilità e migliore scalabilità. Il tutto utilizzando un’architettura moderna e allineata alle più recenti tendenze in ambito dei sistemi distribuiti, riutilizzando quanto funzionava del predecessore e garantendo il più possibile la continuità funzionale.

L’obiettivo che ci siamo posti è stato la realizzazione di un nuovo framework basato su microservice e dedicato, almeno in fase iniziale, a due temi di integrazione attualmente gestiti tramite Sme.UP Provider:

  • Internet delle cose (IOT) e rilevamento dei dati di fabbrica (in ottica MES)
  • Web Service consuming (SOAP e REST).
  • Wev Service providing (SOAP e REST).

Going live

Siamo prossimi al rilascio ufficiale di Sme.UP Gateway.

Dopo una fase iniziale dedicata soprattutto alla ricerca e valutazione delle soluzioni tecnologiche esistenti, lo sviluppo si è concentrato sulla creazione del framework operativo mantenendo un approccio rigorosamente basato su microservice.

Grazie a questa architettura, Sme.UP Gateway può essere configurato in funzione del carico di lavoro previsto e scalato in modo relativamente semplice sfruttando le funzionalità di clustering e parallelizzazione tipiche delle architetture a microservizi.

La varietà di configurazioni possibili è molto ampia: dal nodo unico su un server (reale o virtuale) che implementa in un luogo solo tutti i servizi necessari fino ad arrivare a strutture iper parcellizzate dove ogni singolo nodo fornisce un solo servizio.

La parcellizzazione della struttura è il requisito necessario per garantire anche le funzionalità di secondo livello, come la business continuity, la fault tolerance oppure il deploy dinamico, concetti molto importanti in una moderna architettura software distribuita.

Ogni singolo microservice che compone il framework può essere considerato un elemento isolato e in ogni momento può essere sostituito o affiancato da un altro servizio che sa fare la stessa cosa in modo diverso. Il tutto senza vincoli tecnologici; ad oggi il grosso dei servizi è scritto in linguaggio java, ma ciò non toglie che un servizio scritto in un altro linguaggio si possa registrare nel framework e fornire i suoi servigi.

Per concludere, il lavoro fatto fino ad ora è stato tanto, sia di ricerca che di sviluppo e i risultati iniziano a vedersi. L’obiettivo è sicuramente molto ambizioso e la strada da fare è ancora lunga e piena di incognite, anche se oggi sono molte meno di ieri e domani saranno ancor meno.

Ma, come dice il proverbio, “si può mangiare anche un elefante, basta farlo un boccone alla volta”.

E di sicuro a noi dello Sme.UP LAB la fame di novità non manca.

Sme.UP ERP e gli altri

Sme.UP ERP ed il mondo fisico

Approfondimento

Qualche ulteriore dettaglio sulla strada che ha portato ai Microservice

All in one

In origine un pò tutti i software erano monolitici. E’ un’architettura figlia di una concezione del software oggi considerata arcaica un pò da tutti (tranne forse da chi vende ancora questo tipo di prodotti). Il software monolitico può essere visto come un unico calderone che contiene tutto. La complessità globale del sistema aumenta in maniera esponenziale all’aumentare delle funzionalità implementate, il che con il tempo porta inevitabilmente ad una situazione talmente complessa da rendere difficile non solo lo sviluppo di nuove funzionalità ma anche la manutenzione di quelle esistenti. Può sembrare una situazione abbastanza anacronistica per il giorno d’oggi ma in realtà sono ancora molti i prodotti, anche noti, che possono essere ascritti in questa categoria.

Divide et impera

Il deciso passo avanti nell’evoluzione è stata l’introduzione delle cosiddette Service Oriented Architecture (SOA). Il funzionamento del sistema è basato su servizi, cosa che favorisce lo sviluppo modulare e consente di definire con precisione le responsabilità (chi fa cosa). Dal punto di vista funzionale, le architetture SOA sono un grosso passo avanti rispetto alle architetture monolitiche, consentono un maggior ordine e favoriscono la riusabilità del codice.

Tutto questo però si paga con una maggiore complessità tecnica dovuta soprattutto alla necessità di avere un framework comune che faccia da “collante” tecnologico tra i vari servizi e che di fatto ne limita la libertà di azione (solo chi è nel framework può fornire o fruire di servizi).

Let’s make some music

Veniamo infine ai Microservice, oggi tanto di moda, che da un certo punto di vista possono essere considerati come la rivisitazione in chiave moderna delle architetture SOA.

Nelle architetture microservice il concetto di servizio (che in realtà può essere tutt’altro che micro) viene portato all’estremo e viene introdotto un concetto di indipendenza funzionale; un microservice diventa un’entità in grado di svolgere un servizio in modo completamente autonomo e indipendente dal contesto in cui verrà utilizzato (principio di singola responsabilità o SRP). Non esistono vincoli implementativi sul singolo microservice, nella stessa architettura possono convivere microservice scritti con linguaggi diversi o attestati su diverse piattaforme; l’unica cosa davvero importante è che il servizio offerto dal singolo microservice sia ben definito ed accessibile.

Ovviamente perché un software complesso possa funzionare con un’architettura così eterogenea e frammentata è necessario che qualcuno svolga un’operazione di orchestrazione, cioè che esista un’entità in grado di coordinare il flusso operativo e l’accesso ai servizi disponibili.

Praticamente un sistema a Microservice può essere pensato come una grande orchestra sinfonica, composta da tanti maestri ognuno in grado di suonare in maniera eccellente uno specifico strumento.

In teoria c’è tutto il know how che servirebbe per eseguire una sinfonia ma perchè la cosa sia davvero possibile è necessario l’intervento di un direttore d’orchestra che coordini le risorse in campo e porti al risultato voluto. Per la loro natura le architetture microservice sono particolarmente adatte per contesti molto eterogenei e multipiattaforma e sono la base su cui sono create le piattaforme cloud oggi tanto in voga.

Credits: Dario Foresti, Giuliano Giancristofaro