Che cos'è la scalabilità del software e perché la tua azienda dovrebbe prenderla sul serio?

Anche le aziende esperte e di successo possono avere problemi con la scalabilità. Ricordi l'app Applause della Disney? Ha consentito agli utenti di interagire con diversi spettacoli Disney. Quando l'app è apparsa su Google Play, era estremamente popolare. Non così scalabile, però. Non è in grado di gestire un numero elevato di fan, con conseguente scarsa esperienza utente. Le persone erano furiose, lasciando un feedback negativo e una valutazione a una stella su Google Play. L'app non si è mai ripresa da questa pubblicità negativa.

Puoi evitare problemi come questo se presti attenzione alla scalabilità del software durante le prime fasi di sviluppo, sia che tu lo implementi tu stesso o utilizzi servizi di ingegneria del software.

Allora, cos'è la scalabilità nel software? Come assicurarsi che la soluzione sia scalabile? E quando è necessario iniziare il ridimensionamento?

Cos'è la scalabilità del software?

Gartner definisce la scalabilità come la misura della capacità di un sistema di diminuire o aumentare le prestazioni e i costi in risposta ai cambiamenti nelle richieste di elaborazione.

Nel contesto dello sviluppo del software, la scalabilità è la capacità di un'applicazione di gestire la variazione del carico di lavoro aggiungendo o rimuovendo utenti con costi minimi. Pertanto, ci si aspetta che una soluzione scalabile rimanga stabile e mantenga le sue prestazioni dopo un forte aumento del carico di lavoro, previsto o spontaneo. Esempi di aumento del carico di lavoro sono:

• Molti utenti accedono al sistema contemporaneamente
• Espansione dei requisiti di capacità di archiviazione
• Aumento del numero di transazioni in fase di elaborazione

Tipi di scalabilità del software

È possibile ridimensionare un'applicazione orizzontalmente o verticalmente. Vediamo quali sono i vantaggi e gli svantaggi di ciascun approccio.

Scalabilità orizzontale del software (scaling out)

È possibile ridimensionare il software orizzontalmente incorporando nodi aggiuntivi nel sistema per gestire un carico maggiore, poiché verrà distribuito tra le macchine. Ad esempio, se un'applicazione inizia a subire ritardi, puoi ridimensionare aggiungendo un altro server.

La scalabilità orizzontale è una scelta migliore quando non è possibile stimare la quantità di carico che l'applicazione dovrà gestire in futuro. È anche un'opzione ideale per il software che deve scalare rapidamente senza tempi di inattività.

Benefici:

• Resilienza al fallimento. Se un nodo fallisce, gli altri colmeranno il gioco
• Non ci sono periodi di inattività durante il ridimensionamento in quanto non è necessario disattivare i nodi esistenti durante l'aggiunta di nuovi
• Teoricamente, le possibilità di scalare orizzontalmente sono illimitate

Limitazioni:

• Complessità aggiunta. È necessario determinare in che modo il carico di lavoro viene distribuito tra i nodi. Puoi utilizzare Kubernetes per la gestione del carico
• Costi più elevati. L'aggiunta di nuovi nodi costa di più rispetto all'aggiornamento di quelli esistenti
• La velocità complessiva del software potrebbe essere limitata dalla velocità di comunicazione del nodo

Scalabilità software verticale (scaling up)

La scalabilità verticale consiste nell'aggiungere più potenza all'hardware esistente. Se con la scalabilità orizzontale aggiungeresti un altro server per gestire il carico di un'applicazione, qui aggiornerai il server esistente aggiungendo più potenza di elaborazione, memoria, ecc. Un'altra opzione è rimuovere il vecchio server e connetterne uno più avanzato e capace.

Questo tipo di scalabilità funziona bene quando si conosce la quantità di carico aggiuntivo che è necessario incorporare.

Benefici:

• Non è necessario modificare la configurazione o la logica di un'applicazione per adattarsi all'infrastruttura aggiornata
• Costi inferiori, in quanto costa meno aggiornare che aggiungere un'altra macchina

Limitazioni:

• Ci sono tempi di inattività durante il processo di aggiornamento
• La macchina aggiornata presenta ancora un singolo punto di errore
• C'è un limite su quanto puoi aggiornare un dispositivo

Scalabilità verticale vs. orizzontale del software

Ecco una tabella di confronto che offre una panoramica dei diversi aspetti di entrambi i tipi di scalabilità del software.

Quando hai assolutamente bisogno di scalabilità?

Molte aziende mettono da parte la scalabilità nell'ingegneria del software a favore di costi inferiori e cicli di vita di sviluppo del software più brevi. E anche se ci sono alcuni casi in cui la scalabilità non è un attributo essenziale della qualità del sistema, nella maggior parte dei casi è necessario considerarla fin dalle prime fasi del ciclo di vita del prodotto.

Quando la scalabilità del software non è necessaria:

• Se il software è una prova di concetto (PoC) o un prototipo
• Quando si sviluppa software interno per piccole aziende utilizzato solo dai dipendenti
• App mobile/desktop senza back-end

Per il resto, si consiglia vivamente di esaminare le opzioni di scalabilità per essere pronti quando sarà il momento. E come fai a sapere che è il momento di scalare? Quando noti un calo delle prestazioni. Ecco alcune indicazioni:

• Il tempo di risposta dell'applicazione aumenta
• Impossibilità di gestire le richieste degli utenti simultanei
• Aumento dei tassi di errore, come errori di connessione e timeout
• I colli di bottiglia si stanno formando frequentemente. Non puoi accedere al database, l'autenticazione fallisce, ecc.

Suggerimenti per la creazione di software altamente scalabile

La scalabilità del software è molto più economica e più facile da implementare se considerata all'inizio dello sviluppo del software. Se devi ridimensionare in modo imprevisto senza eseguire i passaggi necessari durante l'implementazione, il processo consumerà molto più tempo e risorse. Uno di questi approcci consiste nel refactoring del codice, che è uno sforzo duplicato, poiché non aggiunge nuove funzionalità. Fa semplicemente ciò che avrebbe dovuto essere fatto durante lo sviluppo.

Di seguito puoi trovare otto suggerimenti che ti aiuteranno a creare software più facile da scalare in futuro. La tabella seguente suddivide i suggerimenti in diverse fasi di sviluppo del software.

Suggerimento n. 1: scegli l'hosting nel cloud per una migliore scalabilità del software

Hai due opzioni per ospitare le tue applicazioni, nel cloud o in locale. Oppure puoi utilizzare un approccio ibrido.

Se opti per il modello on-premise , farai affidamento sulla tua infrastruttura per eseguire le applicazioni, gestire l'archiviazione dei dati, ecc. Questa configurazione limiterà la tua capacità di ridimensionamento e la renderà più costosa. Tuttavia, se operi in un settore fortemente regolamentato, potresti non avere scelta, poiché l'hosting on-premise ti offre un maggiore controllo sui dati.

Inoltre, in alcuni settori, come quello bancario, il tempo di gestione delle transazioni è essenziale e non puoi permetterti di aspettare che il cloud risponda o tollerare eventuali tempi di inattività dei fornitori di servizi cloud. Le aziende che operano in questi settori sono limitate all'utilizzo di hardware specifico e non possono fare affidamento su qualsiasi offerta dei fornitori di servizi cloud. Lo stesso vale per le applicazioni mission-critical sensibili al tempo, come i veicoli automatizzati.

Scegliere i servizi di cloud computing ti darà la possibilità di accedere a risorse di terze parti invece di utilizzare la tua infrastruttura. Con il cloud, hai una possibilità quasi illimitata di scalare su e giù senza dover investire in server e altro hardware. I fornitori di servizi cloud sono anche responsabili della manutenzione e della protezione dell'infrastruttura.

Se lavori nel settore sanitario, puoi consultare il nostro articolo sul cloud computing nel settore medico.

Suggerimento n. 2: utilizzare il bilanciamento del carico

Se decidi di ridimensionare orizzontalmente, dovrai distribuire un software di bilanciamento del carico per distribuire le richieste in arrivo tra tutti i dispositivi in ​​grado di gestirle e assicurarti che nessun server sia sovraccarico. Se un server non funziona, un sistema di bilanciamento del carico reindirizzerà il traffico del server verso altre macchine online in grado di gestire queste richieste.

Quando un nuovo nodo viene connesso, diventerà automaticamente parte della configurazione e inizierà anche a ricevere richieste.

Suggerimento n. 3: memorizza nella cache il più possibile

La cache viene utilizzata per archiviare contenuti statici e risultati precalcolati a cui gli utenti possono accedere senza dover ripetere i calcoli.

Memorizza nella cache quanti più dati possibile per alleggerire il carico dal tuo database. Configura la tua logica di elaborazione in modo tale che i dati che vengono raramente modificati ma letti piuttosto spesso possano essere recuperati da una cache distribuita. Questo sarà più veloce e meno costoso rispetto all'interrogazione del database con ogni semplice richiesta. Inoltre, quando qualcosa non è nella cache ma vi si accede spesso, l'applicazione lo recupererà e memorizzerà nella cache i risultati.

Ciò comporta problemi, ad esempio, quanto spesso dovresti invalidare la cache, quante volte è necessario accedere a un pezzo di dati per essere copiato nella cache, ecc.

Suggerimento n. 4: abilita l'accesso tramite API

Gli utenti finali accederanno al tuo software tramite una varietà di client e sarà più conveniente offrire un'interfaccia di programmazione dell'applicazione (API) che tutti possono utilizzare per connettersi. Un'API è come un intermediario che consente a due applicazioni di parlare. Assicurati di tenere conto di diversi tipi di client, inclusi smartphone, app desktop, ecc.

Tieni presente che le API possono esporti a vulnerabilità di sicurezza. Cerca di risolvere questo problema prima che sia troppo tardi. Puoi utilizzare gateway sicuri, autenticazione avanzata, metodi di crittografia e altro ancora.

Suggerimento n. 5: trarre vantaggio dall'elaborazione asincrona

Un processo asincrono è un processo che può eseguire attività in background. Il cliente non ha bisogno di aspettare i risultati e può iniziare a lavorare su qualcos'altro. Questa tecnica consente la scalabilità del software poiché consente alle applicazioni di eseguire più thread, consentendo ai nodi di essere più scalabili e gestire più carico. E se arriva un'attività che richiede tempo, non bloccherà la minaccia di esecuzione e l'applicazione sarà comunque in grado di gestire altre attività contemporaneamente.

L'elaborazione asincrona riguarda anche la suddivisione dei processi in fasi quando non è necessario attendere il completamento di una fase prima di avviare quella successiva se ciò non è fondamentale per il sistema. Questa configurazione consente di distribuire un processo su più thread di esecuzione, il che facilita anche la scalabilità.

L'elaborazione asincrona viene ottenuta a livello di codice e infrastruttura, mentre la gestione asincrona delle richieste è a livello di codice.

Suggerimento n. 6: optare per tipi di database più facili da scalare, quando possibile

Alcuni database sono più facili da scalare rispetto ad altri. Ad esempio, i database NoSQL, come MongoDB, sono più scalabili di SQL. Il suddetto MongoDB è open source ed è tipicamente utilizzato per l'analisi di big data in tempo reale. Altre opzioni NoSQL sono Amazon DynamoDB e Google Bigtable.

SQL funziona bene quando si tratta di ridimensionare le operazioni di lettura, ma si blocca sulle operazioni di scrittura a causa della sua conformità ai principi ACID (atomicità, coerenza, isolamento e durabilità). Quindi, se questi principi non sono la preoccupazione principale, puoi optare per NoSQL per un ridimensionamento più semplice. Se devi fare affidamento su database relazionali, per coerenza o per qualsiasi altra questione, è comunque possibile ridimensionare utilizzando lo sharding e altre tecniche.

Suggerimento n. 7: scegli i microservizi rispetto all'architettura monolitica, se applicabile

Architettura monolitica

Il software monolitico è costruito come una singola unità che combina operazioni lato client e lato server, un database, ecc. Tutto è strettamente accoppiato e ha un'unica base di codice per tutte le sue funzionalità. Non puoi semplicemente aggiornare una parte senza influire sul resto dell'applicazione.

È possibile ridimensionare il software monolite, ma deve essere ridimensionato in modo olistico utilizzando l'approccio di ridimensionamento verticale, che è costoso e inefficiente. Se si desidera aggiornare una parte specifica, non c'è scampo dalla ricostruzione e dalla ridistribuzione dell'intera applicazione. Quindi, opta per un monolitico se la tua soluzione non è complessa e sarà utilizzata solo da un numero limitato di persone.

Architettura dei microservizi

I microservizi sono più flessibili dei monoliti. Le applicazioni progettate in questo stile sono costituite da molti componenti che funzionano insieme ma vengono distribuiti in modo indipendente. Ogni componente offre una funzionalità specifica. I servizi che costituiscono un'applicazione possono avere diversi stack tecnologici e accedere a diversi database. Ad esempio, un'app di e-commerce creata come microservizi avrà un servizio per la ricerca di prodotti, un altro per i profili utente, un altro ancora per la gestione degli ordini e così via.

I componenti dell'applicazione di microservizi possono essere ridimensionati in modo indipendente senza gravare sull'intero software. Quindi, se stai cercando una soluzione scalabile, i microservizi sono il tuo progetto di riferimento. L'elevata scalabilità del software è solo uno dei tanti vantaggi che puoi ottenere da questa architettura. Per ulteriori informazioni, consulta il nostro articolo sui vantaggi dei microservizi.

Suggerimento n. 8: monitora le prestazioni per determinare quando ridimensionare

Dopo la distribuzione, puoi monitorare il tuo software per rilevare i primi segnali di degrado delle prestazioni che possono essere risolti mediante il ridimensionamento. Questo ti dà l'opportunità di reagire prima che il problema si aggravi. Ad esempio, quando noti che la memoria si sta esaurendo o che i messaggi sono in attesa di essere elaborati più a lungo del limite specificato, questa è un'indicazione che il tuo software sta funzionando al massimo della sua capacità.

Per essere in grado di identificare questi e altri problemi relativi alla scalabilità del software, è necessario incorporare un sistema di monitoraggio della telemetria nell'applicazione durante la fase di codifica. Questo sistema ti consentirà di monitorare:

• Tempo medio di risposta
• Throughput, ovvero il numero di richieste elaborate in un dato momento
• Il numero di utenti simultanei
• Metriche delle prestazioni del database, come il tempo di risposta alle query
• Utilizzo delle risorse, come CPU, utilizzo della memoria, GPU
• Tassi di errore
• Costo per utente

Puoi trarre vantaggio dalle soluzioni di monitoraggio esistenti e dai framework di aggregazione dei log, come Splunk. Se il tuo software è in esecuzione nel cloud, puoi utilizzare la soluzione del fornitore del cloud. Ad esempio, Amazon offre AWS CloudWatch per questo scopo.

Esempi di soluzioni software scalabili dal portafoglio ITRex

Specchio fitness intelligente con un allenatore personale

Descrizione del progetto

Il cliente voleva costruire uno specchio per il fitness a parete a figura intera che aiutasse gli utenti nella loro routine di allenamento. Potrebbe monitorare la forma dell'utente durante l'esercizio, contare le ripetizioni e altro ancora. Questo sistema avrebbe dovuto includere un software che consentisse agli allenatori di creare e caricare video e agli utenti di registrare e gestire i propri allenamenti.

Cosa abbiamo fatto per garantire la scalabilità del software

• Abbiamo optato per l'architettura a microservizi
• Scalabilità orizzontale implementata per la distribuzione del carico. Un nuovo nodo veniva aggiunto ogni volta che c'era troppo carico su quelli esistenti. Pertanto, ogni volta che l'utilizzo della CPU superava il 90% della sua capacità e rimaneva lì per un periodo di tempo specificato, veniva aggiunto un nuovo nodo per alleggerire il carico.
• Abbiamo dovuto implementare database relazionali, ad esempio SQL e PostgreSQL, per motivi di architettura. Anche se i database relazionali sono più difficili da scalare, ci sono ancora diverse opzioni. All'inizio, poiché la base di utenti era ancora relativamente piccola, abbiamo optato per il ridimensionamento verticale. Se il pubblico cresceva, avevamo in programma di implementare l'approccio master-slave, distribuendo i dati su diversi database.
• Ha ampiamente beneficiato della memorizzazione nella cache poiché questo sistema contiene molte informazioni statiche, come i nomi degli allenatori, i titoli degli allenamenti, ecc.
• Usato RestAPI per l'elaborazione asincrona delle richieste tra l'app di allenamento e il server
• Basato su un'architettura serverless, come AWS Lambda, per altri tipi di elaborazione asincrona. Un esempio è l'elaborazione video asincrona. Dopo che un trainer ha caricato un nuovo video di allenamento e lo ha segmentato in diversi esercizi, preme "salva" e il server avvia l'elaborazione di questo video per lo streaming live HTTP per creare quattro versioni del video originale con risoluzioni diverse. Il formatore può caricare nuovi video contemporaneamente.
• In un altro esempio, il sistema esegue in modo asincrono il ritaglio intelligente sui video degli utenti per rimuovere eventuali parti in cui l'utente era inattivo.

Sistema di sicurezza informatica basato sulla biometria

Descrizione del progetto

Il cliente desiderava creare una piattaforma di sicurezza informatica che consentisse alle aziende di autenticare dipendenti, appaltatori e altri utenti in base alla biometria e di evitare password e PIN. Questa piattaforma conterrebbe anche uno strumento video live per confermare in remoto l'identità dell'utente.

Come ci siamo assicurati che questo software fosse scalabile

• Abbiamo utilizzato un'architettura di microservizi decentralizzata
• Distribuito tre sistemi di bilanciamento del carico per distribuire il carico tra diversi microservizi
• Alcune parti di questa piattaforma erano autoscalabili in base alla progettazione. Se il carico superava una determinata soglia, veniva creata automaticamente una nuova istanza di un microservizio
• Abbiamo utilizzato sei diversi database: quattro PostgreSQL e due MongoDB. I database PostgreSQL sono stati ridimensionati verticalmente quando necessario. Durante la progettazione dell'architettura, ci siamo resi conto che alcuni dei database avrebbero dovuto essere ridimensionati piuttosto spesso, quindi abbiamo adottato MongoDB a tale scopo, poiché sono più facili da ridimensionare orizzontalmente.
• Elaborazione asincrona distribuita per una migliore esperienza utente. Ad esempio, la post-elaborazione video è stata eseguita in modo asincrono.
• Abbiamo optato per l'algoritmo di riconoscimento facciale di un fornitore di servizi di terze parti. Quindi, ci siamo assicurati di selezionare una soluzione che fosse già scalabile e l'abbiamo incorporata nella nostra piattaforma tramite un'API.

Sfide che potresti incontrare durante il ridimensionamento

Se intendi pianificare la scalabilità del software durante lo sviluppo dell'applicazione e desideri incorporare i suggerimenti di cui sopra, puoi comunque affrontare le seguenti sfide:

• Debito tecnico accumulato . Le parti interessate del progetto potrebbero ancora tentare di mettere da parte la scalabilità a favore di costi inferiori, velocità, ecc. La scalabilità non è un requisito funzionale e può essere messa in ombra da caratteristiche più tangibili. Di conseguenza, l'applicazione accumulerà caratteristiche tecniche che non saranno compatibili con la scalabilità.
• Scaling con metodologia di sviluppo Agile . La metodologia Agile consiste nell'accogliere il cambiamento. Tuttavia, quando il cliente desidera implementare troppe modifiche troppo spesso, la scalabilità del software può essere messa da parte per soddisfare le mutevoli esigenze.
• Test di scalabilità . È difficile eseguire test di carico realistici. Supponiamo che tu voglia testare come si comporterà il sistema se aumenti la dimensione del database di 10 volte. Dovrai generare una grande quantità di dati realistici, che corrispondano alle caratteristiche dei dati originali, quindi generare un carico di lavoro realistico sia per le scritture che per le letture.
• Scalabilità dei servizi di terze parti . Assicurati che il tuo fornitore di servizi di terze parti non limiti la scalabilità. Quando si seleziona un fornitore di tecnologia, verificare che sia in grado di supportare il livello previsto di scalabilità del software e integrare correttamente la propria soluzione.
• Comprensione dell'utilizzo dell'applicazione . Devi avere una visione solida di come funzionerà il tuo software e di quante persone lo useranno, cosa che raramente è possibile stimare con precisione.
• Restrizioni architettoniche . A volte sei limitato nelle tue scelte architettoniche. Ad esempio, potresti dover utilizzare un database relazionale e dovrai occuparti del ridimensionamento sia in orizzontale che in verticale.
• Avere il talento giusto . Per progettare una soluzione scalabile che non ti darà mal di testa in futuro, hai bisogno di un architetto esperto che abbia già lavorato su progetti simili e che comprenda la scalabilità del software sia dal punto di vista della codifica che dell'infrastruttura. Qui a ITRex Group, abbiamo lavorato a molti progetti e teniamo sempre presente la scalabilità durante lo sviluppo del software.

Per riassumere

A meno che tu non sia assolutamente certo che non sarà necessario ridimensionare, considera la scalabilità del software nelle prime fasi di sviluppo e prendi le precauzioni necessarie. Anche se sei limitato nelle tue scelte architetturali e non puoi sempre implementare l'opzione più scalabile, saprai comunque dove sono gli ostacoli e avrai tempo per considerare le alternative.

Tralasciare la scalabilità per il bene di altri requisiti funzionali si ritorcerà contro. Innanzitutto, l'azienda dovrà lottare con il degrado delle prestazioni. Ci vorrà troppo tempo per elaborare le richieste. Gli utenti sperimenteranno ritardi inaccettabili. Dopo tutto questo, la società ridimensionerà pagando il doppio e il triplo dell'importo che avrebbe potuto essere speso nelle fasi precedenti.

Stai pensando di implementare un nuovo software aziendale o di aggiornare un sistema esistente, ma temi che non riesca a tenere il passo con le esigenze aziendali in rapida espansione? Contattaci! Faremo in modo che il tuo software non solo abbia tutte le funzionalità richieste, ma possa anche essere ridimensionato con investimenti e tempi di inattività minimi.

Originariamente pubblicato su https://itrexgroup.com il 24 luglio 2023.