È in corso una silenziosa rivoluzione nello sviluppo software: la natura del lavoro si sta spostando da “sviluppare e utilizzare applicazioni di grandi dimensioni complesse” a “collegare in modo esclusivo nuovi ed esistenti servizi creandone un differente valore aggiunto”. È questo, in sintesi, lo scenario che ne traggono Kurt Bittner e Michael Facemire, analisti di Forrester, nel tracciare il contesto di riferimento entro cui operano oggi gli sviluppatori applicativi. “Combinando servizi applicativi disponibili ‘apertamente’ [all’interno delle community globali di app developers – ndr] attraverso Api (application programming interfaces), service-rich platform (piattaforme che già incorporano pacchetti di servizi applicativi) e nuove tecnologie di sviluppo è oggi possibile creare applicazioni di alta qualità”, scrivono i due analisi, senza “scrivere da zero il codice nativo (come si faceva solo fino a qualche anno fa) e con tempi di rilascio molto più celeri”.
La vera essenza dell’application development è cambiata, sostengono i ricercatori: “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 ‘prodotti vitali’ utilizzando servizi già disponibili, scrivendo nuovo codice solo quando è inevitabile e assolutamente necessario”. Attraverso questo approccio, 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 approcci metodologici rigorosi, controllati e controllabili, nuove competenze e specifiche tecnologie a supporto.
La fine del Big Design
Il paradigma e le metodologie tradizionali legate allo sviluppo applicativo incentrare sul ‘Big Design’ (scrittura di codice nativo per realizzare monoliti applicativi) rappresentano oggi un approccio fallimentare per svariate ragioni:
1) 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, fortemente influenzato dalla digitalizzazione, in generale, e dalla Software Economy nello specifico;
2) 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;
3) 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), esigenze difficilmente sostenibili per aziende i cui giochi competitivi si dipanano in mercati globali che cambiano molto rapidamente;
4) 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; laddove si è intervenuti a sostegno, come abbiamo visto, di interoperabilità e integrazione; si sono così formate intricate reti applicative 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);
5) 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.
Application Composition: Agile e DevOps le risposte metodologiche
In risposta a tutte queste complessità, dicono Bittner e Facemire, è necessario passare da un approccio di “Application Design” verso un più dinamico modello di “Application Composition”, secondo gli analisti oggi più efficace perché in grado di accelerare i cicli di sviluppo e rilascio delle applicazioni, nonché di garantirne una continua e rapida evoluzione (figura 1). L’evoluzione delle tecnologie ha generato un nuovo ‘stile’ di sviluppo che ha decretato la fine dell’Application Design: il nuovo paradigma 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. Abbiamo più volte descritto la stretta correlazione esistente tra l’Agile e il DevOps; quello che qui ci preme sottolineare sono gli aspetti di automazione dei processi, in particolare di quelli di change, release e configuration management, tasselli fondamentali per accelerare il nuovo ‘stile’ di sviluppo applicativo (application composition).
Secondo Elinor Klavens e Amy DeMartine, entrambe analiste di Forrester, nel nuovo ‘software development style’ i processi citati devono essere considerati e gestiti attraverso una visione olistica dato che sono tutti processi strettamente correlati e interdipendenti tra loro (figura 2) [sul piano metodologico, in questo senso, possono essere di supporto anche le indicazioni del framework Itil – ndr]. “Le organizzazioni che intendono affidarsi alle metodologie Agile e DevOps – scrivono le due ricercatrici – devono essere consapevoli del fatto che ciò richiede cambiamenti importanti in alcune aree chiave del ‘service design & delivery’. Le metodologie non sono di per sé la soluzione ma di fatto forniscono metodi sistematici e principi guida affinché si possa arrivare ad un application life cycle efficace e di valore per il business”.
È in questa logica, dunque, che le metodologie citate possono offrire il corretto supporto. Tornando ai processi di change, configuration e release management, il primo step, suggeriscono le analiste, è 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, come accennato, 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).
L’aiuto tecnologico
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 contenuti ma rapidi e frequenti) 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:
1) 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;
2) 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 analsiti di Forrester gli API Search tool saranno cloud-based e guidati nella loro evoluzione dalle community globali di sviluppatori, anche open source;
3) 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’applicazione, potenzialmente, potrebbe essere il risultato di un insieme di ‘pacchetti di servizi’ provenienti da vari vendor. “Gestire tale complessità non è ‘umanamente possibile’, servono nuovi tool tecnologici”, affermano gli analisti Forrester. Soluzioni che, anche in questo caso, secondo le previsioni degli analisti, saranno sempre più resi disponibili attraverso modelli cloud e open source (vedi articolo dal titolo "Un It aziendale "contagiato" dall'open source").
Per maggiori informazioni: Devops e agile nello sviluppo software
