Who's Who
Tech InDepth
Oltre alle quattro forze che stanno alla base della rivoluzione digitale, cioè cloud, mobile, social network e big data (che tra poco non si potrà più considerare a parte perché, dice Gartner, “tutti i dati saranno big data”) ve n’è una quinta. Altrettanto rivoluzionaria e forse ancor più pervasiva, ma trasparente a chi guarda alla digitalizzazione nel lavoro e nella società. È la ‘rivoluzione silenziosa’ dello sviluppo software, che vede il passaggio da un modello rivolto allo sviluppo e delivery di grandi applicazioni a uno che consiste nel creare micro-servizi, cioè servizi software semplici e di piccole dimensioni, per assemblarli tra loro e/o con altri micro-servizi preesistenti per comporre, questo è il punto, un insieme di più alto valore per il business.
Il concetto di creare componendo non è nuovo. Linus Pauling (Nobel per la chimica 1954 e per la pace 1962) disse un giorno: “Il modo migliore per avere una buona idea è avere molte idee”. E questa è oggi la regola, dalla ricerca pura alla produzione manifatturiera, dove l’esempio più evidente è dato proprio dall’hardware ICT. Nello sviluppo applicativo il modello è supportato da mezzi sia tecnologici (software open source, API, piattaforme di servizi) sia di metodo (come il DevOps). Questi strumenti, assieme alla ricca offerta di API e micro-servizi ‘preconfezionati’, danno all’IT aziendale il modo di fornire in tempi rapidi i servizi richiesti dal business con applicazioni che in più offrono la flessibilità data dal poter essere scomposte e ricomposte in risposta a nuovi bisogni. E poiché le applicazioni sono, in ultima analisi, idee di business tradotte in algoritmi e codice, è chiaro come dal ritmo del loro sviluppo dipenda il passo dell’innovazione del business e dell’impresa.
Confronto tra sviluppo su progetto ad hoc e sviluppo per composizione di servizi Fonte: Forrester Research
Il problema che porta lo sviluppo e il delivery applicativo a un punto di svolta è che gli strumenti di cui s’è detto non sono ancora molto diffusi né sono usati in una visione sinergica. In molte imprese le applicazioni che reggono il business sono ancora disegnate e sviluppate ad hoc o sono così customizzate da essere di fatto proprietarie e legacy. Concepite per un mondo di processi stand-alone (acquisti, vendite, fatture…) non sono più adatte a gestire i flussi interdipendenti che sono al cuore dell’impresa digitale, ai quali occorre invece un tessuto fatto da servizi “loosely-coupled”, cioè connessi ma facilmente sostituibili o modificabili per inseguire nuovi bisogni o mettere in atto nuove idee. In breve: lo sviluppo deve cambiare. E il modello compositivo sembra il migliore, se non l’unico possibile.
Perché i software container
Lo sviluppo di applicazioni composite ne semplifica il rilascio, che secondo i princìpi del DevOps avviene man mano che i servizi sono connessi, e ne riduce i rischi perchè il codice nuovo e da testare è ridotto al minimo. In compenso, però, l’esecuzione è molto più complicata. Essendo l’accoppiamento “loose”, le interdipendenze tra micro-servizi che provengono da diverse fonti e operano in ambienti diversi vanno gestite nel runtime, che diventa quindi molto complesso. Inoltre, ogni versione di un’applicazione composita è legata a specifiche versioni dei servizi usati. Stante il fatto che tali servizi possono essere migliaia, gestirne il versioning è un compito che supera le capacità umane. Occorre un approccio diverso.
Una tecnologia che promette di facilitare l’impiego delle applicazioni composite superando alcune delle complessità del runtime è quella dei cosiddetti “container”, che Forrester mette tra quelle il cui sviluppo va seguito con grande attenzione dai responsabili I&O (infrastruttura e operazioni).
Un Software Container, o Compute Container (nei testi si trovano entrambi i termini, noi qui useremo il primo, abbreviato in Swc) è un tipo di virtualizzazione che opera a livello del sistema operativo incapsulando un intero ambiente runtime, cioè l’applicazione, le binary libraries che traducono il sorgente in linguaggio macchina e i configuration files, in un pacchetto che il kernel Os considera in modo isolato da ogni altro processo.
Una singola macchina con un singolo Os può quindi servire più istanze per utente facendo girare più applicazioni contemporaneamente.
Si tratta di un livello di astrazione più elevato rispetto a quello sul quale sono concepite le virtual machine (VM), che astrae l’hardware, e questo rende gli Swc concettualmente molto diversi dalle macchine virtuali. Dalle differenze tra i due modelli derivano modalità d’implementazione e funzionamento che oggi rendono l’adozione degli Swc un passo vantaggioso sia per l’IT sia per il business delle imprese utenti. Di queste cose parleremo negli articoli a seguire, ma non possiamo non anticipare il vantaggio fondamentale dei container, dal quale dipendono molte delle sue peculiarità: mentre una VM ha un suo sistema operativo (OS guest), da cui il bisogno di un supervisor che gestisca i vari OS guest nei riguardi dell’OS host e dell’hardware, un SWC ne è privo, riferendosi a un OS che condivide con tutti gli altri. Ciò porta a conseguenze che si possono sintetizzare nel risparmio delle risorse hardware; nella portabilità del container da una piattaforma all’altra (preziosa in un ambiente cloud ibrido) e soprattutto nella grande semplicità e rapidità del deployment dell’SWC e, quindi, dell’applicazione contenuta. È questo ciò che secondo gli analisti farà dei software container lo strumento più adatto ad affrontare le sfide poste ai responsabili I&O dalla rivoluzione digitale.
Ecco il primo di una serie di articoli dedicati alla tematica del Software Container. Leggi anche l’articolo: Software Container: come si possono gestire e quali sono i vantaggi per l’utente
