Questo mese abbiamo fatto colazione con…
Massimiliano Pianciamore, Head of Distributed Architectures Competence Center di CEFRIEL

In vista del Technology Infrastructure Summit 2018, che si terrà il prossimo 20 settembre, The Innovation Group ha intervistato Massimiliano Pianciamore, Head of Distributed Architectures Competence Center di CEFRIEL, che ha parlato dei nuovi modelli di sviluppo dell’infrastruttura ICT e quali saranno le opportunità per le aziende.

Sempre più oggi si parla di microservizi, tecnologia serverless, infrastructure-as-a-code ed architetture basate su API: perché le aziende sappiano cogliere al meglio le opportunità legate a questi nuovi strumenti sarà necessario per le stesse essere in grado di “adattarsi” e fronteggiare al meglio le sfide del business; quali sono, dunque, i principali trend che stanno ridefinendo le architetture IT delle aziende?

Nell’ambito della progettazione di architetture software un trend particolarmente rilevante è quello individuato dalle API-driven Architectures e, all’interno di questo, dalle architetture a Microservizi. I principali vantaggi di un approccio API-driven nella progettazione del software sono una riduzione dei tempi di sviluppo complessivi delle applicazioni, una migliore architettura interna nella quale sono esplicitati i ‘contratti’ fra i diversi componenti in termini di API esposte e fruite e una migliore documentazione del software realizzato. Una progettazione API-driven è, inoltre, un fattore abilitante per la realizzazione di architetture a Microservizi che possono essere viste come collezioni di componenti indipendenti gli uni dagli altri in esecuzione in container che interagiscono tra loro esclusivamente tramite l’invocazione di API.

Come deve essere una architettura tecnologica agile e flessibile e quali componenti funzionali e tecnologici deve prevedere? Possiamo chiarire e posizionare quella che viene chiamata Infrastructure-as-a-code, virtualizzata, containerizzata, cloud ready e a micro-servizi?

Nella progettazione, realizzazione e gestione operativa di una architettura API-driven diventa indispensabile l’adozione e l’utilizzo di una piattaforma di API Management, che consente di gestire in modo completo e articolato i vari aspetti del ciclo di vita dei componenti dell’architettura quali ad esempio lo sviluppo e il deploy delle singole API, l’orchestrazione di API per la realizzazione di funzionalità complesse e articolate, la gestione della sicurezza, la pubblicazione di una API (anche in versioni multiple), la gestione di tutti gli aspetti legati al deployment, operation e monitoraggio delle API pubblicate.

Infrastructure-as-code è la pratica DevOps con la quale si riconduce la descrizione e la configurazione dell’infrastruttura tecnologica/fisica (container, macchine virtuali, etc.) sulla quale devono essere dispiegati ed eseguiti i componenti dell’architettura alla scrittura di script e all’utilizzo di strumenti di tool automation mutuati dallo sviluppo software, quali ad esempio strumenti per il controllo delle versioni, librerie per il test automatizzato, strumenti di deployment e orchestrazione dei componenti dell’infrastruttura. L’utilizzo di Infrastructure-as-code consente di documentare in modo rigoroso l’infrastruttura stessa, di renderla facilmente riproducibile e in generale di gestire tutto il ciclo di vita dei singoli componenti infrastrutturali (creazione, test, operatività, distruzione) in modo sostanzialmente automatizzato utilizzando codice eseguibile scritto in un linguaggio ad alto livello.

Come deve essere lo stack tecnologico di  piattaforme  digitali che abilitano servizi ed ecosistemi ?

 Come anticipato precedentemente, un elemento essenziale ed abilitante per la gestione operativa di una architettura API-driven è una infrastruttura di API Management. Altri componenti abilitanti per una architettura a Microservizi sono i container, all’interno dei quali vengono dispiegati i singoli microservizi. Si sta inoltre diffondendo l’utilizzo di piattaforme per l’orchestrazione e gestione di container quali ad esempio Kubernetes, che rappresenta lo standard de facto in questo ambito. Kubernetes, che può essere visto come livello di astrazione che sta al di sopra dei livelli dei microservizi e dei container, permette di eliminare molti dei processi manuali coinvolti nel deployment e nella gestione della scalabilità di applicazioni containerizzate e di gestire in maniera semplice ed efficiente cluster di host sui quali vengono eseguiti i singoli container. Nello stack tecnologico di riferimento non possono poi mancare strumenti a supporto del processo di Continuous Integration e Continuos Delivery per orchestrare e gestire in modo automatizzato il processo di rilascio e test dei componenti software dell’architettura.

Come devono cambiare le modalità di gestione e i processi IT ? Dal provisioning e maintenance allo sviluppo  software ?

 Nelle architetture API-driven e a microservizi le API sono il primo ‘prodotto’ che viene creato durante il processo di sviluppo e intorno al quale il processo di sviluppo viene (ri)definito. In un processo di sviluppo API-driven  è necessario definire criteri per supportare lo sviluppo di API di qualità attraverso la definizione di linee guida di riferimento che indirizzano verso l’utilizzo di tecniche consolidate di API design, all’utilizzo di standard di riferimento per gestire la sicurezza negli accessi alle API, etc. Nel processo di sviluppo e di pubblicazione delle API e dei microservizi sarà inoltre necessario prevedere attività esplicite di validazione delle API realizzate per verificarne la qualità rispetto alle indicazioni presenti nelle linee guida di riferimento. L’adozione di architetture API-driven e a microservizi pone inoltre i team di sviluppo al centro attribuendo loro la responsabilità di sviluppare, testare e rilasciare i singoli servizi e le loro evoluzioni in modo sostanzialmente indipendente gli uni dagli altri. Il confine sempre più sfumato tra il codice applicativo e quello per la configurazione delle infrastrutture comporta un confine altrettanto sfumato tra i compiti di sviluppatori e responsabili delle operazioni.