Non ho avuto molto a che fare direttamente con questo termine, e presumo che sarebbe facile trovare una definizione da manuale su Google. Ma ho avuto problemi relativi alla scalabilità nel mio lavoro di sviluppo, e quindi fornirò la mia comprensione del termine dalla mia esperienza di programmatore senza aver cercato nulla.
La scalabilità è una considerazione importante per un ingegnere del software che sta progettando o implementando un sistema che probabilmente assumerà un carico molto più pesante di quello che sarà sperimentato in un ambiente di test. Ma mi aspetto che si riferisca in realtà non solo alla capacità di sopportare un carico pesante, ma di riflettere le capacità basate sulle risorse che gli vengono date.
Per esempio, consideriamo un sistema che può permettere ai risultati di ricerca di restituire una lista completa di articoli entro 3 secondi. Una soluzione non scalabile potrebbe richiedere un indirizzo server dedicato esclusivamente all'indicizzazione delle parole chiave degli articoli. Questo non riesce a scalare in una situazione in cui si hanno solo poche centinaia di articoli, ciascuno di poche migliaia di parole. Questo potrebbe facilmente essere mantenuto tutto su un singolo server, e dover creare un server separato per l'indicizzazione sarebbe eccessivo e dispendioso. Un'altra soluzione non scalabile potrebbe cercare sequenzialmente gli articoli con una semplice ricerca testuale ogni volta che viene fatta una richiesta, e non ha modo di dividere il carico di lavoro. Questa soluzione non riesce a scalare in più modi: non fornisce alcun mezzo per sfruttare risorse aggiuntive (dividere il carico di lavoro) e lo fa male non ottimizzando il modo in cui il lavoro viene eseguito quando è coinvolta una grande quantità di dati.
Se avete un miliardo di articoli che non sono indicizzati in qualche modo, la ricerca in sequenza in 3 secondi richiederà molte più risorse di un sistema che mantiene i dati in una forma ottimizzata per la ricerca ripetuta di grandi quantità di dati. Una soluzione scalabile a questo problema userà le risorse in modo ottimale sia per piccole che per grandi quantità di dati, e può fare buon uso di qualsiasi risorsa gli venga data piuttosto che assumere un compito grande o un compito piccolo.
Un esempio di un problema di scalabilità con cui sono stato personalmente coinvolto è quando ho progettato un sistema per elaborare i dati per un sistema ERP in memoria per ottimizzare le prestazioni. C'erano alcuni sistemi in cui erano coinvolte centinaia di migliaia di record e il loro caricamento in memoria funzionava male nel migliore dei casi, e falliva completamente nel peggiore. L'architettura di memoria dei sistemi coinvolti non è stata progettata per utilizzare la memoria a queste scale in questo modo. Un sistema più scalabile avrebbe fatto più affidamento sull'archiviazione persistente e sull'indicizzazione e non avrebbe dato per scontato che così tanto potesse essere caricato nella memoria di lavoro.
Un altro esempio è la ricostruzione di strutture informative di sicurezza per grandi aziende. Abbiamo una procedura per cancellare e ricostruire queste informazioni basate su dati gerarchici che definiscono chi ha accesso a quali parti dell'azienda. L'abbiamo testata su sistemi con poche migliaia di dipendenti in qualche centinaio di filiali. Ma quando è stato eseguito su un sistema con centinaia di migliaia di dipendenti in migliaia di filiali, il processo di ricostruzione si è rivelato richiedere più tempo del necessario, e non c'era modo di assegnare più risorse al compito per completarlo più rapidamente.
Per migliorare la scalabilità della nostra seconda soluzione, stiamo implementando la possibilità di dividere il lavoro su più processori, e studiando soluzioni ottimizzate, che richiedono procedure di test che operano su più dati.
Di solito i problemi di scalabilità si trovano nei fallimenti della scalabilità per gestire carichi di lavoro maggiori. Non sono stato coinvolto in soluzioni che non sono riuscite a scalare verso il basso.