Monitorare e ottimizzare nel tempo
 Investire sempre in modo adeguato man mano che il carico di lavoro si evolve. |
|---|
Quello che era importante ieri potrebbe non esserlo oggi. Man mano che si apprende valutando i carichi di lavoro di produzione, è necessario prevedere cambiamenti nell'architettura, nei requisiti aziendali, nei processi e anche nella struttura del team. Le procedure del ciclo di sviluppo del software (SDLC) potrebbero dover evolversi. Anche i fattori esterni possono cambiare, ad esempio la piattaforma cloud, le relative risorse e i contratti.
È consigliabile valutare attentamente l'impatto di tutti i cambiamenti sui costi. Monitorare le modifiche e la tendenza del ROI a cadenza regolare e valutare se è necessario modificare i requisiti funzionali e non funzionali.
Scenario di esempio
Contoso Air offre una soluzione di tracciamento dei bagagli per le compagnie aeree. Il carico di lavoro è ospitato in Azure, è in esecuzione nel servizio Azure Kubernetes con Cosmos DB per il database e usa Hub eventi per la messaggistica. Il carico di lavoro viene distribuito nelle aree Stati Uniti occidentali e Stati Uniti orientali.
Valutare e ottimizzare continuamente l'ambiente e i costi di supporto.
Usare il sistema di tracciamento dei costi per valutare e ottimizzare continuamente i costi delle risorse, dei dati e del supporto a pagamento. Sono presenti risorse sottoutilizzate che possono essere ritirate, sostituite, ricompilate o sottoposte a refactoring?
È possibile ridurre i costi evitando di pagare per le risorse che non vengono usate completamente. Comprendere le metriche dei prezzi consente di prendere decisioni più allineate al modello di costo, nonché di prevenire la fatturazione non autorizzata. Il ridimensionamento o la rimozione di risorse sottoutilizzate, o anche la modifica degli SKU, possono ridurre i costi.
È anche possibile riuscire a risparmiare su alcuni costi valutando l'uso dei contratti di supporto con i fornitori di tecnologie e ridimensionandoli correttamente.
Sfida di Contoso
- Il team del carico di lavoro è sempre rimasto entro il budget, quindi l'ottimizzazione dell'efficienza dei costi non è stata una priorità.
- Prevede di migliorare l'affidabilità del carico di lavoro il prossimo anno ed è consapevole che ciò aumenterà i costi di Azure, probabilmente spingendo il costo del carico di lavoro oltre al budget. Sta valutando la possibilità di richiedere di un aumento del budget per il prossimo anno.
Applicazione dell'approccio e risultati
- Il team decide che prima di richiedere più denaro, valuterà i costi correnti di Azure e del supporto per individuare possibili opportunità di risparmio. Esamina le suddivisioni dei costi per risorsa, per gruppo di risorse e per tag nel sistema di tracciamento dei costi esistente e nota una spesa imprevista.
- Il team scopre che nel proprio ambiente sono in esecuzione macchine virtuali che sono state usate per un sistema di compilazione deprecato e non sono più necessarie, è presente una quantità significativa di dati obsoleti in Archiviazione di Azure che può essere spostata in un livello meno costoso e che il contratto di supporto con il provider di servizi cloud include ore di consulenza di cui non usufruiscono.
- Il team ottimizza i costi di Azure eliminando le macchine virtuali inutilizzate e spostando i dati precedenti nello spazio di archiviazione. Inizia a lavorare più da vicino con il provider di servizi cloud per sfruttare al meglio i propri servizi di consulenza.
- Il team aggiunge un'attività ricorrente al backlog per eseguire valutazioni dei costi del carico di lavoro in futuro.
Esaminare e perfezionare continuamente il carico di lavoro
Adeguare continuamente le decisioni di progettazione dell'architettura, delle risorse, del codice e dei flussi di lavoro ai dati ROI.
Le revisioni regolari delle metriche, dei dati sulle prestazioni, dei report di fatturazione e dell'utilizzo delle funzionalità possono favorire un'ottimizzazione che può ridurre i costi.
Sfida di Contoso
- Dal momento che storicamente il team è rimasto entro il budget, non ha esaminato approcci alternativi alle funzionalità esistenti. La maggior parte della pianificazione era invece incentrata sulla creazione di nuove funzionalità.
- Dopo aver trovato elementi obsoleti durante la valutazione iniziale, decide di esaminare il resto dei componenti correnti per cercare opportunità di ottimizzazione.
Applicazione dell'approccio e risultati
- Il team rileva di aver allocato più risorse di quelle necessarie ai flussi con priorità bassa e che possono ridurre in modo sicuro la velocità effettiva allocata, mantenendo al contempo i requisiti di prestazioni. In particolare, possono discostarsi dal provisioning eccessivo per la gestione dei carichi di picco e implementare invece un sistema di livellamento del carico basato su coda.
- Scopre anche che è stata aggiunta una nuova funzionalità che sostituisce il codice di autenticazione allo SKU selezionato nella piattaforma di calcolo. L'uso di questa funzionalità comporta un minor numero di codice da gestire e testare.
Ottimizzare gli ambienti di distribuzione
È consigliabile considerare gli ambienti SDLC in modo diverso e distribuire il numero corretto di ambienti. Gli ambienti di produzione devono essere il fattore di costo principale.
È possibile risparmiare denaro comprendendo che non tutti gli ambienti devono simulare la produzione. Gli ambienti non di produzione possono avere funzionalità, SKU, numeri di istanze e persino modalità di registrazione diverse.
È anche possibile risparmiare sui costi creando ambienti di preproduzione su richiesta e rimuovendoli quando non sono più necessari.
Sfida di Contoso
- Il team del carico di lavoro spende di più negli ambienti di preproduzione rispetto agli ambienti di produzione. Sebbene ciò possa essere importante in alcuni scenari, sembra eccessivo per questo carico di lavoro.
- Gli ambienti di preproduzione sono stati creati in modo che corrispondano molto strettamente all'ambiente di produzione. Il team del carico di lavoro apprezza la disponibilità di un'approssimazione molto vicina dell'ambiente di produzione negli ambienti di livello inferiore, in quanto permette loro di essere assolutamente certi che i comportamenti nell'ambiente di produzione corrispondano a quelli degli ambienti di livello inferiore.
Applicazione dell'approccio e risultati
- Dopo un'attenta valutazione, il team decide di accettare il compromesso di un po’ più di rischio per ottenere i risparmi sui costi derivanti dalla differenziazione degli ambienti.
- Il team decide di scegliere una posizione condivisa per alcuni ambienti di test nella stessa infrastruttura e di arrestare gli ambienti inutilizzati durante la notte.
- Il team trova anche opportunità di spostarsi a sinistra ed eseguire lo sviluppo e il test dei cicli interni nelle workstation di sviluppo locali.
- Trovando modi per fare piccoli compromessi negli ambienti di preproduzione e nelle procedure di sviluppo, hanno svincolato risorse del budget che verranno messe a buon uso nelle attività di automazione.