Quando la scalabilità è considerata un dettaglio tecnico

Nel vasto universo dei progetti informatici esiste una dimensione parallela dove i server non si stancano mai, le risorse sono infinite e la parola “limite” è stata cancellata dal vocabolario aziendale.

Parliamo di quei requisiti non funzionali che dovrebbero essere discussi nelle fasi preliminari, ma che vengono sistematicamente ignorati. Performance, scalabilità, disponibilità: concetti che nella mente di chi decide hanno consistenza labile. Non esistono ordini di grandezza, solo vaghe aspirazioni cosmiche.

L’illusione dell’infinito

Nella mente di molti manager IT, nulla ha un limite. Il numero di utenti collegati contemporaneamente è infinito. Se il sistema permette di creare un oggetto logico, se ne possono creare dieci, mille, un milione. Il concetto di limite è semplicemente assente: tutto è infinito, a parte il budget.

Chiedete a un decisore quanti utenti dovranno utilizzare il sistema. La risposta oscillerà tra “quanti ne servono” e “tutti”. È come chiedere a un bambino quanti gelati vuole: la risposta sarà sempre “tutti quelli che esistono”.

Gli ordini di grandezza che non esistono

Nel mondo concreto, esistono ordini di grandezza ben definiti. Le prestazioni e la scalabilità richiedono analisi approfondite, stime basate su dati reali e valutazione attenta dei carichi di lavoro.

Ma le risposte evaporano in un “Ovviamente funzionerà per sempre!” “Sono questioni tecniche” dicono, come se tecnico significasse “si risolverà da solo per magia”. La disponibilità deve essere del 100%, come se fosse possibile eliminare l’entropia dell’universo.

Questa mentalità ignora la differenza tra gestire cento utenti e centomila. Tra processare mille transazioni al giorno e un milione al minuto. Ogni ordine di grandezza introduce complessità e costi esponenzialmente maggiori.

Le decisioni senza vincoli reali

Pensare che il sistema debba gestire utenti infiniti porta a rischi enormi: costi esorbitanti, architetture troppo complicate e progetti che crollano al primo sovraccarico.

Nel mondo reale, ogni parametro ha un limite. Ogni performance ha un costo. Ignorare questi vincoli non li fa sparire, li trasforma in problemi che emergeranno in produzione quando sarà troppo tardi. Un database può gestire milioni di record, ma non miliardi senza architettura adeguata.

I compromessi che nessuno vuole accettare

I manager pensano in termini assoluti, ma la realtà tecnica è fatta di compromessi. Vuoi più scalabilità? Preparati a sacrificare semplicità. Vuoi disponibilità al 99,999%? Apri il portafoglio per numeri con molti zeri.

Ogni “nove” aggiuntivo nella disponibilità costa esponenzialmente di più. Il 99,999% richiede data center multipli, failover automatici, team 24/7. Ma quando si discute di disponibilità, nessuno vuole sentire queste distinzioni. Si vuole semplicemente “sempre disponibile”.

Le performance come problema futuro

L’approccio classico è “Le performance sono un problema del futuro!” Si sviluppa senza considerare l’impatto delle scelte architetturali. Tanto si ottimizzerà dopo. Peccato che “dopo” significhi riscrivere porzioni significative del sistema.

Quando arrivano i test di carico, tutti sembrano sorpresi che un sistema progettato per cento utenti vacilli con mille. È come stupirsi che un ascensore per quattro persone non regga un’intera classe. “Ma funzionava così bene con un utente solo!”

I test, quando vengono fatti, usano volumi ridicolmente bassi. Si testa con un decimo degli utenti previsti, con dati puliti, in condizioni ideali che non si verificheranno mai.

La gestione delle aspettative assente

Non comunicare i limiti del sistema è un errore comune. Gli utenti sviluppano la convinzione che ogni ambiente debba essere disponibile 24/7 con prestazioni da supercomputer.

La storia dell’utente che si lamenta perché l’ambiente di test non è disponibile alle tre del mattino è un classico. È come lamentarsi che il ristorante dove si fanno le prove non sia aperto a mezzanotte. In produzione ci sono backup e monitoring, ma questo non significa replicare tutto in ogni ambiente.

Caratteristiche architetturali, non decorazioni

Le performance e la disponibilità sono caratteristiche architetturali che vanno pensate fin dall’inizio, come la portata di un ponte. Non sono decorazioni che si aggiungono dopo.

Un sistema pensato per centinaia di utenti richiede un’architettura fondamentalmente diversa da uno per milioni. Queste decisioni influenzano ogni aspetto del design. Tentare di aggiungere scalabilità dopo è come allargare le fondamenta di un grattacielo dopo averlo costruito.

Lo scaricabarile inevitabile

Quando emergono i problemi, e emergono sempre, inizia il gioco dello scaricabarile. “Ma i test di carico non li avete fatti?” “Sì, con un decimo degli utenti reali”. “E perché non l’avete detto?”

Gli sviluppatori dicono che i requisiti non erano chiari. I manager dicono che gli sviluppatori avrebbero dovuto sapere. Il vero problema è sistemico: la mancanza di una discussione onesta su limiti e compromessi fin dall’inizio.

Verso una pianificazione realistica

Le performance e la disponibilità non sono optional da considerare dopo. Sono parte integrante del progetto fin dalla concezione. Richiedono discussioni difficili su trade-off e compromessi. Richiedono stime realistiche di carichi e volumi.

Un sistema ben progettato non è quello che funziona quando tutto va bene, ma quello che fallisce in modo prevedibile quando le cose vanno male. Meglio sapere in anticipo che il sistema può gestire cinquantamila utenti concorrenti, piuttosto che scoprirlo quando il sessantamillesimo causa il crash totale.

Serve il coraggio di dire “questo sistema può gestire X utenti con Y transazioni al secondo e garantire Z% di disponibilità”. Numeri specifici, non vaghe promesse di infinito.

Questo articolo è tratto da “Non funziona niente! – I progetti IT in crisi”, il primo libro della collana Nothing Works! — una tragicommedia aziendale per chi ha visto troppi Gantt chart trasformarsi in fiction.

Scopri la collana completa, gli altri libri e le prossime uscite su nothingworks.it

Vuoi il libro subito? Compralo su Amazon

Potrebbe interessarti anche

• Sistemista IT in una PMI: mansioni e competenze
• DIRETTORE ACQUISTI
• Perché documentare gli interventi IT potenzia la posizione del Sistemista?
• BACK OFFICE MANAGER
• Da sistemista IT a IT Manager: un, possibile, percorso di carriera nell’ambito manifatturiero
• SOC MANAGER 
• I problemi quotidiani di un Sistemista IT e come risolverli
• SISTEMISTA
• Quanto guadagna un Sistemista a Torino?
• SISTEMISTA IT