Considerazioni sulla Scalabilità

Quali sono i vantaggi di un'applicazione in grado di dimensionarsi dinamicamente?

Riduzione dei costi di Infrastruttura IT

Variando il numero delle repliche, variano anche le risorse impiegate da ogni singolo applicativo / microservizio.

Acquistando risorse in base all'effettivo tempo di utilizzo come avviene nei Public Cloud la matematica è piuttosto semplice (repliche per costo al minuto)

Quando invece le risorse sono di proprietà e si parla di Private Cloud o più in generale infrastrutture private, la riduzione dei costi può essere ottenuta attraverso la condivisione.

In generale per dimensionare le risorse necessarie all'esecuzione di un applicativo si prende come riferimento il caso peggiore dove si ipotizza un traffico / carico massimale e si acquistano risorse capaci di gestire quel carico.
Se la stima è stata eseguita correttamente, l'utilizzo effettivo sarà molto inferiore alle capacità acquistate. Un pò come avere una Ferrari per girare in città, al semaforo tutti rimarranno impressionati dall'accelerazione, ma il motore sarà raramente al massimo della potenza.

La virtualizzazione consente di mitigare questo overprovisioning allocando risorse virtuali in quantità superiore a quelle reali.
Questo scenario nei casi comuni prevede un numero di repliche stabili che hanno un effettivo utilizzo di risorse anche quando queste non vengono utilizzate (spazio disco, allocazione ram).

Se l'applicazione invece è in grado di diminuire o aumentare le repliche senza produrre effetti collaterali apprezzabili e quindi di scalare, le risorse nuovamente disponibili possono essere ridistribuite attribuendo delle priorità ai carichi di lavoro: Transazioni OnLine > Analisi Dati > Processi Batch

Business Continuity

Un'applicazione progettata per operare su apparati non affidabili è nativamente in grado di spostare i suoi carichi di lavoro da un centro di calcolo ad un altro.

Se questa applicazione ad esempio viene eseguita in un Hybrid Cloud è facile immaginare che in caso di interruzione del servizio nella parte Private i carichi di lavoro possano essere assorbiti nella parte Public e viceversa.

Attraverso i principali Public Cloud provider è anche possibile distribuire le applicazioni su diverse region (aree geografiche) o all'interno della stessa region su più availability zone (suddivisioni indipendenti delle region inter-connesse con link a bassissima latenza) per ridondanza.

Utilizzando gli accorgimenti architetturali necessari e avvalendosi di questi strumenti è perciò possibile garantire livelli di business continuity molto elevati senza aumentare i costi ( es connettività con SLA elevati, apparati in standby , costi di gestione, etc)

Aggiornamenti e Miglioramenti Infrastrutturali

Le applicazioni non sono statiche e più o meno velocemente aggiungono nuove funzionalità, aumentano la base degli utenti e gli apparati utilizzati per eseguire i carichi di lavoro sono soggetti ad obsolescenza.

L'infrastruttura su cui questi carichi applicativi vengono eseguiti può essere gestita seguendo due principi Pet (animale domestico) o Cattle (Bestiame).

Nell'approccio Pet, le infrastrutture sono gestite in modo diretto ed eventualmente differenziato in relazione ai carichi di lavoro. Questo situazione crea una sorta di legame tra applicazione e server, (es. struttura del filesystem, indirizzi di rete, configurazione dei permessi, servizi di sistema, etc) difficile da spezzare.

In contrapposizione l'approccio Cattle chiede ai carichi di lavoro di astrarre tutte le risorse necessarie. Le applicazioni non possono fare affidamento su un ambiente particolare ma solo su risorse astratte che una qualsiasi infrastruttura può  "implementare" e rendere disponibili ai carichi applicativi.
In pratica si chiede alle applicazioni di considerare le risorse come volatili ed effimere (pezzi di ferro), che in caso di problemi non vengono sistemate ma semplicemente rimpiazzate.

Seguendo questa filosofia, effettuare un aggiornamento infrastrutturale diventa semplice la cancellazione di una replica, nell'attesa che questa venga ricreata in automatico su apparati di nuova generazione.

Performance e Scalabilità

Quando si dimensiona un sistema in base al caso peggiore,  il business spera sempre di sbagliare per difetto.

Il sogno proibito di ogni imprenditore è quello di dover correre ai ripari dopo aver sbagliato una previsione di circa 1.000 utenti paganti a fronte di 100.000 reali.
Anche se questo è quello che potremmo definire come Happy Problem dal punto di vista tecnologico e architetturale potrebbe diventare un vero e proprio incubo.

Adeguare un applicativo progettato o costruito con strumenti non adatti a scalare di ordini di grandezza (es. database relazionali ) può essere una operazione assai ardua, composta da una serie di interventi che possono essere costosi , rischiosi o complicati.

In queste situazioni, le architetture a microservizi si comportano molto bene permettendoci di:

• scalare indipendentemente ciascun servizio (es. il servizio di Ricerca Articoli può essere sicuramente più congestionato di un servizio registrazione utenti )
• aggiungere e rimuovere server per far fronte ad un carico immediatamente (anche senza intervento manuale)  pagandoli al minuto o acquistandoli solo in momenti successivi

Conclusioni

Cloud Computing, Virtualizzazione, Containerizzazione, Progettazione a risorse infinite, etc,  sono strumenti indispensabili per la costruzione di applicazioni performanti, scalabili, localizzate su una singola regione o distribuite su scala mondiale ed utilizzare ( pagando l'effettivo utilizzo) infrastrutture di ultima generazione.

La vita quotidiana ci insegna che possedere uno strumento non ci permette automaticamente di godere di tutti i benefici/servizi che questo può offrire, se non li si utilizza adeguatamente si rischia di avere effetti potenzialmente devastanti.

Utilizzare le tecniche architetturali e le tecnologie pensate per sfruttare al massimo questi strumenti non è banale e richiede una formazione costante.

La scelta, delle -ilities architetturali, di un'approccio a microservizi o monolitico, coreografia o orchestrazione, ACID o consistenza eventuale sono solo alcuni esempi delle domande che ci si dovrebbe porre per sfruttare al meglio gli strumenti a nostra disposizione.

Sono proprio queste scelte frutto delle conoscenza della creatività  che influenzano il successo o l'insuccesso di un progetto, quelle pennellate di un quadro che in altri contesti chiamiamo arte.