Consigli per un approccio ai Microservizi, ma anche ad un nuovo modo di pensare
scritto da Riccardo Torsoli
Mi sono appassionato alla programmazione funzionale nel 2012 quando uscì il primo corso di Martin Odersky (creatore di Scala e professore all’ EPFL di Losanna ) su Coursera.
Seguire quel corso ha avuto una notevole influenza sul mio modo di programmare e di “vedere” il mondo della programmazione nel suo complesso.
Ne avevo sentito parlare anche in precedenza, durante il mio percorso consulenziale in Engineering nel 2009 grazie ad una uno dei maggiori talenti della programmazione italiana Federico Monaldi, ma erano per lo più discussioni extra lavoro con una visione rivolta al futuro.
Poi nel 2014 la visione del film Interstellar e la lettura del libro di Kip Thorne “La Fisica di Interstellar” (fisico teorico vincitore del premio Nobel per la fisica nel 2018 per gli studi sulla fisica gravitazionale e tra gli autori del film), mi resero piu chiaro perchè questo tipo di programmazione sarebbe diventata fondamentale (lo era già, ma ancora non era mainstream).
Nel libro Thorne spiega come un azienda, la Double Negative, sia riuscita a creare la grafica di un buco nero rotante grazie alle equazioni del fisico. terabyte di dati e di computazioni sequenziali e parallele per riuscire a definire un fenomeno gravitazionale agli occhi del pubblico: di questa opera d’arte ne beneficiò lo stesso Thorne che vide anche lui per la prima volta il prodotto delle sue teorie. Magnifico!
Quando il robot TARS supera l’Orizzonte degli Eventi e si avvicina alla singolarità registra tutti i dati che possono completare le equazioni esistenti sulla gravità permettendo all’ umanità di salvarsi, un operazione di streaming infinito con miriadi di computazioni.
Questo mi ha fatto riflettere ed ho pensato “Gli ingegneri che hanno costruito TARS come hanno potuto dargli queste possibilità?” la risposta che mi sono dato è stata “Grazie all’ AI”, ma poi mi sono posto una successiva domanda “Quali modelli hanno implementato?” e “Sarei in grado con la tecnologia che conosco di creare anche un prototipo di TARS?”.
La risposta è stata chiara “No!”. Il motivo è perché noi programmatori normali, non abbiamo le nozioni e gli strumenti per implementare tutto ciò.
Ma la tecnologia esiste, occorre solo apprenderla.
Da dove si comincia?
Ecco questa domanda si è tradotta in un percorso lungo e tortuoso ma avvincente. Prima si è trattato di assorbire le basi, poi con esse costruire piano piano gli artefatti, per arrivare allo scopo (mi sarei accontentato anche di molto meno di arrivare alla AI…).
Nel mio percorso molte volte ho letto che la programmazione funzionale ed i modelli che ne sono scaturiti sono proiezioni della AI nelle funzionalità odierne e che tutto e nato molti anni fa con i linguaggi Haskell / Erlang / Lisp , con il modello degli attori, con l’applicazione dell’algebra astratta alla programmazione.
Ma solo oggi possiamo veramente applicarla a tutti i contesti grazie alla tecnologia odierna, potenza computazionale, reti mondiali ad alta velocità, storage infiniti, cloud computing, computer quantici ecc…
Nel 1994 inizia il mio percorso lavorativo in quel fantastico, e pieno di opportunità, mondo dell’informatica: ebbi molta fortuna nel mio ingresso perchè vinsi un concorso tra più di 500 persone per partecipare ad un corso ELEA di durata annuale il cui titolo era “Programmatore Client Server”.
A quel tempo infatti era in corso un cambiamento di paradigma dal Mainframe al Personal Computer, dal Cobol alla programmazione Windows, dai file VSAM ai DB relazionali.
Molto era lo sconcerto nelle aziende informatiche che spesso non erano pronte al passaggio a tale architettura per mancanza di conoscenza e per mancanza di persone che avessero competenze diametralmente opposte a quelle dei programmatori COBOL, che vedevano come fumo negli occhi la programmazione Event Driven, la logica relazionale e la programmazione non procedurale.
Pochi anni dopo il paradigma si evolse sotto la spinta della rete Internet, che era stata sdoganata da rete militare a rete commerciale e che prese il sopravvento grazie alla spinta di aziende come Netscape e grazie a questa onda due persone decisero di creare un azienda di nome ThinWEB, che legava il precedente paradigma con il nuovo che avanzava a grandi passi.
Era l’inizio della programmazione WEB e della creazione di architetture molto complesse per l’epoca: Web Server, Mail Server, Firewall, Proxy Server, Load Balancer, Security Server ecc…
Ogni onda informatica ha avuto il suo padre tecnologico, se per la architettura mainframe vide in IBM il suo mentore , l’architettura Client/Server ha visto l’ingresso di Microsoft come capofila tecnologico, mentre nell’architettura WEB fu invece SUN a prenderne il timone.
Negli anni successivi ci fu l’introduzione di evoluzioni del modello WEB che vide da un parte SUN fare la parte del leone con JAVA (sviluppato nel 1994, ma solo adesso grande protagonista) ed in affanno Microsoft con la tecnologia .NET, ma con grandi mezzi che gli permisero di recuperare almeno un posto di minoranza al tavolo dei protagonisti.
Negli anni successivi si ebbe un consolidamento della tecnologia WEB con la maturazione dello stack SUN J2EE e con l’avvento sulla scena dei primi Application Server. Un signore di nome Rod Johnson nel 2002 con il suo libro Expert One-on-One J2EE Design and Development diede il via al framework Spring che grazie all’introduzione del modello della Dependency Injection si prese una fetta importante della produzione di software WEB in Java, creando un alternativa agli EJB e allo sviluppo JSF con un approccio Stateless e forte produttività da una parte mentre dall’altra Gavin King con Hibernate e il framework SEAM che spingeva per un approccio Statefull con la corazzata SUN come alleato.
Spring (oggi di Google) insieme a Google entrata sulla scena con una forza inaudita, si divisero la fetta maggiore della programmazione WEB, lasciando a Microsoft, Ruby on Rails, Python con Django una fetta importante ,ma minoritaria.
Negli anni successivi fu la volta di Javascript lato client che si ritagliò una grande parte di interesse per la programmazione in quanto permetteva una programmazione reattiva lato UI, che portò all’introduzione di modelli come il RestFul (Api Gateway) che permisero una maggior resa della UI e un disaccoppiamento importante tra la programmazione Front End e la programmazione Back End, creando i presupposti per il lento declino della architettura J2EE, che vide sconfitta una parte importante del proprio stack come le JSF.
Una parte fondamentale in questo percorso fu ricoperta da Google, che con GWT creò un vero e proprio spartiacque che aprì le porte a framework come Angular e ReactJS.
Ma veniamo alla parte interessante lasciando stare la nostalgia per i tempi passati. E’ proprio nei primi anni del secondo decennio del nuovo millennio che cominciarono i primi vagiti del nuovo cambiamento di paradigma, che tutt’oggi è in corso,
Il professore di Losanna, Martin Odersky, cominciò a divulgare il linguaggio ibrido funzionale Scala (creato nel 2004) agendo da evangelista per spiegare come la programmazione funzionale, che risaliva agli anni 70 con linguaggi come Lisp, Erlang e Haskell, sarebbe stata il nuovo Eldorado per la programmazione del nuovo paradigma che si stava affacciando e che avrebbe svolto la parte del leone in un ambiente cloud che tecnologicamente stava maturando e che avrebbe permesso il cosidetto Internet of Things.
Partecipai al primo corso ufficiale Scala nel 2012 su Coursera e saggiai con mano le potenzialità di un simile approccio, ma ancora non mi era chiaro come potesse essere utilizzato al posto delle tecnologie esistenti.
Lo capiì più tardi seguendo i seminari e i primi passi del manifesto della programmazione reattiva, vero caposaldo della programmazione e dei sistemi reattivi.
Ma se i linguaggi funzionali erano già presenti (SQL, Javascript, Lisp, Haskell, Clojure, ML, OCAML) perchè Scala?
La vera forza di Scala è rilasciare bytecode Java, potendo così girare su JVM e condivide le librerie Java e attingere ad una comunità infinita e consolidata.
Ogni era è segnata da un mentore e dai suoi discepoli, in questo caso il faro si chiama LightBend ed i discepoli sono molti, il già -più volte — citato Martin Odersky, ma soprattutto Jonas Boner, che riscrisse per Scala e Java il paradigma degli attori , scritto in Erlang negli anni 70 per le telco dell’epoca, ma assolutamente adatto ad un sistema cloud odierno, permettendo rispetto agli anni 70 maggiori potenze di calcolo e quindi calcolo sequenziale e parallelo distribuito (distribuito è la parola fondamentale).
Grazie al binomio Scala e Akka (framework che si basa sul paradigma degli attori), si riesce ad avere una visione più chiara ed esaustiva del nuovo modello che è oggi sotto i riflettori: il modello dei microservizi.
Tale modello è necessario per un ulteriore disaccoppiamento lato back end in un sistema distribuito effettivo che permette di aderire perfettamente alla legge di Amdhal e di Gunter, in una parola scalabilità ed utilizzo delle risorse in ambiente distribuito.
Ora finito il pippone passiamo a quali passi devono essere seguiti per cambiare pelle all’azienda e avere un ruolo in questa nuova evoluzione tecnologica che sarà prevalente nei prossimi anni.
L’importante è che l’azienda con i suoi stakeholders principali: soci, dirigenti, quadri intermedi, project manager e sviluppatori, comprendano pienamente il nuovo paradigma e siano i primi a crederci.
Si parte dal manifesto della programmazione reattiva e a tutti i white paper direzionali che si trovano sul sito della LightBend e che forniscono le basi teoriche e le indicazioni fondamental procedendo poi alla formazione del personale tramite i servizi oggi presenti e disponibili: Screencast, YouTube, Webinar, corsi online, corsi a pagamento (la Lightbend ha dei corsi costosi ma sono il top, e rendono più lieve e rapida la curva di apprendimento ).
Il materiale che elenco è la mia esperienza in corsi e formazione effettuata, ad eccezione dei corsi Coursera che sono importanti, ma ad oggi è possibile anche utilizzare altre strade.
Per i soci:
https://www.youtube.com/watch?v=lTL4TflgEWc
Fondamentale: https://www.reactivemanifesto.org/ https://www.lightbend.com/ http://jonasboner.com/
Per capi progetto e sviluppatori:
Libri Scala:
Il migliore: Functional Programming in Scala
La bibbia da avere sempre: Programming in Scala
Corsi Udemy:
Scala: https://www.udemy.com/user/daniel-ciocirlan/
Importante seguire il corso primer ed avanzato di scala che serve come base per il resto dei corsi.
Corsi avanzati su scala:
https://www.udemy.com/implementing-graph-algorithms-using-scala/ https://www.udemy.com/sorting-and-searching-algorithms-in-scala/
YouTube:
Video di Jonas Boner
Must see (Odersky aggiunge sempre qualcosa…anche vederlo 6 anni dopo…)
Corsi Akka:
Daniel Ciocirian: corso sugli attori Akka I e II sono importanti per avere una visione su come si sviluppano i microservizi
Il corso su Akka Stream è un Must See, fondamentale per capire gli Stream in profondità.
Su www.akka.io c’è tutto quello che serve.
Stream:
FS2 il top, con questi video si ha una visione degli streams ottimale.
Kafka:
Ottimi I corsi anche su gRPC e AWS.
Il corso su Kafka è in java , ma si possono utilizzare gli stream kafka in scala di alpakka.
Spark:
Spark va visto come kubernetes per ultimo dopo avere consolidato i corsi sugli streams.
