Dalle applicazioni desktop al database su server. Dallo sviluppo basato sui componenti alle service oriented architecture. Che cosa renderà i microservice il paradigma vincente?
By Sander Hoogendoorn
Nel lontano 1988, al mio primo impiego presso una società per scrivere software, il mondo era abbastanza semplice. L’ambiente di sviluppo era basato su caratteri. Il database era integrato e attraversato da cursori. E avevamo costruito un intero nuovo sistema amministrativo che copriva tutto tranne il lavello della cucina. Ci vollero cinque anni per completare il progetto, soprattutto perché il cliente continuava a cambiare idea spesso e perché ogni cambiamento nel codice avrebbe potuto rompere il codice in altre parti del sistema. L’unit testing non era ancora stato inventato e il collaudo veniva svolto dagli utenti finali, in produzione.
Fin qui si trattava di monoliti, ma nel 1994 passai a un’azienda che realizzava applicazioni desktop. Non dimentichiamo che il world wide web era nato solo da un paio di anni e che le applicazioni web non erano ancora state inventate. Utilizzavamo un ottimo strumento chiamato PowerBuilder e ora avevamo due componenti di cui preoccuparci: l’applicazione sul desktop e il database sul server. Le applicazioni che costruivamo di solito servivano per i reparti o talvolta anche per l’intera azienda. Non erano molto complicate, ma nemmeno altamente scalabili. Insomma, ci divertivamo, almeno fino a quando è durato il paradigma client-server.
Lo sviluppo basato sui componenti
Ma il mondo divenne più complesso a metà degli anni Novanta: le aziende volevano applicazioni web, in genere eseguite su intranet, per potersi sbarazzare delle implementazioni desktop, e chiedevano applicazioni necessarie per servire più reparti e talvolta anche per andare oltre i confini aziendali. Nacque un nuovo paradigma: lo sviluppo basato sui componenti, noto anche come CBD, component based development. Il paradigma prometteva il riutilizzo, la scalabilità, la flessibilità e un modo per raccogliere il codice esistente (di solito scritto in COBOL). Così iniziammo a scomporre i nostri sistemi in grandi blocchi funzionali, e a cercare di far comunicare tra di loro quei componenti. Fu inventato Java, e tutti improvvisamente volevano scrivere codice in Java (e a quanto pare alcuni cercano di farlo ancora oggi). I componenti venivano eseguiti su tecnologie impossibili come application server e CORBA (se volete impressionare i vostri collaboratori, cercate quest’ultimo su Wikipedia). Ah, i bei vecchi tempi degli object request broker!
In quel periodo lavoravo per una grande banca internazionale, cercando di impostare una metodologia per fare sviluppo basato sui componenti. Ma anche con un team pesantemente armato di consulenti Andersen ci vollero tre anni per scrivere il sistema: alla fine, sia il paradigma sia la tecnologia erano troppo complessi per scrivere software decenti e performanti. Semplicemente non decollò mai.
La service oriented architecture
Poi, nei primi anni di questo secolo, pensavo che ci fossimo sbarazzati dello sviluppo software distribuito e avessimo felicemente iniziato a costruire applicazioni web. Credo che tutti ignorassero coraggiosamente la prima legge di Martin Fowler sugli oggetti distribuiti: non distribuite i vostri oggetti. A poco a poco ci siamo spostati nel paradigma successivo del computing distribuito, reimpacchettando le promesse dello sviluppo basato su componenti in un insieme rinnovato di tecnologie. Così, iniziammo a sviluppare business process modeling (BPM) e a implementare questi processi in Enterprise Service Bus (ESB), con servizi di fornitura dei componenti. Eravamo nell’età della Service Oriented Architecture, meglio conosciuta come SOA. Venendo dal CBD, la SOA sembrava più facile. Finché i componenti – i producer – sono agganciati nell’enterprise service bus, eravamo in grado di costruire sistemi scalabili e flessibili, visto che ora avevamo componenti molto più piccoli che si potevano davvero estrarre dai nostri sistemi esistenti (e ormai non scritti solo in COBOL, ma anche in PowerBuilder, .NET e Java). I libri con gli schemi obbligatori di progettazione erano stati pubblicati e il mondo era pronto ad andare avanti: questa volta sarebbe stata quella giusta!
Mi sono trovato a lavorare per una società di trasporti internazionali, realizzando felicemente applicazioni sul middleware SAP, fornendo tool ESB e BPM. Non avevamo bisogno solo di regolari sviluppatori Java e .NET, ma anche sviluppatori di middleware e consulenti SAP. E anche se la metodologia agile era stata introdotta per accelerare lo sviluppo (lo so, questo non è l’argomento più adatto), i progetti mostravano ancora una certa lentezza. Ma soprattutto, una volta messi a posto tutti i pezzi del puzzle, abbiamo iniziato a capire che i test di integrazione e l’implementazione di nuove release diventavano sempre più complicati di giorno in giorno.
Finalmente i microservice!
Spero che i lettori mi perdoneranno per questa lunga e tortuosa introduzione al tema attuale: i microservice, che qualcuno chiama anche microservizi. Certamente si potrebbe obiettare sulla necessità di avere un altro articolo sui microservice, visto che sull’argomento c’è già molta letteratura. Ma se si guarda da vicino al diluvio di articoli che si trovano su internet, la maggior parte descrivono solo i vantaggi e le possibilità dei microservice, e alcuni prendono in esame i pochi esempi famosi (Netflix, Amazon, e Netflix, e Amazon e Netflix e …). Solo un paio di articoli scavano davvero nel profondo, e di solito consistono nell’elencare le tecnologie che si usano nell’implementazione dei microservice. Forse siamo ancora a uno stadio iniziale.
Per questo, un po’ di prospettiva storica non farà male. Trovo interessante constatare che i benefici e le possibilità dei predecessori dei microservice sono ancora con noi. I microservice sembrano promettere sistemi scalabili e flessibili, basati su piccoli componenti che possono essere facilmente implementati in modo indipendente, e quindi promuovono l’uso delle migliori scelte nel campo delle tecnologie per componenti. Fondamentalmente, si tratta delle stesse promesse tipiche di CBD e SOA, quindi parrebbe non esserci nulla di nuovo, ma questo non vuol dire che non sia utile indagare sui microservice.
Questa volta è diverso?
Insomma, cosa c’è di diverso questa volta? Cosa renderà i microservice il paradigma vincente, come invece non erano i suoi predecessori? Che cosa lo fa emergere? Come sviluppatore, non c’è dubbio che sono piuttosto entusiasta dei microservice, ma lo ero anche (più o meno) quando vennero fuori CBD e SOA. Io suppongo che ci siano alcune differenze. Per la prima volta, sembra che siano disponibili tutte le tecnologie necessarie per realizzare questo tipo di architetture. Tutto il middleware frivolo e complesso è sparito, e ci si affida esclusivamente su protocolli web e su tecnologie di base e soprattutto esistenti da lunga data: basta solo confrontare REST a CORBA. Inoltre, ci sembra di comprendere molto meglio il deployment, alla luce del fatto che abbiamo imparato come fare l’integrazione continua, l’unit testing e anche l’erogazione continua. Queste differenze suggeriscono che questa volta siamo in grado di far funzionare tutto. Eppure, dal mio punto di vista storico, un certo scetticismo è inevitabile. Anche dieci anni fa, eravamo davvero convinti che la SOA sarebbe stata tecnologicamente fattibile, avrebbe risolto tutti i nostri problemi e ci avrebbe messo in grado di costruire rapidamente cose più riutilizzabili e più affidabili. Quindi, per essere onesti, il fatto che noi crediamo che la tecnologia sia pronta, non costituisce un argomento particolarmente valido. Perché nel frattempo, anche il mondo è diventato più complesso. Nel corso dell’ultimo anno, ho avuto a che fare con una società che si sta allontanando dal mainframe (troppo caro) e da una serie di monoliti Java meno recenti (troppo grandi e difficili da mantenere). Anche il time-to-market svolge un ruolo importante: l’IT deve supportare l’introduzione di un nuovo prodotto nell’arco di pochi mesi, se non di settimane. Così abbiamo deciso di essere alla moda e adottare i microservice.
Ma se volete conoscere il buono, il brutto e il cattivo dell’architettura microservice, così come ho avuto modo di vedere nel corso del nostro primo anno di utilizzo, dovete leggere il mio riepilogo sul prossimo numero di Data Manager.
Sander Hoogendoorn
Mentore, allenatore, software architect, sviluppatore, speaker e scrittore. Apprezzato dai suoi numerosi clienti internazionali come grande innovatore nello sviluppo software, è autore del best-seller “This is Agile”. Ha scritto libri anche su UML e pubblicato più di 250 articoli su riviste specializzate. Oltre a essere keynote speaker in molte conferenze internazionali, presenta seminari e corsi di formazione in tutto il mondo.
Sander Hoogendoorn presenterà a Roma per Technology Transfer i seminari “Agile, Scrum, XP, Kanban e Continuos Delivery in pratica” il 22 aprile 2016 e “Progettare, sviluppare e implementare una Microservices Architecture” il 10 giugno 2016.
