La scalabilità è una componente essenziale del software aziendale. Dare la priorità ad essa fin dall’inizio porta a costi di manutenzione più bassi, una migliore esperienza dell’utente e una maggiore agilità.

Il design del software è un atto di bilanciamento in cui gli sviluppatori lavorano per creare il miglior prodotto entro i limiti di tempo e di budget del cliente.

Non si può evitare la necessità del compromesso. I compromessi devono essere fatti per soddisfare i requisiti di un progetto, che siano tecnici o finanziari.

Troppo spesso, però, le aziende danno la priorità ai costi rispetto alla scalabilità o addirittura ignorano del tutto la sua importanza. Questo è purtroppo comune nelle iniziative di big data, dove i problemi di scalabilità possono affondare un progetto promettente.

La scalabilità non è una “caratteristica bonus”. È la qualità che determina il valore di vita del software, e costruire pensando alla scalabilità permette di risparmiare tempo e denaro nel lungo periodo.

Cos’è la scalabilità?

Un sistema è considerato scalabile quando non ha bisogno di essere riprogettato per mantenere prestazioni efficaci durante o dopo un forte aumento del carico di lavoro.

Il “carico di lavoro” potrebbe riferirsi agli utenti simultanei, alla capacità di memorizzazione, al numero massimo di transazioni gestite, o a qualsiasi altra cosa che spinge il sistema oltre la sua capacità originale.

La scalabilità non è un requisito fondamentale di un programma, in quanto un software non scalabile può funzionare bene con una capacità limitata.

Tuttavia, riflette la capacità del software di crescere o cambiare con le richieste dell’utente.

Qualsiasi software che può espandersi oltre le sue funzioni di base – specialmente se il modello di business dipende dalla sua crescita – dovrebbe essere configurato per la scalabilità.

I benefici del software scalabile

La scalabilità ha benefici sia a lungo che a breve termine.

All’inizio permette a un’azienda di acquistare solo ciò di cui ha bisogno immediatamente, non tutte le caratteristiche che potrebbero essere utili in seguito.

Per esempio, un’azienda che lancia un programma pilota di data intelligence potrebbe scegliere un pacchetto di analisi aziendale massiccio, o potrebbe iniziare con una soluzione che gestisce solo le funzioni di cui ha bisogno all’inizio.

Una scelta popolare è un cruscotto che estrae i risultati dalle loro fonti di dati primarie e dal software aziendale esistente.

Quando crescono abbastanza da utilizzare più programmi di analisi, questi flussi di dati possono essere aggiunti al dashboard invece di costringere l’azienda a destreggiarsi tra più programmi di visualizzazione o a costruire un sistema completamente nuovo.

Costruendo in questo modo ci si prepara alla crescita futura, creando un prodotto più snello che si adatta alle esigenze attuali senza ulteriore complessità.

Richiede anche un minore esborso finanziario iniziale, che è una considerazione importante per i dirigenti preoccupati per le dimensioni degli investimenti in big data.

La scalabilità lascia anche spazio al cambiamento delle priorità. Quel pacchetto di analisi off-the-shelf potrebbe perdere rilevanza quando un’azienda si sposta per soddisfare le richieste di un mercato in evoluzione.

Scegliere soluzioni scalabili protegge l’investimento tecnologico iniziale. Le aziende possono continuare a usare lo stesso software più a lungo perché è stato progettato per crescere insieme a loro.

Quando arriva il momento di cambiare, costruire su un software solido e scalabile è considerevolmente meno costoso che cercare di adattare programmi meno agili.

C’è anche un tempo più breve di “ramp up” per portare nuove funzionalità online che per implementare un software completamente nuovo.

Come vantaggio collaterale, il personale non avrà bisogno di molta formazione o persuasione per adottare quel sistema aggiornato. Hanno già familiarità con l’interfaccia, quindi lavorare con le caratteristiche aggiuntive è visto come un bonus piuttosto che un lavoro di routine.

Le conseguenze dei fallimenti della scalabilità

Quindi, cosa succede quando il software non è scalabile?

In principio, la debolezza è difficile da individuare. Il carico di lavoro è leggero nelle prime fasi di un’applicazione. Con relativamente pochi utenti simultanei non c’è molta richiesta sull’architettura.

Quando il carico di lavoro aumenta, sorgono i problemi. Più dati immagazzinati o utenti simultanei il software raccoglie, più sforzo viene messo sull’architettura del software.

Limitazioni che non sembravano importanti all’inizio diventano una barriera alla produttività. Le patch possono alleviare alcuni dei problemi iniziali, ma le patch aggiungono complessità.

La complessità rende la diagnosi dei problemi su base continuativa più noiosa (traduzione: più costosa e meno efficace).

Come il carico di lavoro aumenta oltre la capacità di scala del software, le prestazioni diminuiscono.

Gli utenti sperimentano tempi di caricamento lenti perché il server impiega troppo tempo per rispondere alle richieste. Altri potenziali problemi includono la diminuzione della disponibilità o persino la perdita di dati.

Tutto questo scoraggia l’uso futuro. I dipendenti troveranno dei workaround per un software inaffidabile al fine di portare a termine il proprio lavoro.

Questo mette l’azienda a rischio di una violazione dei dati o peggio.

Quando il software è rivolto ai clienti, l’inaffidabilità aumenta il potenziale di abbandono.

Google ha scoperto che il 61% degli utenti non darà una seconda possibilità a un’app se hanno avuto una brutta prima esperienza. Il 40% passa invece direttamente al prodotto di un concorrente.

I problemi di scalabilità non sono solo un errore da principianti fatto dalle piccole aziende. Anche la Disney ha avuto problemi con il lancio originale della sua app Applause, che aveva lo scopo di dare agli spettatori un modo in più per interagire con gli spettacoli Disney preferiti. L’app non poteva gestire la marea di utenti di streaming video simultanei.

I fan frustrati hanno lasciato recensioni negative fino a quando l’app aveva una sola stella nel negozio Google Play. I funzionari della Disney hanno dovuto togliere l’app per riparare il danno, e la pubblicità negativa è stata così intensa che non è più tornata online.

Fissare le priorità

Alcune aziende non riescono a dare priorità alla scalabilità perché non ne vedono l’utilità immediata.

La scalabilità viene messa da parte in favore della velocità, dei cicli di sviluppo più brevi o dei costi inferiori.

Ci sono effettivamente alcuni casi in cui la scalabilità non è una priorità principale.

Il software destinato ad essere un prototipo o una prova di concetto a basso volume non diventerà abbastanza grande da causare problemi.

Parimenti, il software interno per piccole aziende con un basso limite fisso di potenziali utenti può stabilire altre priorità.

Infine, quando la conformità ACID è assolutamente obbligatoria la scalabilità passa in secondo piano rispetto all’affidabilità.

Come regola generale, però, la scalabilità è più facile e meno dispendiosa in termini di risorse se considerata fin dall’inizio.

Per prima cosa, la scelta del database ha un enorme impatto sulla scalabilità. La migrazione a un nuovo database è costosa e richiede tempo. Non è qualcosa che può essere fatto facilmente in seguito.

Principi di scalabilità

Diversi fattori influenzano la scalabilità generale del software:

Usage

Usage misura il numero di utenti simultanei o connessioni possibili. Non ci dovrebbero essere limiti artificiali all’utilizzo.

Aumentarlo dovrebbe essere semplice come mettere più risorse a disposizione del software.

Massimo di dati immagazzinati

Questo è particolarmente rilevante per i siti con molti dati non strutturati: contenuti caricati dagli utenti, rapporti sul sito e alcuni tipi di dati di marketing.

Anche i progetti di scienza dei dati rientrano in questa categoria. La quantità di dati memorizzati da questi tipi di contenuti potrebbe aumentare drammaticamente e inaspettatamente.

Se i dati massimi memorizzati possono scalare rapidamente dipende molto dallo stile del database (server SQL vs NoSQL), ma è anche fondamentale prestare attenzione alla corretta indicizzazione.

Codice

Gli sviluppatori inesperti tendono a trascurare le considerazioni sul codice quando pianificano la scalabilità.

Il codice dovrebbe essere scritto in modo da poter essere aggiunto o modificato senza rifattorizzare il vecchio codice. I buoni sviluppatori mirano ad evitare la duplicazione degli sforzi, riducendo la dimensione complessiva e la complessità della base di codice.

Le applicazioni crescono in dimensione quando si evolvono, ma mantenere il codice pulito minimizzerà l’effetto e preverrà la formazione di “codice spaghetti”.

Scaling Out Vs Scaling Up

Scaling up (o “vertical scaling”) comporta la crescita utilizzando hardware più avanzato o più forte. Lo spazio su disco o un’unità di elaborazione centrale (CPU) più veloce vengono utilizzati per gestire l’aumento del carico di lavoro.

Scaling up offre prestazioni migliori dello scaling out. Tutto è contenuto in un posto, consentendo ritorni più veloci e meno vulnerabilità.

Il problema con lo scaling up è che c’è solo tanto spazio per crescere. L’hardware diventa più costoso man mano che diventa più avanzato. Ad un certo punto, le aziende si scontrano con la legge dei rendimenti decrescenti nell’acquisto di sistemi avanzati.

Ci vuole anche tempo per implementare il nuovo hardware.

A causa di queste limitazioni, lo scaling verticale non è la soluzione migliore per il software che deve crescere rapidamente e con poco preavviso.

Lo scaling out (o “scaling orizzontale”) è molto più usato per scopi aziendali.

Quando si fa lo scaling out, il software cresce usando più hardware – non più avanzato – e distribuendo il maggior carico di lavoro sulla nuova infrastruttura.

I costi sono più bassi perché i server o le CPU extra possono essere dello stesso tipo usato attualmente (o di qualsiasi tipo compatibile).

Lo scaling avviene anche più velocemente, poiché nulla deve essere importato o ricostruito.

C’è un leggero compromesso nella velocità, comunque. Il software scalato orizzontalmente è limitato dalla velocità con cui i server possono comunicare.

La differenza non è abbastanza grande da essere notata dalla maggior parte degli utenti, comunque, e ci sono strumenti per aiutare gli sviluppatori a minimizzare l’effetto. Di conseguenza, lo scaling out è considerato una soluzione migliore quando si costruiscono applicazioni scalabili.

Guidelines for Building Highly Scalable Systems

È sia più economico che più facile considerare la scalabilità durante la fase di pianificazione. Ecco alcune buone pratiche per incorporare la scalabilità fin dall’inizio:

Utilizzare software di bilanciamento del carico

Il software di bilanciamento del carico è fondamentale per i sistemi con infrastruttura distribuita (come le applicazioni a scala orizzontale).

Questo software usa un algoritmo per distribuire il carico di lavoro tra i server per assicurare che nessun singolo server venga sopraffatto. È una necessità assoluta per evitare problemi di prestazioni.

Il posizionamento conta

Il software scalabile fa il più possibile vicino al client (nel livello dell’applicazione). Ridurre il numero di volte in cui le applicazioni devono navigare il traffico più pesante vicino alle risorse di base porta a velocità più elevate e meno stress sui server.

L’edge computing è un’altra cosa da considerare. Con un maggior numero di applicazioni che richiedono risorse intensive, mantenere quanto più lavoro possibile sul dispositivo riduce l’impatto delle aree a basso segnale e dei ritardi di rete.

Cache dove possibile

Siate consapevoli dei problemi di sicurezza, ma la cache è un buon modo per evitare di dover eseguire lo stesso compito più e più volte.

Condurre con API

Gli utenti si connettono attraverso una varietà di client, quindi condurre con API che non presuppongono un tipo di client specifico può servire tutti.

Elaborazione asincrona

Si riferisce a processi che sono separati in passi discreti che non hanno bisogno di aspettare che il precedente sia completato prima dell’elaborazione.

Per esempio, ad un utente può essere mostrata una notifica “inviata!”

L’elaborazione asincrona rimuove alcuni dei colli di bottiglia che influenzano le prestazioni del software su larga scala.

Limitare l’accesso concorrente a risorse limitate

Non duplicare gli sforzi. Se più di una richiesta richiede lo stesso calcolo dalla stessa risorsa, lasciate che la prima finisca e usate solo quel risultato. Questo aggiunge velocità mentre riduce lo sforzo sul sistema.

Utilizza un database scalabile

I database NoSQL tendono ad essere più scalabili di SQL. SQL scala abbastanza bene le operazioni di lettura, ma quando si tratta di operazioni di scrittura entra in conflitto con le restrizioni intese a far rispettare i principi ACID.

Scalare NoSQL richiede un’aderenza meno rigorosa a questi principi, quindi se la conformità ACID non è una preoccupazione un database NoSQL può essere la scelta giusta.

Considera le soluzioni PaaS

La Platform-as-a-service allevia molti problemi di scalabilità poiché il fornitore PaaS gestisce lo scaling. Scalare può essere facile come aggiornare il livello di abbonamento.

Guarda FaaS

Function-as-a-service si è evoluto da PaaS ed è strettamente collegato. Il serverless computing fornisce un modo per utilizzare solo le funzioni che sono necessarie in qualsiasi momento, riducendo le richieste inutili sull’infrastruttura back-end.

FaaS è ancora in fase di maturazione, ma potrebbe valere la pena considerarlo come un modo per tagliare i costi operativi migliorando la scalabilità.

Non dimenticare la manutenzione

Imposta il software per i test automatici e la manutenzione in modo che quando cresce, il lavoro di manutenzione non sfugga di mano.

Costruisci con un occhio al futuro

Privilegiare la scalabilità prepara il tuo business al successo. Consideralo in anticipo e raccoglierai i benefici dell’agilità quando è più necessario.

Stai cercando un software che possa crescere con la tua azienda? Fissa un appuntamento gratuito con uno dei nostri sviluppatori per parlare di dove hai bisogno di andare e di come possiamo portartici!