Le best practice per architettare un software hanno subito una radicale trasformazione in questi anni. Guidate dal paradigma della trasformazione digitale, le aziende si sono scontrate con i limiti delle modalità di consumo dei servizi informativi On Premise, dove le soluzioni Client/Server su LAN si sono rivelate inadeguate a soddisfare le nuove aspettative di accessibilità e resilienza dei dati. Esporre a device mobili e dashbord di Business Intelligence le informazioni contenute nelle tabelle del gestionale ERP aziendale si è spesso rivelato un frustrante calvario tra firewall bloccanti e protocolli di interscambio mai funzionanti realmente appieno. Sebbene gli ingegneri abbiano architettato sistemi ingegnosi tramite console schedulate, tabelle di confine e scambi di dati in formato CSV tramite FTP, l’impegno richiesto dalla manutenzione di queste soluzioni ha presto dimostrato quanto il sistema avesse necessità di un radicale cambio di architettura di fondo.
La progressiva virtualizzazione
La prima evoluzione significativa si è avuta con l’impiego di sistemi Back End appoggiati su Web Server, che erano in grado di pubblicare le informazioni necessarie ai processi di Business anche al di fuori del perimetro della rete aziendale.
Queste nuove possibilità hanno determinato anche una importante evoluzione nelle tecnologie di accesso ai dati: grazie al passaggio ai sistemi di Object Relational Mapping, i team di sviluppo hanno potuto beneficiare di un accesso ai dati più semplice e integrato nel codice rispetto alle Stored Procedure e alle View Transact SQL. Questo ha contribuito a una percezione della fruibilità del dato sempre più orientata alla specializzazione granulare piuttosto che a una esposizione monolitica ulteriormente da perfezionare lato client. Grazie a tecnologie come Entity Framework, i team di sviluppo hanno potuto implementare API capaci di recuperare con precisione i range di dati specificamente necessari alle logiche di business front end, permettendo così un costante miglioramento delle prestazioni e dell’esperienza utente finale.
Container e microservizi
La specializzazione nella gestione del dato ha portato a una architettura più dinamica che si è progressivamente liberata dalle complessità della manutenzione legata al concetto classico di server e sistema operativo. A un primo passaggio dei server dal ferro alla macchina virtuale, è seguita una ulteriore evoluzione dettata dal bisogno dei team di sviluppo di potersi concentrare sulle specificità del software senza essere appesantiti da problematiche di tipo sistemistico.
Si è assistito così al fiorire della tecnologia dei Container, o Docker, sistemi in grado di ospitare logiche software oscurando agli sviluppatori i layer relativi alle componenti di più basso livello. Questo nuovo ambiente si è rivelato l’ecosistema ideale per il proliferare di logiche business strutturate su microservizi. Attenzione, infatti, a non confondere i due concetti: container e microservizio non sono la stessa cosa. Il contanier è una risorsa dedicata all’allocazione e alla condivisione, mentre il microservizio in sé è fondamentalmente un pattern software.
I vantaggi dei microservizi
L’architettura a microservizi prevede, infatti, che il codice sia strutturato in modo da garantire obbligatoriamente una serie di vantaggi rispetto ai tradizionali pattern di sviluppo.
Il primo di questi vantaggi è una elevata semplicità di test e debugging: con i microservizi la logica di business viene spezzettata in tante unità dedicate a compiti specifici, che sono perciò più facilmente verificabili di un lungo flusso di istruzioni o di una complessa rete di oggetti interdipendenti.
Il secondo vantaggio è che il gruppo di sviluppo si può dividere in team più piccoli, che possono dedicarsi alla gestione del singolo servizio a loro dedicato. Per esempio, un team potrebbe dedicarsi alle funzioni che gestiscono l’interfaccia web per i desktop, mentre un altro team potrebbe specializzarsi sull’interfaccia dedicata ai device mobili Android. Questa suddivisione dei compiti permette anche ai nuovi assunti di diventare produttivi in tempi più rapidi, perché devono essere formati solo sulle specifiche relative al microservizio su cui andranno a lavorare, tralasciando i dettagli del progetto. I microservizi, infine, offrono anche una scalabilità eccezionale, proprio grazie alla loro granularità. Ipotizziamo, infatti, che su una dashboard incontri particolare successo una particolare funzione statistica. Per migliorarne le prestazioni in rapporto alla crescita del numero di utenti, sarà sufficiente scalare il microservizio che la gestisce, e non tutta la dashboard.
Tecnologie di microservizi
Essendo un pattern software, il microservizio non è una tecnologia di esclusivo appannaggio di un particolare vendor. Ci sono, però, delle soluzioni che si sono diffuse più di alcune altre, sia per aspetti di natura economica, sia per motivi prettamente tecnologici. Una soluzione ampiamente utilizzata sono le Azure Functions, che permettono di realizzare logiche di software senza doversi preoccupare di nessun aspetto legato alla gestione dei componenti di basso livello. Le funzioni di Azure sono attivabili da diversi tipi di trigger, sia a chiamata, sia a schedulazione, e vengono fatturate a consumo, ossia solo per il tempo che vengono effettivamente utilizzate dalla vostra applicazione. Altre diffuse soluzioni basate su microservizi sono quelle di Spring, un framework basato su JAVA specializzato nella produzione i soluzioni serverless, impiegato da numerose applicazioni anche di grande successo commerciale.
