Pacchettini o Containers?

 10 Oct 2022 -  Giulio Vian -  ~5 minuti

In un precedente articolo ho considerato il principio che DevOps raccoglie da Lean, ossia l’importanza di minimizzare la dimensione dei rilasci. In Lean si parla di small batches, trattandosi di software riduciamo per quanto possibile la quantità di modifiche presenti in un rilascio. Con dei semplici esempli spero di aver dimostrato i vantaggi che se ne ricavano e come l’automazione sia conseguenza di minimizzare il peso dei nostri rilasci.

Oggi torniamo sul tema perché Accelerate   ci insegna che le organizzazioni con le migliori performances hanno valori altissimi per Deployment Frequency, la frequenza dei rilasci, fino a diversi rilasci giornalieri (p. 19).

 

Per quanto ciò sia innegabile per una organizzazione nel suo complesso, la metrica di Deployment Frequency deve esser considerata in modo diverso quando scendiamo a livello di una singola applicazione. La frequenza di aggiornamento dipenderà sia dalla maturità dell’applicazione che dalla sua importanza strategica. Tali fattori si compongono e mediano quando abbiamo un portafoglio IT con molte applicazioni sviluppate internamente.

Maturità

Ogni applicazione, sotto-sistema IT, system asset, o come lo si voglia chiamare ha uno specifico ciclo di vita, variamente suddiviso in quattro, cinque o più fasi (es: Acquisto, Rilascio, Uso, Manutenzione, Ritiro e Smaltimento).

Consideriamo ora solamente i sistemi sviluppati internamente, le applicazioni. Per questi gli stadi sono tipicamente quattro:

1. Sviluppo
2. Crescita
3. Maturità
4. Declino

Iniziamo con la prospettiva finanziaria per una singola applicazione o prodotto o servizio. Questa si focalizza sull’utilizzo ovvero sui ricavi. La curva di utilizzo che ci attendiamo è quella tipica di un prodotto, con una fase di crescita intensa dopo la pubblicità iniziale, una stabilizzazione e infine un declino fino al ritiro finale.

Veniamo ora alla prospettiva dello sviluppo ingegneristico. Qui ci interessa la frequenza con cui introduciamo modifiche nelle suddette applicazioni.

Uno schema tipico vede una fase di investimento pressoché costante fino a quando il prodotto o servizio non prende piede ed è possibile aumentare gli investimenti, dando maggior valore ai clienti. Una volta maturato il prodotto, l’investimento e dunque il tasso di cambiamento cala con una certa rapidità: è la fase in cui gli investitori cominciano ad incassare. Le novità diminuiscono e la manutenzione ordinaria diventa l’attività prevalente. Quando si comprende che il mercato non darà più ritorni per quel prodotto o servizio, ecco che restano solo attività di manutenzione per un parco utenti sempre più calante, fino al ritiro definitivo del prodotto.

Questo è un ragionamento semplificato naturalmente. Se l’applicazione vede una crescita esponenziale, succede non di rado che il disegno iniziale non sia in grado di sopportare il tasso di cambiamento né il carico crescente. Quando l’organizzazione, sulla base delle evidenze tecniche, decide per un ridisegno radicale, abbiamo la sostituzione di un prodotto con uno nuovo

La migrazione di Twitter da Ruby a Scala è tra gli esempi più noti di una riscrittura di un prodotto per adeguarlo alla crescita (vedi Twitter Shifting More Code to JVM, Citing Performance and Encapsulation As Primary Drivers (infoq.com)   e Twitter Engineering: Twitter Search is Now 3x Faster   ). Altri esempi sono Facebook Messenger ( Project LightSpeed: Rewriting Messenger to be faster, smaller, and simpler   ).

In sintesi: la quantità e frequenza dei cambiamenti per una applicazione varia nel tempo, declinando quando raggiunge la maturità.

Strategicità

La cosa più certa del futuro è la sua imprevedibilità. E dopo questa bella catalanata   (ai più giovani suggerisco guardare Le catalanate di “Quelli della notte” - Rai Teche   ) cerchiamo di descrivere quanto l’importanza strategica di una applicazione influisce sulla sua evoluzione.

Nella sezione Maturità il grafico dell’utilizzo appare ben definito, ma sarà aderente alla realtà solo quando l’applicazione ha concluso la propria esistenza! Durante le fasi iniziali si possono fare solo supposizioni su come evolverà la curva. In risposta alle condizioni del mercato, delle richieste degli utenti, delle scelte strategiche della dirigenza, quest’ultima può decidere di investire maggiormente o togliere risorse fino a decidere, ad esempio, di sostituire una soluzione fatta in casa con una commerciale (buy vs make). Chi fosse interessato ad approfondire il tema di calibrare l’investimento IT raccomando studiare lo strumento delle Wardley Maps   .

Abbiamo dunque due elementi che concorrono ad incrementare o diminuire il lavoro di sviluppo e di conseguenza la quantità di modifiche disponibili nel tempo per essere rilasciate in produzione.

Rilasci

Alcuni di voi saranno già saltati alle conclusioni di come i due elementi, maturità e strategicità, di un prodotto influenzano i rilasci, ma procediamo con ordine.

Chiaramente maggiore il numero di persone che concorrono ad un prodotto, una applicazione, maggiore la quantità di modifiche prodotte nell’unità di tempo.

È vero anche l’inverso: meno persone lavorano, minori cambiamenti vengono prodotti. Questo in particolare quando il prodotto si avvia al declino: le modifiche diventano infrequenti, una manciata all’anno, senza nuove funzionalità, solo correzioni e adeguamenti.

Questa semplice constatazione ha un impatto diretto sulla frequenza di rilascio: se non ci sono modifiche disponibili, cosa posso rilasciare?

Conclusione

In sintesi, la metrica Deployment Frequency ha senso solo a livello di una organizzazione con un portafoglio di applicazioni. Non può essere considerata a livello di una singola applicazione a meno di fattorizzare la maturità e l’investimento sulla stessa, il che vuol dire usare una metrica diversa.

In realtà, il vero approccio Lean richiede la capacità di rilasciare on-demand, ogni qualvolta sia necessario o utile. Da qui il bisogno di automazione anche per quei casi meno evidenti, come ho accennato in Automatizzare? Sempre! .

In futuro articolo, affronterò il tema dei rilasci non-funzionali di una applicazione e della sempre maggiore importanza che hanno nell’informatica moderna.

Voi che ne pensate?