img_0753

Scalabilità

Ultimamente, complice la metodologia Agile e gli MVP, si pospone e trascura la questione della scalabilità del software, considerandola rimandabile a lungo.

Finché il prodotto non gode del meritato successo, tutto procede bene. Poi arrivano gli utenti e l’architettura mostra tutte le falle.

Il prodotto crolla in produzione e la massima “fail fast succeed faster” non fa in tempo a essere applicata: si fallisce e basta con una grande scritta EPIC FAIL lampeggiante.

Occorre quindi prevedere la scalabilità del prodotto fin dal primo MVP?

Secondo me occorre gettare le basi di un prodotto scalabile fin dalla sua nascita e lavorare ad una migliore scalabilità ad ogni release.

Non occorre partire con la migliore scalabilità possibile, ma nemmeno iniziare con le ruote quadrate: il prodotto deve essere ben scritto, un po’ ottimizzato nei punti critici, essere pensato in un’ottica di scalabilità by design.

Per esercizio tendo a consigliare di fare girare il prodotto iniziale su macchine lente e dotate di poca memoria.

Chiedo che i processi siano sempre consistenti nei dati e nelle connessioni di qualsiasi genere. In modo che essi siano lanciabili parallelamente fin da subito.

Chiedo che i processi utilizzino sempre delle code per essere lanciati in modo che anche un affollarsi di richieste eviti le perdite di messaggi e dati ed anche in caso di numero elevato ogni richiesta giunga sempre a compimento.

Quest’ultima richiesta è dovuta al fatto che un utente può sopportare un lungo tempo di risposta, ma mai una perdita del lavoro.

La scalabilità diventa quindi uno dei processi della scrittura del software, insieme ai test, al codice parlante, alla documentazione.

Spetta a chi cura l’architettura del prodotto indicare la strategia a breve e lungo termine per quanto riguarda la scalabilità: deve essercene una.

Lascia un commento