Il caso Tablo in università: parliamo di scalabilità del software

Cosa c’entrano Tablo, l’università Ca’ Foscari e la scalabilità del software? L’11 maggio Mabiloft ha avuto il piacere di riunire questi tre argomenti in una lezione tenuta dal nostro Head Frontend Engineer Giulio Trolese all’università Ca’ Foscari di Venezia.

La lezione ha avuto luogo all’interno dell’insegnamento di Software performance and scalability del professore Andrea Marin per il corso di laurea magistrale in Computer Science and Information Technology. 

Mabiloft ha da lungo tempo stretto rapporti con Ca’ Foscari in quanto partner per tirocinio e ciò ci ha portato ad avere l’opportunità di tornare tra i banchi, questa volta non nel ruolo di studenti, ma come professionisti pronti a condividere la propria esperienza.

Collegando concetti teorici come architettura, database e algoritmi, a un caso studio che abbiamo concretamente affrontato, quello di Tablo, abbiamo trattato un tema che, prima o poi, ogni prodotto digitale deve affrontare: la scalabilità del software.

Cosa significa scalabilità del software

Cosa vuol dire scalare un software? La scalabilità di un software è la sua capacità di reggere più carico di lavoro, come quello derivante da un significativo aumento del numero di utenti.

Non si tratta solo di evitare il crash, ma anche di mantenere le performance in linea con le aspettative degli utenti. Un’app che non scala bene, infatti, diventa lenta, inutilizzabile dal punto di vista dell’utente: secondo uno studio del 2018 il 38% degli utenti è pronto ad abbandonare una pagina che non carica entro i 5 secondi.

Eppure qualsiasi bravo sviluppatore è in grado di prendere le giuste decisioni tecniche per permettere a un’applicazione di scalare senza problemi. La vera difficoltà, però, è conciliare l’aspetto tecnico con le esigenze del business. La scelta ottimizzata da un punto di vista tecnologico, infatti, non sempre è conciliabile con quello che il prodotto può permettersi.

Il caso di Tablo

Quando abbiamo lanciato la V2 di Tablo sapevamo che la scalabilità sarebbe stato uno dei punti critici. La nuova versione dell’app, infatti, aveva ottimizzato la user experience rivedendo i flussi utente, ma ciò ha comportato un aumento nel numero di utenti, che non poteva essere retto dall’infrastruttura esistente.

Nei momenti di picco di utilizzo, ad esempio poco prima del fine settimana, l’applicazione mostrava segni di cedimento. In particolare, ottenere la lista degli eventi poteva richiedere fino a 8 secondi, ben al di sopra della tolleranza dell’utente medio.

Bisognava agire in fretta, prima che gli utenti abbandonassero l’applicazione. E una soluzione c’era. Sfortunatamente, questa soluzione non era applicabile per Tablo.

Gli utenti erano divisi tra coloro che avevano già installato la nuova versione dell’applicazione e coloro che utilizzavano ancora quella precedente. Prendere le misure necessarie, le più ovvie da un punto di vista tecnico, avrebbe escluso gli utenti che ancora non avevano aggiornato l’app. In pratica, il rischio era che questi utenti passassero da un’esperienza deficitaria a non poter più utilizzare l’applicazione in toto.

Abbiamo quindi dovuto cercare una soluzione che potesse contemporaneamente:

• Garantire performance ottimali
• Essere rilasciata in produzione il prima possibile
• Evitare di perdere una fetta di utenza

Non vi annoieremo con i dettagli tecnici, ma se anche voi state riscontrando problemi a scalare la vostra applicazione, noi di Mabiloft possiamo aiutarvi. Per vedere altri case study o per prenotare una call conoscitiva senza impegno, consultate il nostro sito.

La lezione sulla scalabilità del software

Ma come è andata la lezione a Ca’ Foscari? La partecipazione degli studenti è stata un’aggiunta preziosa alla sola esposizione del caso Tablo. Domande, osservazioni e curiosità ci hanno permesso di ragionare sul processo decisionale che porta un team a preferire una soluzione rispetto a un’altra.

In uno scenario ideale, tutto è ottimizzato al massimo delle sue potenzialità. Ma ciò si scontra spesso con la realtà dei fatti, in cui la scalabilità deve essere valutata anche nell’ottica delle decisioni strategiche che devono essere prese nel ciclo di vita di una startup.

Per quanto riguarda il messaggio che abbiamo voluto lasciare agli studenti, qui sotto trovate riassunti i punti principali che abbiamo toccato durante la lezione.

Non scalare tutto e subito. Progettare un sistema sovradimensionato troppo presto può rallentare lo sviluppo e far lievitare i costi. Specialmente nell’ambito di una startup, a volte è più efficace rinviare l’ottimizzazione a un secondo momento. Una buona architettura non è quella perfetta fin dal primo rilascio, ma quella che è in grado di evolvere assieme al prodotto.

L’ottimizzazione deve partire dai dati. Senza misurazioni sulle performance e l’utilizzo, il rischio è quello di agire su feature non critiche. Non tutte le funzionalità hanno lo stesso impatto. Ottimizzare le aree sbagliate è una perdita di tempo e denaro per un prodotto digitale.

Le soluzioni non devono essere perfette, ma funzionali. La soluzione ideale non sempre è applicabile, sia per una questione di fattibilità che di costi. Spesso una soluzione che funziona è tutto ciò che è necessario. E solo in seguito, con un budget maggiore, quando il prodotto lo richiede, si può ricorrere a un approccio diverso.

Momenti come quello trascorso con gli studenti universitari sono preziosi per noi, perché ci permettono di trasmettere la nostra maniera di intendere lo sviluppo del software: non è solo scrivere codice, ma progettare prodotti digitali in grado di crescere, adattarsi alle circostanze e generare valore nel tempo.

Ringraziamo infinitamente Ca’ Foscari, gli studenti che hanno partecipato e il professor Marin per averci dato quest’opportunità. E se anche voi volete sentirci parlare degli argomenti che ci appassionano, nelle vostre aule o nei vostri uffici, noi non vediamo l’ora di dare il nostro contributo. Contattateci ai nostri recapiti o nel form che trovate nella pagina dedicata.