È cambiata la metodologia di sviluppo software e di applicazioni perché è radicalmente cambiato il tempo richiesto dal business per poter disporre di applicazioni: oggi si chiedono tempi strettissimi di sviluppo per abilitare rapidamente la disponibilità di nuovi prodotti e servizi. Non solo, alle nuove app si chiede di poter comunicare nativamente tra loro (attraverso Api-Application programming interface). Ma che cos’è la metodologia DevOps e l’Agile management?
“L’era degli ‘intricati’ design è finita; è arrivata l’epoca dell’assemblamento flessibile dove un rapido sviluppo di nuove applicazioni viene garantito attraverso la ‘composizione’ di servizi già disponibili, scrivendo nuovo codice solo quando è inevitabile e assolutamente necessario”, spiega Forrester. Attraverso l’approccio DevOps, l’applicazione evolve passo per passo: il team di sviluppo lavora in modo sinergico, mentre qualcuno riscrive i servizi che non funzionano, altri affinano quelli che risultano ottimali per l’applicazione in fase di sviluppo. È evidente che un simile modo di lavorare, perché risulti realmente efficace e non generi complessità organizzative con inevitabili ripercussioni sulla qualità dell’applicazione o addirittura sui tempi di rilascio, richiede alla base una definizione di approcci e metodologie rigorosi, controllati e controllabili (come DevOps e Agile), nuove competenze e specifiche tecnologie a supporto.
La differenza tra Big Design e metodologia DevOps e Agile
Il paradigma legato allo sviluppo applicativo incentrato sul ‘Big Design’ (scrittura di codice nativo per realizzare monoliti applicativi) rappresenta oggi, rispetto alle metodologie di sviluppo software Devops e Agile, un approccio fallimentare per svariate ragioni:
- generano applicazioni complesse con interfacce ‘fragili’ e non flessibili che rendono difficilmente integrabili e interoperabili le soluzioni con altri servizi applicativi, situazione non più accettabile nell’attuale scenario competitivo globale in cui si muovono le aziende;
- manutenzione ed evoluzione risultano costose e complesse, per le stesse ragioni legate alla difficoltà di integrazione/interoperabilità cui si aggiungono le criticità legate alla disponibilità di competenze;
- le tecnologie ‘monolingua’ sono fuori tempo in un mondo poliglotta: l’approccio Big Design ha generalmente portato allo sviluppo di applicazioni basate su linguaggi proprietari; le moderne interfacce REST-based hanno permesso ad applicazioni scritte in differenti linguaggi di interoperare ma inserire layer applicativi di questo tipo risulta comunque molto complesso e richiede tempo (anni, secondo Forrester);
- l’interdipendenza è divenuta la regola, non l’eccezione: il parco applicativo aziendale, in linea di massima, oggi è rappresentato da svariati strati applicativi con soluzioni eterogenee l’una strettamente dipendente dall’altra si sono così formate intricate reti di applicazioni che rendono complessi gli interventi evolutivi a causa delle eccessive interdipendenze tra un servizio e l’altro (spesso senza alcuna chiarezza e visibilità sulle reali interconnessioni con ripercussioni ‘drammatiche’ anche sul testing applicativo);
- l’attenzione agli aspetti infrastrutturali dovrebbe essere continua, non ‘one-shot’: in passato le architetture sottostanti i servizi applicativi venivano ‘tarate’ per supportarne semplicemente la scalabilità; oggi le applicazioni devono evolvere rapidamente e con esse anche le infrastrutture a supporto.
Che cos’è DevOps? Perché Development e Operations devono collaborare?
Development da un lato e Operations dall’altro, il DevOps è una metodologia di sviluppo del software che sfrutta le nuove logiche della condivisione e della collaboration ma anche di un crowdsourcing più verticale. Ecco cosa significa DevOps ed è possibile portando nuovi livelli di integrazione tra gli sviluppatori e gli addetti alle operations per accelerare i tempi di progettazione, testing e di rilascio delle soluzioni applicative aziendali sia in ambienti tradizionali che in ambienti cloud. Il tutto assicurando la qualità e la sicurezza del software sviluppato.
La complessità è infatti spesso il riflesso della crescita incontrastata delle infrastrutture It; un debito non risolto nemmeno con l’introduzione di tecnologie quali Soa, virtualizzazione, cloud computing che dovrebbero, al contrario, garantire proprio la semplificazione dell’It. La complessità, dunque, regna sovrana all’interno dei data center delle aziende: da un sondaggio condotto da Gartner, le infrastrutture It esistenti (comprese le architetture applicative) risultano essere ‘very complex’ nel 54% dei casi.
Analizzando un po’ più in dettaglio le ‘cause’ di tale complessità, Gartner evidenzia come le problematiche maggiori siano da rilevare nell’ambito dei processi It, da un lato, e nel proliferare di tool tecnologici, dall’altro. Situazioni che rendono difficoltoso sia il rilascio sia il mantenimento di servizi It efficienti (ed efficaci sul piano del business).
E dato che uno dei servizi It più impattante sul piano del business è quello applicativo, Gartner ha voluto indagare per capire meglio quali possano essere le ‘disfunzioni’ all’interno della famiglia It che si riflettono poi sull’azienda. Una delle aree maggiormente critiche risulta essere la ‘relazione’ tra l’application development e le It operation. Ben il 47% degli intervistati ha dichiarato che i rapporti tra questi differenti team è del tutto ‘un-collaborative’. Le lamentele più comuni delle operation derivano dal fatto che spesso queste vengono ‘lasciate fuori’ dalle decisioni sia quelle inerenti le architetture It sia quelle di business, con il risultato di un minor controllo sui service level (compresi i costi).
I principali ‘conflitti’, causa della ‘disfunzionale’ relazione tra development e operation, derivano, infatti, dalle persone, poco abituate a un approccio collaborativo anche, e soprattutto, a causa delle strutture ‘a silos’ dei data center. Le problematiche maggiori sono quindi da ricondurre a processi non comuni (per il 43% degli intervistati) e alla mancanza di collaborazione (41%). Interessante vedere che la mancanza di condivisione delle metriche è ritenuta una ‘causa di conflitto’ solo dal 3% delle persone: “Ma questo è il risultato dell’ignoranza – scrive Gartner – che amplifica il problema della ‘chiusura’ e della mancanza di collaborazione”.
Al contrario, il significato del DevOps sta proprio nel sapere andare oltre a questa lacuna culturale.
I cardini della metodologia DevOps: i 4 consigli di Gartner
L’evoluzione delle tecnologie ha generato un nuovo ‘stile’ di sviluppo che ha decretato la fine dell’Application Design a favore del più dinamico modello Application Composition. Una volta definito, più sopra, in linea generale, cos’è DevOps, approfondiamo ora questo il senso di questo nuovo paradigma che mira a ridurre le interdipendenze applicative attraverso un accoppiamento ‘lasco’ ossia sfruttando architetture service oriented (Soa) e le più recenti Rest Api per sviluppare servizi applicativi indipendenti riutilizzabili in contesti non pianificati (cioè come base anche per applicazioni differenti tra loro). Paradigma che trova oggi negli approcci Agile e DevOps una risposta anche sul piano metodologico, nonché dal punto di vista delle scelte tecnologiche e sul fronte delle competenze.
Gartner parla di ‘filosofia’ DevOps più che di metodologia, ma non manca di proporre alcune utili linee guida per indirizzare un percorso adeguato:
- Capire se l’approccio DevOps potrà migliorare l’It service management analizzando le performance dei processi esistenti ed identificando le potenziali aree di miglioramento in termini di agilità. Questo comporta fin da subito una stretta collaborazione tra development e operation che devono analizzare insieme, seppur dalla propria prospettiva, le performance.
- Identificare processi specifici, quelli dove risulta più immediata la semplificazione infrastrutturale e dove l’agilità è più facilmente raggiungibile, per poter avviare progetti pilota di successo e utili a ‘fare esperienza’.
- Servono dei meccanismi in grado di aiutare e facilitare il flusso di informazioni tra le varie organizzazioni (development e operation) coinvolte. In questo caso, vengono in aiuto tool tecnologici di planning e social It management che introducono funzionalità di collaborazione e condivisione per accelerare i processi grazie allo scambio e alla condivisione delle informazioni.
- Definire metriche comuni condivise (sia tecniche sia di business) tra development e operation che consentano alle due parti di operare verso un unico obiettivo (tipicamente, i team di sviluppo seguono metriche inerenti il codice di sviluppo applicativo per verificare e testare le funzionalità della soluzione, mentre le operation utilizzano metriche differenti per testare qualità, sicurezza, ecc.). Questo garantisce una visione olistica del processo di sviluppo e accelera il rilascio del servizio It.
Come accelerare il nuovo “stile” di sviluppo applicativo:le 3 indicazioni di Forrester
Alcuni processi, in particolare di quelli di change, release e configuration management, rappresentano tasselli fondamentale per accelerare il nuovo ‘stile’ di sviluppo applicativo. Quindi ecco come procedere:
- il primo step è ragionare in termini di automazione al fine di rendere quanto più ‘agili’ possibile gli interventi e accelerare le singole fasi del ciclo di sviluppo;
- laddove poi tale ciclo si avvicina al paradigma dell’Application Composition è fondamentale che tali processi siano governati in modo univoco per avere sempre sotto controllo gli eventuali impatti e le correlazioni che un intervento di configurazione, per esempio, genera sul piano del change e del release management (e viceversa).
Le applicazioni sviluppate sotto forma di ‘network di servizi’ sono più semplici e meno rischiose perché i rilasci sono più frequenti (con incrementi funzionali e migliorie di contenuti) e si utilizza poco codice nuovo e non testato. Se è vero però che i rilasci e la gestione dei cambiamenti (soprattutto se sostenuti da metodologie Agile e DevOps e dall’automazione dei processi) risultano più dinamici e semplici da gestire, non va trascurato il fatto che la complessità non sparisce, ‘semplicemente’ ricade (e cresce) in altri step dell’application life cycle. Ecco i consigli di Forrester per farvi fronte.
- coordinare gli aggiornamenti e le release di applicazioni ‘composte’ richiede nuove tecniche e nuove tecnologie: diventa fondamentale tenere traccia di tutte le funzionalità applicative e dell’usabilità in modo da apportare eventuali modifiche e aggiornamenti solo laddove i servizi sottostanti a supporto e correlati siano effettivamente pronti;
- servono sistemi di API discovery and dependency management: prima ancora di puntare al ‘riuso’, gli sviluppatori devono sapere che cosa c’è a disposizione; è fondamentale quindi avere un sistema di gestione e ricerca delle API (ecosistema sempre più complesso). Secondo gli analisti di Forrester gli API Search tool saranno cloud-based e guidati nella loro evoluzione dalle community globali di sviluppatori, anche open source;
- la complessità si sposta sul piano della gestione dei servizi: se è vero che la scrittura del codice si semplifica e il processo di rilascio dell’applicazione è accelerato, è innegabile che il continuo rilascio di ‘pezzi’ di servizio applicativo rendano più critica la gestione del servizio applicativo nel suo insieme. Un’attività che, secondo Forrester, dovrà essere supportata da nuovi tool tecnologici, sempre più resi disponibili attraverso modelli cloud e open source.
Quanto è diffuso il DevOps in Italia e in Europa, quali i benefici che si possono ottenere
Gli analisti raccontano uno scenario di indubbia e prosperosa crescita della diffusione e dell’adozione della metodologia DevOps nelle aziende. Tuttavia, andando ad analizzare in dettaglio alcuni dati di un’indagine compiuta da Freeform Dynamics l’anno scorso appariva evidente la difficoltà di tale percorso: solamente il 40% dei manager interpellati (su un panel di intervistati di 1.442 tra business manager e responsabili It, tra i quali 506 in Europa) dichiarava un’adozione diffusa della metodologia DevOps lungo tutta la propria azienda; il 32% la stava ‘sperimentando’ solo in alcune aree mentre il restante 28% era ancora fermo a guardare, anche questione Return on investment – Roi del DevOps non è infatti da sottovalutare.
Per quanto riguarda l’Italia, sempre Freeform Dynamics ha rilevato che – in uno scenario in cui l’81% degli intervistati italiani riconosce l’importanza di garantire un’adeguata conoscenza delle priorità di business nell’ambito dell’It, ma solo il 38% mette in atto questo principio e sempre l’81% considera importante disporre dell’infrastruttura e degli strumenti giusti, ma solo il 26% ha già raggiunto questo risultato – comunque l’84% dei partecipanti al sondaggio ritiene fondamentale acquisire le competenze informatiche necessarie per mettere in pratica la metodologia DevOps, ma solo il 35% le ha già adottate.
Eppure, le imprese che mostrano un elevato livello di adozione del DevOps nella realizzazione delle loro iniziative digitali sono anche quelle che hanno raggiunto i migliori risultati aziendali. In tutta Europa, tra il 70 e l’80% di queste realtà ha ottenuto ‘significativi benefici misurabili’ in termini di fidelizzazione dei clienti e acquisizione di nuovi e ha conseguito risultati concreti nei nuovi flussi di ricavi (ossia con una crescita di fatturato generato direttamente da nuovi servizi digitali).
In generale, ciò che appare evidente nelle analisi delle società di ricerca è che la ‘filosofia’ DevOps offre miglioramenti che variano a seconda della posizione in cui si trova l’azienda nel percorso di implementazione: ad esempio, il 46% dei decision maker It intervistati da Vanson Bourne afferma di aver già visto aumentare la frequenza del deployment dei propri software e servizi, mentre un altro 44% prevede di ottenere gli stessi risultati nel breve periodo; circa il 39% registra un maggior numero di clienti e/o utenti finali che utilizza i software e i servizi aziendali, e il 39% conferma un incremento della collaborazione tra reparti; oltre un terzo (36%) afferma di aver visto aumentare la qualità e le performance dei software e il 34% di aver ridotto il tempo dedicato alla correzione e alla manutenzione delle applicazioni.
In sintesi, alcune delle ragioni che rendono questa metodologia interessante per le aziende si evincono dalle risposte collezionate sia da Vanson Bourne sia da Freeform Dynamics: secondo quasi la metà degli intervistati in entrambi i panel “nell’economia delle applicazioni la qualità del software deve migliorare”. Anche le performance applicative sono citate come uno dei driver di DevOps, poiché le aziende sanno che rischiano di perdere i propri clienti qualora l’interfaccia utente non sia intuitiva o l’app troppo lenta rispetto alle esigenze e alle aspettative. Uno dei fattori che spinge particolarmente la crescita del DevOps è infatti la maggiore attenzione all’esperienza del cliente.
Di contro, le ragioni a testimonianza di coloro che si sono avvicinati al DevOps solo in via sperimentale o di coloro che ancora non sanno come ‘muoversi’ sono prevalentemente da ricondurre alla misurazione del valore, dell’efficacia e del Roi del DevOps; malgrado quest’ultimo stia conquistando popolarità tra chi per primo l’ha adottato, mancano infatti ancora sistemi di misurazione adeguati a comunicare il successo di un’implementazione.
