Wannabe CTO: il COVID-19, la scalabilità e lo sparring partner

Sentiamo sempre parlare della pandemia riferendoci ai deceduti, ai malati, ai casi totali. Sicuramente non potrebbe essere diversamente e io sono tra i primi che, nel periodo iniziale dell'epidemia in Italia, consultava i dati quotidianamente, facendo analisi e proiezioni con conoscenti e amici, anche qui su Linkedin.

La pandemia ha investito tutto e tutti e anche chi si occupa di commercio elettronico, come noi in eDock, abbiamo avuto uno tsunami da gestire. Lo tsunami è stato veramente tale e per un'applicazione ad alta intensità di dati (data-intensive application), questi tsunami sono sconvolgenti perché mettono a dura prova la tenuta del sistema.

Il COVID-19 ha colpito pure noi, causandoci non pochi grattacapi. Siccome un'immagine vale più di mille parole, ecco rappresentata in immagine la mole di ordini che abbiamo dovuto gestire, il nostro tsunami. Ho nascosto, per ovvie ragioni (come fa sempre Amazon quando fornisce dei dati), il valore numerico (asse Y), la scala è lineare. I dati di Giugno sono ovviamente incompleti.

In poche parole:

• nel periodo natalizio 2019 (novembre - dicembre), che è solitamente il periodo più critico per noi e per i nostri clienti, abbiamo processato come di consueto circa il 30% di ordini in più della media dei mesi precedenti.
• nel periodo di lockdown (marzo - aprile - maggio) abbiamo infranto ogni Natale. La media di quei tre mesi è valsa il 35% in più del Natale 2019, con Aprile che è stato circa il 50% in più di Dicembre 2019. Praticamente abbiamo avuto una situazione "peggiore" (ovviamente noi siamo molto contenti per noi e per i nostri clienti!) del Natale e persistente per tre mesi consecutivi.
• In Aprile abbiamo gestito più del doppio degli ordini che solitamente gestiamo in un mese qualunque (+125% rispetto ad Aprile 2019)

Scalabilità

Nel 2008, quando siamo partiti con eDock, l'applicazione girava su un Windows Server ospitato da un fornitore di cui non ricordo neanche il nome e i servizi di integrazione con i diversi marketplace erano tutti servizi Windows e tutti i dati archiviati su una installazione di SQL Server sulla stessa macchina (se non ricordo male). Ora, per chi è tecnico la cosa è comprensibile. Per chi non è tecnico, questa è una strutturazione dell'applicazione piuttosto primitiva, poiché basta che quella macchina abbia un disservizio e... il servizio si ferma. Basta che il servizio Windows per qualche ragione si arresti e... qualcuno deve accorgersene e intervenire.

Certo eravamo proprio all'inizio, i clienti dovevano ancora arrivare e non avevamo ancora in mente cosa sarebbe venuto fuori negli anni a venire. È abbastanza normale partire un po' con le pezze, all'inizio, quando sei tu che ti devi finanziare lo sviluppo (e, soprattutto, quando non hai mai affrontato problemi di questo tipo).

Nel 2010 circa, iniziai a sentire parlare di Microsoft Azure e fui abbagliato dalla potenza: il messaggio era chiaro "tu sei uno sviluppatore e devi occuparti del codice. Noi ci occupiamo dell'infrastruttura". Il sogno si realizzava, potevo essere indipendente dalla macchina su cui girava l'applicazione, non avrei dovuto più preoccuparmi dei servizi, avrei avuto finalmente una vita felice, fatta di codice, versioni, deploy e clienti contenti.

Affrontai la migrazione di eDock ad Azure con il supporto di Fabio Santini e devo riconoscere che fu uno dei passaggi più sfidanti della mia vita lavorativa. Il passaggio al cloud comporta un cambio completo di paradigma e, di conseguenza, un cambio piuttosto pesante di architettura. Specialmente circa 10 anni fa non era una cosa banale, soprattutto quando sei partito, anche se da poco, e hai già dei clienti in produzione.

Architettura cloud

Come può immaginare chiunque, un'applicazione per poter continuare a funzionare anche ha un disservizio quando la macchina su cui si appoggia, deve essere pensata attentamente. Un'applicazione che è in grado di morire dolcemente e riprendersi da sola, viene chiamata "resiliente" o "robusta". Per avere un'applicazione robusta, su Azure, devi fare in modo tale che tu non sappia assolutamente dove girerà la tua applicazione, poiché oggi può essere sul server X, ma tra 5 minuti sul server Y e tra 3 ore sul server Z. Esistono numerosi servizi di Azure che ti permettono di raggiungere questo scopo più facilmente.

Invito ora a pensare a cosa sarebbe stato qualora non ci fossimo attrezzati per tempo. Certo, come mostrerò fra poco, durante lo tsunami non sono mancati i momenti di difficoltà, ma l'essere attrezzati con una architettura resiliente e flessibile ci ha permesso di 1. gestirla, 2. gestirla con rapidità, 3. limitare il numero dei disservizi.

Azure e l'architettura cloud di eDock ci hanno letteralmente salvato.

Cosa abbiamo potuto fare?

Grazie all'architettura cloud di cui ci siamo dotati abbiamo potuto:

• incrementare il numero di macchine a disposizione per gestire le richieste dei clienti. Questa si chiama scalabilità orizzontale
• incrementare la potenza delle macchine per riuscire a gestire richieste più pesanti. Questa si chiama scalabilità verticale
• distribuire la potenza disponibile sulle parti delle applicazioni che necessitavano di più. La nostra architettura è, praticamente, a microservizi per cui, ad esempio, abbiamo potuto isolare i servizi di integrazione con Amazon ed eBay da tutto il resto, dedicando ad ognuno una potenza di calcolo ben definita
• monitorare attentamente l'applicazione, accorgendoci in maniera proattiva di cali prestazionali per cercare di prevenire i disservizi. Questo si chiama tracing

Lo sparring partner

Ho avuto la fortuna di non dover vivere questo COVID-19 in ospedale e di poter affrontare una nuova affascinante sfida lavorativa. Vedere la propria applicazione così sotto stress e, tutto sommato, in grado di gestire un picco così improvviso e critico (vi basti pensare che per un venditore Amazon lo spedire in ritardo alcuni ordini può significare la chiusura perenne dell'account e, quindi per alcuni, la chiusura dell'attività) è stato soddisfacente.

Tuttavia devo riconoscere una figura importantissima, ovvero quello dello sparring partner. Quando succedono questi periodi di extra-lavoro ed extra-sfide, è indispensabile, a mio avviso, avere una persona di fiducia a cui tirare i cazzotti (virtuali, ovviamente) e che ribatte con cazzotti ancora più pesanti. Una persona che non necessariamente lavora nel progetto, ma che ha la competenza per farti vedere le cose da un'altra prospettiva e, magari, farti accendere la lampadina.

Colgo quindi l'occasione per ringraziare pubblicamente Antonello Scalmato, mio ex compagno di Università, che non solo è stato un ottimo sparring partner, ma anche una spalla su cui piangere nei momenti più tosti. Un ottimo CTO, un grande conoscitore di Azure e un super amico!

Consiglio a tutti, quindi, di trovarsi il proprio sparring partner e di combatterci spesso: sarà una crescita mostruosa, meglio se per entrambi.

Conclusioni

Tutto questo è stato facile? No. Tutto questo è stato gratis? No.

Ecco quindi i consigli che mi sento di rivolgere a chi, come me, è un Wannabe CTO:

• se hai un SaaS, la scalabilità e la resilienza sono tutto
• l'applicazione è viva, la manutenzione vale il 99% del nostro lavoro
• lascia il codice, ogni giorno, in una condizione migliore di come l'hai trovato
• il debito tecnologico lo dovrai sempre pagare, prima o poi. Pensaci per tempo
• trovati uno sparring partner con cui "fare guantoni" e che ti aiuti a vedere le cose da una prospettiva diversa