Stavo leggendo - qualche tempo fa - di come, passati i 40 anni, i ricordi tendano ad accavallarsi e una cosa che sembra accaduta 2 o 3 anni fai in realtà sia accaduta ben più di 10 anni fa.

Probabilmente questa considerazione da bar non è del tutto infondata: ricordo infatti con estrema lucidità quando, nelle varie conferenze italiane e internazionali, si parlava delle architetture basate sui microservizi come la soluzione a tutti i mali causati dal software monolitico.

Per fortuna - lungi da essere uno che si fa ammaliare e trasportare dalle mode del momento - la situazione è decisamente cambiata.

Uso come cartina tornasole il QCon London 2019, la conferenza organizzata da InfoQ dedicata allo sviluppo software che si focalizza sulle tecnologie innovative utilizzate da quelli che vengono definiti “innovator, early adopter, and early majority stages” da Moore nel suo “Crossing the Chasm”.

Nonostante la tecnologia basata sui microservizi sia ormai largamente adottata, finalmente ne vengono analizzati i reali contesti di utilizzo e gli scenari che intrinsecamente porta con sé rendendola estremamente appropriata in talune realtà e meno in altre.

Finalmente non si ha più paura di affermare, ad esempio, che “i microservizi sono più complicati da gestire e mantenere” (Sarah Wells, Financial Times) e che se un’azienda non li valuta a tutto tondo ma solo come “componente tecnologica” ignorando le implicazioni lato organizzazione, flussi, struttura, team e persone, costituiranno essi stessi la nuova componente legacy prendendo solamente il posto dell’applicazione monolitica!

Ovviamente la componente tecnologica non è stata trascurata affatto; sono infatti tre gli aspetti che hanno ricevuto maggiore attenzione: orchestrazione, service meshes e FaaS.

A farla da padrone per quanto riguarda l’orchestrazione è ovviamente ancora Kubernetes; finalmente, anche su questo fronte, si è iniziato a parlare non solo dei vantaggi che l’adozione di un sistema di orchestrazione di container porta con sé ma anche del crescente livello di complessità di una architettura basata su servizi e containers. Non mi riferisco - soltanto - ad una complessità tecnica ma anche strutturale e organizzativa: dall’ownership di un servizio (e di conseguenza degli svariati containers e sidecars) fino alle problematiche di gestione e versionamento delle configurazioni o alla scrittura di documentazione: tutte pratiche ormai sdoganate nel mondo dello sviluppo software ma nuove nella gestione di una architettura di orchestrazione di containers (da segnalare che c’è già chi sta provando a “configurare” pods e containers usando JavaScript!).

Ovviamente, per un problema che si risolve, altri sette se ne creano: come gestisco efficacemente il traffico sempre crescente tra i servizi? Come individuo all’interno dell’infrastruttura un’istanza di un servizio con il quale ho la necessità di comunicare? Come posso gestire il rilascio di nuove versioni di un servizio, l’A/B Test, il rilascio incrementale o il bilanciamento di carico? Per non parlare poi della sicurezza: come essere certi che i servizi dialoghino tra loro in modo cifrato e chi garantisce il rispetto degli standard di sicurezza? Chi autentica le richieste e ne autorizza o meno l’esecuzione? Come tentare di prevenire il guasto a un servizio monitorandone lo stato di salute e gestendone il traffico in ingresso? E come reagire invece a un guasto di uno o più servizi senza compromettere l’esperienza utente? Istio, al momento, è l’implementazione più nota di un’architettura di service mesh.

Parlando ancora di servizi e soprattutto avendo ormai sdoganato la natura effimera degli stessi, in un’epoca in cui il cloud ha rivoluzionato il modo di gestire le applicazioni, perché in molti contesti si ragiona ancora in termini di server anche se spesso non si ha più a che fare con i server fisici? Cosa succede se teniamo i server fuori dall’equazione e iniziamo ad astrarre ancora maggiormente i flussi di lavoro, la logica di business, i dati e i relativi layer di persistenza? Le declinazioni attuali delle cosiddette tecnologie Serverless sono FaaS e BaaS: Function-as-a-Service come AWS Lambda, Auth0 Webtask, Azure Functions, Google Cloud Functions e Backend-as-a-Service come Auth0, Amazon DynamoDB, Google Firebase e altre.

In tutti e tre i casi, sia che si utilizzino sistemi di orchestrazione che architetture di service mesh oppure ci si affidi a tecnologie Serverless gestite da un vendor, restano purtroppo valide queste affermazioni: i sistemi falliscono; su larga scala i sistemi falliscono un casino.

La cultura aziendale che consideri il fallimento di un servizio un evento naturale, che limiti i danni di tale malfunzionamento cercando di mantenere operativi i servizi, che automaticamente (e velocemente!) risolva la situazione di pericolo, è terreno fertile per la nascita di ambienti resilienti.
Le attività proattive finalizzate a prepararsi a essere impreparati e a mantenere alto il potenziale di azioni adattive future quando le condizioni cambiano sono caratteristiche che un sistema fa e non che un sistema ha.
A tutti i livelli, ormai, si costruiscono sistemi distribuiti molto complessi: documentazione, runbooks, metriche e tracing sono ormai caratteristiche imprescindibili di qualsiasi architettura. Un complesso sistema distribuito senza il chaos testing tenderà, inevitabilmente, a fallire nei modi più creativi e disparati quando meno te lo aspetti!

La resilienza è un impegno che, all’interno di un’organizzazione, deve essere preso a tutti i livelli; la cultura dell’apprendimento, dell’irreprensibilità e del non attribuire “la colpa” così come la consapevolezza e la trasparenza rispetto all’esistenza reale di rischi, sono fattori fondamentali di resilienza così come lo sono la preparazione, la flessibilità e la capacità di reagire ai cambiamenti.
Sono da molti anni appassionato di tecniche investigative relative agli incidenti aerei e ho ormai fatta mia la considerazione che attribuire a una “causa principale” la disgrazia è fondamentalmente sbagliato perché l’errore palese richiede sempre una serie di altri errori per trasformarsi in disastro: “la causa” isolata di un incidente non esiste. Valutazioni diverse da questa non riflettono una comprensione tecnica della reale natura del fallimento, bensì il bisogno sociale e culturale di incolpare qualcuno o qualcosa.

Alla base di molte delle tracce e dei talk di questa edizione di QCon London vi sono alcune delle considerazioni presenti nel libro “Accelerate. The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations” (Nicole Forsgren, Jez Humble, e Gene Kim). L’invito alla lettura di Limoncelli, coautore di “The Practice of Cloud System Administration” è sferzante: “Qui sono racchiuse le considerazioni che CEO, CFO e CIO devono disperatamente sapere se la loro azienda vuole sopravvivere in questo nuovo mondo software-centrico; chiunque non legga questo libro verrà sostituito da qualcun altro che lo avrà invece letto”.