Questo sito utilizza cookie per raccogliere informazioni sull'utilizzo. Cliccando su questo banner o navigando il sito, acconsenti all'uso dei cookie. Leggi la nostra cookie policy.OK

Sviluppare e gestire le applicazioni composite

pittogramma Zerouno

Tech InDepth

Sviluppare e gestire le applicazioni composite

02 Mag 2017

di Giampiero Carli Ballola

Il passaggio dalle applicazioni monolitiche a quelle composte da microservizi porta una difficile sfida ai team di sviluppo e delivery. Cosa sono i software container e come la tecnologia a essi relativa risponde
a questa problematica? In questo articolo, e nei prossimi sullo stesso tema, si spiega come livelli di astrazione degli oggetti e di automazione dei processi possano ridurre la complessità delle operazioni e permettere all’It di fornire servizi applicativi adeguati alle esigenze del business digitale

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.


Sviluppo Software: 7 punti per cambiare

L’adozione del DevOps, delle applicazioni composite e dei microservizi non è ancora molto diffusa. Ma va crescendo e per questo Forrester indica sette cose da fare per essere preparati alla rivoluzione che tra uno-due anni cambierà il lavoro dei team AD&D (application development and delivery).

  1. Le piattaforme di sviluppo sono sempre più “infrastructure agnostic”. Il focus dell’AD&D si sposterà quindi sempre più dalla codifica allo sviluppo degli algoritmi. Per far ciò occorre conoscere il business o relazionarsi con chi lo conosce.
  2. Il primo obiettivo diventa la customer experience dell’utente mobile. Ciò significa che si dovrà andare su nuovi framework e linguaggi in grado di coprire sia il mobile che il web.
  3. Non si svilupperà ciò che si potrà comprare o fruire in SaaS. Bisognerà quindi ridefinire i criteri di separazione tra build e buy.
  4. La gran parte delle applicazioni usa software open source (OsS), ma i team AD&D non hanno ancora ben chiare le loro qualità e vulnerabilità. Si dovrà imparare a governare l’OsS come la supply chain nel lean manufacturing.
  5. L’adozione dei metodi Agile e DevOps implica che sviluppatori e architetti SW dovranno lavorare insieme e darsi una cultura comune rivolta ad applicazioni capaci di profittare al meglio di queste procedure.
  6. Trovare gente esperta è sempre più difficile. Bisogna darsi subito da fare combinando formazione interna, stage per studenti, consulenze e quant’altro utile a creare una pipeline di risorse umane.
  7. Le piattaforme basate su JavaScript (come Node.js) crescono. Servono allora quegli sviluppatori che Forrester definisce “JS nativi”, che pensano cioè in termini di ambienti event-driven.

 

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

Giampiero Carli Ballola
Giornalista

Giampiero Carli-Ballola, nato nel 1942 e giornalista specialista in tecnologia, collabora con ZeroUno dal 1988. Segue i processi di digitalizzazione del business con particolare attenzione ai data center e alle architetture infrastrutturali, alle applicazioni big data e analitiche, alle soluzioni per l’automazione delle industrie e ai sistemi di sicurezza.

Articolo 1 di 5