Preparare la crescita
Si conoscerà probabilmente il detto la preparazione è la chiave del successo. Questo detto è particolarmente vero in relazione a una crescita costante, continua e affidabile.
Uno dei principali vantaggi del cloud computing è la scalabilità. Questa capacità ha portato qualcuno a pensare erroneamente che non sia necessario preparare o pianificare la crescita nel cloud in virtù della scalabilità infinita che lo contraddistingue.
È certamente vero che nel cloud siano presenti risorse più che sufficienti per soddisfare le esigenze dell'applicazione. Esistono tuttavia alcuni motivi per cui è ancora importante comprendere le esigenze di capacità:
Anche se nel cloud sono probabilmente disponibili risorse sufficienti per soddisfare le proprie esigenze, non tutti i servizi utilizzati vengono dimensionati automaticamente o sono intrinsecamente scalabili. È quindi necessario conoscere i limiti del servizio e sapere quando è opportuno aumentare i servizi e le risorse.
Anche se le risorse cloud sono illimitate, il budget probabilmente non lo è. È necessario considerare i costi per poter comunicare ai colleghi del reparto finanziario la spesa per il cloud prevista.
Pianificare la crescita organica
In ambito aziendale per crescita organica si intende il processo in base al quale le organizzazioni espandono la propria capacità, basandosi su risorse e competenze intrinseche per favorire una crescita più lenta e più naturale.
La prima operazione da fare quando si intende pianificare la capacità nel cloud in base alla crescita organica dell'azienda consiste nel definire i requisiti correnti in termini di risorse per i componenti più importanti dell'applicazione.
Scenario: Crescita organica
Torniamo all'architettura esaminata all'inizio di questo modulo. Tailwind Traders sta per lanciare un prodotto innovativo e prevede, di conseguenza, una crescita significativa. Solo a titolo di promemoria, ecco il diagramma dell'architettura di Tailwind Traders.
Per iniziare la pianificazione della capacità, è necessario identificare i componenti più importanti. In questo esempio che include:
- Cluster del servizio Azure Kubernetes
- App Rewards in esecuzione in Servizio app di Azure
- Diversi database, ad esempio Cosmos DB, SQL di Azure e così via.
Per ognuno di questi componenti, è necessario conoscere l'utilizzo corrente delle risorse per poter pianificare l'utilizzo futuro. Verranno ora illustrati l'utilizzo delle risorse per uno di questi componenti di grandi dimensioni.
Misurare la capacità in Cosmos DB
In Cosmos DB lo spazio di archiviazione viene misurato in gigabyte ed è scalabile automaticamente, anche se è comunque opportuno conoscere i dati relativi all'utilizzo per motivi di costo.
La velocità effettiva è soggetta a provisioning preliminare e per misurarla si usa una metrica denominata Unità richiesta. Le unità richiesta (UR) sono una combinazione di memoria, CPU e operazioni di I/O al secondo che offre una singola metrica in base alla quale è possibile pianificare la capacità. Il provisioning delle UR avviene a incrementi di 100 UR al secondo.
Ogni operazione di database viene misurata in UR/s. Le operazioni di lettura sono semplici: ogni KB letto corrisponde a una singola unità richiesta. Le altre operazioni vengono calcolate in base a diversi fattori, ad esempio le dimensioni degli elementi, la coerenza dei dati, i modelli di query e così via.
Quando si crea il profilo dell'applicazione, ogni risposta restituita da Cosmos DB contiene l'intestazione dell'addebito della richiesta, che indica esattamente il numero di UR usate dalla richiesta. È possibile confrontare il numero di UR usate con il numero per cui è stato effettuato il provisioning per verificare se la capacità corrente è più che sufficiente.
È opportuno correlare l'utilizzo delle risorse a una metrica aziendale, ad esempio gli utenti attivi mensili o i ricavi. Questa correlazione consente di pianificare la capacità in base alla previsione di crescita aziendale. È possibile recuperare queste metriche di capacità in Monitoraggio di Azure. Conoscere l'utilizzo delle risorse del sistema consente di sapere quando sarà necessario aumentarne il numero e quali saranno i costi nel tempo.
Verrà ora illustrato un esempio concreto, con l'esame dei dati relativi all'utilizzo di Cosmos DB in Tailwind Traders. Ecco un grafico dell'utilizzo.
In questo esempio Tailwind Traders cresce a una media di 2.500 utenti attivi mensili con una base utente corrente di 10.000 utenti.
Se si guarda lo spazio di archiviazione, si può notare che il database usa 300 GB dei 5 TB disponibili (6%). Cresce quindi dell'1% o di 50 GB al mese.
In termini di velocità effettiva, questa si attesta su 300/1000 e cresce a una percentuale del 10% al mese:
Conoscere le metriche relative alle risorse del sistema consente di sapere quando con buona probabilità diventa necessario dimensionare la velocità effettiva e anche quali saranno i costi nel tempo.
È ora possibile creare un grafico utile per la pianificazione della capacità.
A questo punto si sa che a maggio si raggiungerà la capacità delle UR nel database, quindi sarà necessario ridimensionare prima di allora. Un altro aspetto interessante è che potrebbe essere addirittura necessario ridurre le risorse del database Cosmos DB in questo momento perché la capacità di cui è stato effettuato il provisioning non viene quasi usata.
Pianificare la crescita inorganica
Nell'esempio precedente abbiamo pianificato la crescita organica. La crescita inorganica dipende da fattori esterni anziché da un aumento delle attività aziendali. Invece di essere una progressione naturale, implica in genere un incremento improvviso e considerevole dell'utilizzo.
In alcuni casi non è possibile prevedere un aumento del traffico, del numero degli utenti e così via. In previsione di questi casi, è necessario impostare il sistema in modo che supporti il più possibile la scalabilità automatica e gestisca normalmente le condizioni di errore quando non è possibile. Tratteremo questo argomento più avanti in questo modulo.
In altri casi, ad esempio per il lancio imminente di un prodotto, può verificarsi una crescita inorganica che è possibile pianificare e preparare. Se i team di progettazione, prodotto, marketing e finanze collaborano tra loro e si sa come ottenere i modelli di utilizzo e di crescita delle risorse, è possibile adoperarsi per prevedere l'impatto di questi eventi sui requisiti delle risorse e implementare i cambiamenti di conseguenza.
Il raggiungimento di questo risultato dipende dall'organizzazione e dall'evento specifico. È possibile che il risultato ottenuto non sia quello previsto, ma essere preparati non può che tradursi in un grande vantaggio.
Scenario: Crescita dell'allineamento
Esaminiamo ora un'altra situazione ipotetica come esempio di pianificazione per la crescita inorganica. Si tratta di un evento di marketing imminente per il lancio di un nuovo prodotto di alto profilo di Tailwind Traders, che dovrebbe portare a un incremento di 5000 visitatori del sito di vendita aziendale.
Se si correlano, possibilmente con la giusta causalità, i dati dell'esempio precedente relativo alla crescita organica con una metrica aziendale ottenuta dai team di prodotto/marketing, ad esempio il numero di utenti, è possibile iniziare a pianificare la crescita inorganica.
Si sa dallo scenario precedente che per 2500 utenti sono necessari approssimativamente 50 GB di spazio di archiviazione e 100 UR. È ora possibile usare tali dati e determinare se si è pronti per questo evento. Se sono previsti 5000 utenti, saranno necessari 100 GB di spazio di archiviazione e 200 UR/s.
È possibile notare che la capacità di archiviazione è più che sufficiente per la crescita prevista in occasione dell'evento. La capacità è scalabile automaticamente, di conseguenza bisogna preoccuparsi solo di valutare quali saranno i nuovi costi, ma si tratta di un problema che verrà affrontato in seguito.
È anche possibile prevedere che le UR raggiungeranno solo il 50% di capacità dopo l'evento. Di conseguenza, non c'è da preoccuparsi della capacità di Cosmos DB per l'evento.
Vi sarà però un impatto sui costi.
Come si può notare, 100 GB di spazio di archiviazione aggiuntivo avranno un costo aggiuntivo di 25 USD al mese. Il prezzo della velocità effettiva rimane invariato perché i clienti pagano per le UR di cui è stato effettuato il provisioning e il numero delle unità è più che sufficiente. In conclusione, questo evento di marketing comporterà un incremento di 25 USD nella fattura per Cosmos DB.