Microservices, Sme.UP ERP e IoT Gateway

Il nostro obiettivo è in realtà più limitato ed è quello di spiegarvi nel modo più semplice possibile il nostro punto di vista sull’argomento e capire insieme perché questa tecnologia, oggi tanto di moda, potrebbe essere il modo migliore per proiettare smeup verso il futuro.

Inevitabilmente una breve introduzione sui Microservices è 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.

Introduzione

In origine un po’ tutti i software erano monolitici. E’ una architettura figlia di una concezione del software oggi considerata arcaica un po’ 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.

Il deciso passo avanti nell’evoluzione è stata l’introduzione delle cosiddette Service Oriented Architectures (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).

Microservices

Veniamo infine ai microservices, 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 microservices 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 microservices 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 in qualche modo. 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 Microservices 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 microservices sono particolarmente adatte per contesti molto eterogenei e multipiattaforma e sono la base su cui sono create le piattaforme cloud oggi tanto in voga.

Fatta questa doverosa premessa teorica (ma non troppo), proviamo a capire perché una architettura a Microservices può rappresentare la base ideale per lo sviluppo futuro del gestionale smeup.

Microservices e Sme.UP ERP

smeup 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’AS400, sicuramente apprezzata per l’affidabilità e per le prestazioni ma da molti ritenuta (erroneamente) inadatta allo sviluppo di applicazioni SOA.

Il vero limite di smeup è quello di essere un sistema completamente modulare e fortemente orientato ai servizi ma costretto però a subire i limiti architetturali di una piattaforma legacy. Con il rischio concreto di essere ingiustamente considerato un software AS400 (inteso come sinonimo, sbagliato, di cosa vecchia) dimenticando in un colpo solo tutta l’enorme mole di lavoro che è stata fatta negli anni per rendere questo gestionale 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 microservices potrebbero quindi rappresentare la soluzione architetturale ideale perché smeup 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, si tratta solo di liberarli dal loro substrato legacy e renderli disponibili in modo naturale a qualsiasi contesto operativo.

Ovviamente il processo di migrazione non è semplice e nemmeno immediato, anche tenendo conto della molteplicità di funzioni svolte da un prodotto complesso come smeup; 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.LAB si è deciso di iniziare un percorso graduale di avvicinamento alle architetture Microservices avviando un nuovo progetto di sviluppo. L’obiettivo, nemmeno tanto nascosto, è quello di ottenere i classici due piccioni con l’altrettanto classica fava: sviluppare un nuovo prodotto che copra una necessità esistente e al tempo stesso accumulare preziose esperienze sulle architetture Microservices da spendere poi in ottica smeup multipiattaforma.

IoT Gateway

Il progetto scelto è stato IoT Gateway (il nome potrebbe non essere quello definitivo). L’obiettivo è lo sviluppo di un nuovo framework basato su microservices e dedicato, almeno in fase iniziale, all’interazione del gestionale smeup con l’Internet delle cose (IoT) e al rilevamento dei dati di fabbrica (in ottica MES). Oggi queste funzionalità sono già coperte dallo SmeUP Provider, installato da molti dei nostri clienti e operativo anche in realtà complesse. Ma visto il crescente interesse generale attorno a questo tipo di tematiche si è comunque deciso di sviluppare un nuovo prodotto che superi le limitazioni tecniche del prodotto esistente e fornisca migliori prestazioni, maggior stabilità e migliore scalabilità. Il tutto utilizzando una architettura moderna e allineata alle più recenti tendenze in ambito dei sistemi distribuiti.

Attualmente si può considerare IoT Gateway in una fase avanzata di sviluppo. 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 microservices. Grazie a questa architettura, IoT 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 singolo 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 (per una questione di know how interno del laboratorio) ma ciò non toglie che un servizio scritto in un linguaggio completamente diverso si possa registrare nel framework e fornire i suoi servigi.

Per concludere, il lavoro fatto fino ad oggi è stato tanto, sia di ricerca che di sviluppo e i risultati iniziano a vedersi. C’è però ancora molto da fare e da provare, sia per il progetto IoT Gateway ma soprattutto per la modernizzazione di smeup verso il multipiattaforma. 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 di Sme.LAB la fame di novità non manca.