Le tecnologie


Introduzione



Negli oltre 20 anni di attività, senza contare i precedenti 10 anni dei suoi fondatori come ricercatori nel laboratorio di Intelligenza Artificiale del Gruppo ENI Spa, Sinapsi ha ovviamente avuto modo di cimentarsi con tantissime tecnologie e metodologie di gestione del ciclo di vita del software.

GNU/Linux e Java


Le basi di partenza del 1996 sono state il sistema operativo GNU/Linux e il linguaggio di programmazione Java. Queste due scelte, che molti giudicarono scellerate, perché MS Windows NT la faceva da padrone e il mercato a stento sapeva dell’esistenza di GNU/Linux e del linguaggio di programmazione Java, si sono rilevate a posteriori molto fortunate. Di seguito lo stralcio dell’intervista del 2011 di Flavia Marzano a Mimmo Cosenza su Wired.


Ti occupi di software libero da “sempre”, giusto? Che cosa ti ha spinto a farlo?

… nel 1996 fondai Sinapsi insieme ad alcuni colleghi. Comprammo un paio di PC molto economici con MS Windows preinstallato, ma non sapevamo dove mettere le mani nel loro ambiente di sviluppo e i sistemi UNIX, utilizzati dai nostri primissimi clienti, costavano un botto. Uno dei miei soci mi parlò di Linux. Detto e fatto. Con una macchina x86 molto economica e Linux fummo subito in grado di sviluppare per sistemi di destinazione UNIX molto costosi…

Questo spiega esplicitamente la scelta di GNU/Linux, ma solo implicitamente quella di Java. Sì, perché Java rappresentava la prima vera e propria soluzione di virtual machine per lo sviluppo di applicazioni enterprise, il cui motto era: Write Once, Run Everywhere. Si poteva sviluppare in Java su sistema operativo GNU/Linux e rilasciare le applicazioni in produzione su sistema operativo MS Windows NT, alla faccia dei nostri detrattori di allora.

L’invisibile



Fin dalla sua fondazione, Sinapsi non si è mai posizionata nel mercato dello sviluppo di siti web. Tutt’altro. Quando ci chiedevano di cosa ci occupassimo, rispondevamo così:

Facciamo tutto quello che non si vede

L’immagine di sopra del sito di Sinapsi dei primi anni 2000, registrata su Archive Org, con un angolo della coperta che svela il codice sorgente della classe Socket di Java, era lì a enfatizzarlo.

Architetture SOA



Se si parla di software invisibile, è inevitabile parlare di middleware. Quando nel 2007 La Feltrinelli ci commissionò la realizzazione della loro offerta di e-commerce, il mock-up venne realizzato da Frog Desing. Noi scegliemmo Magnolia CMS, come Content Managament System, e Mule ESB come soluzione di integrazione via Enterprise Service Bus delle numerose applicazioni de La Feltrinelli per la gestione degli ordini, del magazzino e delle spedizioni.

Da allora, le architetture SOA (Service Oriented Architecture) sono diventate il nostro pane quotidiano, ma da qualche anno abbiamo cominciato a spingerci più avanti, tornando ancora una volta indietro alle nostre origini.

Clojure è il nuovo LISP



Nella intervista su Wired già citata, Mimmo Cosenza diceva:

… Nella seconda metà degli anni ‘80 entrai nel centro di ricerca di AI dell’ENI (già Agip Spa) e avevo una meravigliosa LISP machine tutta per me …

L’amore per l’arte della programmazione in LISP non abbandonò mai Sinapsi, si trattò solo di una sospenzione, durata due decenni, che si interruppe quando, nel 2011, Sinapsi scoprì l’esistenza di Clojure. La maggior parte dei linguaggi di programmazione emergenti apparivano, con la straordinaria eccezione di Golang, poco interessanti. E intanto, mentre JavaScript cominciava a imporsi con NodeJS anche sul back-end, Java era diventato ancora più verboso e ingessato.

Dove c’era agilità, come in JavaScript, c’era schizofrenia semantica. Dove c’erano rigore e robustezza, come in Java, mancava agilità.

La scoperta di Clojure, arrivata ancora una volta da un lontano e glorioso passato, fu come una ventata di aria fresca. Ci si ricordò di quando, tenendo i corsi sui Design Patterns, si diceva spesso ai partecipanti;

La migliore linea di codice è quella che non si scrive

Questa affermazione, piuttosto criptica per i non addetti ai lavori, oggi appare paradossale se applicata all’Object-Oriented a ai Design Patterns.

Un linguaggio che ha bisogno dei Design Patterns per risolvere problemi che lui stesso produce, assomiglia al modello geocentrico dell’universo che ha bisogno degli epicicli tolemaici per calcolare i movimenti dei pianeti.

Al contrario, un linguaggio di programmazione che favorisca l’astrazione, consentirà di modellare il mondo con un numero limitato di leggi generali che si compongono tra loro, come le leggi della fisica. Ed è proprio ai laurendi di Matematica e Fisica, abituati più di altri all’astrazione e alla modellazione del mondo, che Sinapsi propose nel 2012 un seminario di qualche mese di Programmazione Funzionale in Clojure. Non a caso, il tasso di Matematici e Fisici, anche con PhD, in Sinapsi è molto alto. Da allora, che si tratti di JVM (Java Virtual Machine) sul back-end o di JSVM (JavaScript Virtual Machine), tanto sul back-end quanto nel browser e persino nell App iOS e Android, Sinapsi propone sempre Clojure e ClojureScript come prima scelta.

Il visibile



Quella di sopra è una delle slide che Sinapsi mostra con maggiore orgoglio ai propri clienti, anche perché ci ha consentito, proprio a noi che eravamo invisibili, di renderci visibili.

A sinistra la varietà di applicazioni:

A destra i server, in tutti i possibili dispiegamenti, indipendentemente dal sistema operativo:

In basso, quando necessario, librerie realizzate con linguaggi di basso livello (e.g. C/C++). In mezzo le virtual machine di Java o di JavaScript.

E in alto, a comandare il tutto, Clojure e ClojureScript, quest’ultimo utilizzando alcune delle più rinomate e performanti tecnologie client-side:

Fast Track



Ogni quanto tempo, mediamente, le aziende portano in produzione le correzioni e le evoluzioni delle applicazioni che progressivamente i programmatori, interni o esterni che siano, sviluppano? E a quanti litigi tra la divisione “sviluppo” e la divisione “gestione operativa” si assiste quando, portando i nuovi sviluppi in produzione, c’è qualche cosa che non ha funzionato come ci si aspettava? Quanto tempo aspetta la divisione di marketing per vedere in produzione le nuove applicazioni da offrire ai propri clienti per poter continuare a stare in un mercato globale sempre più competitivo?

A partire dall’inizio del 2017, Sinapsi ha dato vita a un progetto interno, denominato Fast Track, con lo scopo di ridurre significativamente i tempi di messa in produzione tanto delle nuove applicazioni, quanto delle correzioni e delle evoluzioni delle applicazioni già dispiegate in produzione.

Si tratta di un progetto di automazione progressiva del ciclo di vita del software, a partire dall’acquisizione delle specifiche funzionali fino alla gestione operativa delle applicazioni.

L’obiettivo finale del progetto è arrivare al punto in cui il tempo che intercorre tra l’implementazione della nuova feature di un’applicazione (o la correzione di un malfunzionamento) e il suo dispiegamento in produzione sia vicino ai secondi, o ai minuti, non certo agli attuali giorni, se non settimane. Il tutto passando automaticamente attraverso l’esecuzione delle varie tipologie di test, UAT (User Acceptance Test) compresi.

Lavastoviglie



La metafora che usiamo internamente per caratterizzare il progetto Fast Track è quella della lavastoviglie:

Finché si è in due a mangiare, ci si può anche lavare i piatti a mano senza problemi, ma appena si è un poco di più, tutti vorrebbero avere una lavastoviglie.

Nessuna scusa



Naturalmente siamo consapevoli che una delle più diffuse risposte dei programmatori ai gestori delle operations, quando qualcosa non funziona in produzione sia puntualmente:

Sul mio computer funziona

Docker risolve questo problema, ma, inevitabilmente, ne introduce di nuovi. La sfida del 2018 sarà di estendere la nostra “lavastoviglie”, che nel suo complesso va sotto il nome di Continuous Delivery, alle architetture a micro-servizi basate su Docker e che dovrebbero consentire, una volta risolte alcune delle problematiche più rilevanti di queste architetture, causate in gran parte dall’estrema dinamicità delle stesse, di poter arrivare a rilasciare nuove release in produzione più volte al giorno, potenzialmente a ogni commit.

Ma la sfida più grande sarà per i nostri clienti. Se davvero vogliono adottare architetture scalabili e dinamiche, dovranno inevitabilmente ripensare la propria organizzazione, che a sua volta dovrà essere progettata per essere scalabile, perché il tempo e il mercato non aspettano.