Progettare per l'ottimizzazione della frequenza
 Aumentare l'efficienza senza riprogettare, rinegoziare o sacrificare i requisiti funzionali o non funzionali. |
|---|
Sfruttare le opportunità per ottimizzare l'utilità e i costi delle risorse e delle operazioni esistenti. In caso contrario, si spende inutilmente denaro senza alcun ROI aggiunto.
Scenario di esempio
Il team di Business Intelligence (BI) di Contoso ospita una suite di API GraphQL per varie business unit per accedere agli archivi dati all'interno dell'organizzazione senza concedere l'accesso diretto al database. Questi elementi sono stati compilati nel corso degli anni e hanno scoperto che il controllo delle versioni era importante, quindi hanno esposto le API ora sugli endpoint con controllo delle versioni in un singolo livello di consumo Gestione API gateway.
Dietro le istanze di Gestione API sono presenti tre cluster del servizio Azure Kubernetes che ospitano le API esposte. Uno che esegue un pool di nodi Windows per le API scritte in .NET 4.5, un cluster Linux per le API scritte in Java Spring e un Linux ereditato da un team precedente che esegue le API core dotnet. I cluster sono ora di proprietà del team bi e vengono usati solo per queste API. Anche se la gestione di tre cluster non è ideale, funzionano come previsto, quindi sono stati lasciati soli.
Come centro di costo nell'azienda, il team bi sta cercando modi per ottimizzare le tariffe per ridurre i costi operativi.
Consolidare l'infrastruttura in cui è pratica
Co-individuare l'utilizzo con altre risorse, carichi di lavoro e persino team. Preferisce i servizi che rendono più semplice ottenere una maggiore densità. Considerare i potenziali compromessi, in particolare sui limiti di sicurezza.
Il consolidamento dell'infrastruttura consentirà di ottimizzare i costi del cloud. Con l'aumentare della densità, la quantità di risorse necessarie per eseguire un carico di lavoro diminuisce. Questa riduzione riduce il costo per unità e il costo della gestione.
Sfida di Contoso
- Il team del carico di lavoro ha progettato l'infrastruttura del servizio Azure Kubernetes in base alle indicazioni sull'architettura di base Microsoft, che consiglia di eseguire almeno tre nodi per ogni cluster. Questa configurazione ha portato il team a supportare nove nodi di sistema tra i tre cluster.
- Il team applica patch e aggiornamenti ai cluster tre volte al mese.
Applicazione dell'approccio e dei risultati
- Dopo il test, il team decide di combinare tutte le API in un singolo cluster con tre pool di nodi utente, ottenendo allo stesso tempo le stesse prestazioni e le stesse caratteristiche del sistema operativo del cluster originale.
- Dopo aver consolidato le API in un cluster, si consolidano in quattro nodi per il pool di nodi di sistema, risparmiando i costi di cinque macchine virtuali.
- Il team può ora anche semplificare il processo di applicazione di patch e aggiornamento nel cluster perché ha un solo cluster da gestire.
- Il successivo obiettivo di risparmio sui costi consiste nel valutare il consolidamento dei due pool di nodi Linux in uno per ridurre ulteriormente il sovraccarico operativo.
Sfruttare i vantaggi delle prenotazioni e di altri sconti dell'infrastruttura
Ottimizzare eseguendo il commit e il pre-acquisto per sfruttare gli sconti offerti sui tipi di risorse che non devono cambiare nel tempo e per cui i costi e l'utilizzo sono prevedibili. Inoltre, collaborare con il team di gestione delle licenze per influenzare i futuri programmi di acquisto e i rinnovi.
Microsoft offre tariffe ridotte per un impegno prevedibile e a lungo termine per specifiche risorse e categorie di risorse. Le risorse costano meno durante il periodo di utilizzo e possono essere ammortizzate nel periodo.
Mantenendo il team di gestione delle licenze consapevole dell'investimento corrente e stimato per risorsa, è possibile aiutarli a impegni di dimensioni corrette quando l'organizzazione firma il contratto. In alcuni casi, queste proiezioni e impegni potrebbero influenzare il listino prezzi dell'organizzazione, che trae vantaggio dai costi del carico di lavoro e anche da altri team che usano la stessa tecnologia.
Sfida di Contoso
- Ora che il team si è consolidato in un cluster, rimuovendo alcune delle risorse di calcolo in eccesso e il carico operativo assorbito in precedenza, si è interessati a trovare misure aggiuntive per ridurre il costo del cluster.
- Poiché il team di business intelligence è soddisfatto della piattaforma del servizio Azure Kubernetes, prevede di continuare a usarlo per il prossimo futuro e probabilmente crescerà anche l'utilizzo.
Applicazione dell'approccio e dei risultati
- Poiché il servizio Azure Kubernetes è basato su set di scalabilità di macchine virtuali, il team esamina le prenotazioni di Azure. Conoscono gli SKU previsti e le unità di scala necessarie per i nodi utente.
- Acquistano una prenotazione di tre anni che copre il pool di nodi di sistema e il numero minimo di istanze di nodi per ogni pool di nodi utente.
- Con questo acquisto, il team sa che sta ottenendo la soluzione migliore per le proprie esigenze di calcolo, consentendo al contempo al carico di lavoro di crescere nel tempo.
Usare la fatturazione a prezzo fisso quando pratica
Passare alla fatturazione a prezzo fisso anziché alla fatturazione basata sul consumo per una risorsa quando l'utilizzo è elevato e prevedibile e è disponibile un'opzione di fatturazione o SKU paragonabile.
Quando l'utilizzo è elevato e prevedibile, il modello a prezzo fisso in genere costa meno e spesso supporta più funzionalità. L'uso potrebbe aumentare il roi.
Sfida di Contoso
- Le istanze di Gestione API vengono tutte distribuite come SKU del livello a consumo. Dopo aver valutato i modelli di utilizzo delle API, capiscono che le API vengono usate a livello globale e talvolta molto pesante. Il team decide di analizzare le differenze di costo tra il modello di fatturazione corrente e un modello a prezzo fisso.
Applicazione dell'approccio e dei risultati
- Dopo aver eseguito l'analisi dei costi, il team rileva che la migrazione dal livello Consumption al livello Standard sarà leggermente meno costosa, in base ai modelli di utilizzo correnti. Man mano che i servizi crescono nel prossimo anno, le differenze di costo diventeranno probabilmente più pronunciate. Anche se il modello a prezzi fissi non riflette le caratteristiche di elasticità delle richieste, a volte i modelli di fatturazione preacquistati sono la scelta giusta.
- Come ulteriore vantaggio, l'uso del livello Standard consente l'uso di un endpoint privato per le connessioni in ingresso, che il team è stato desideroso di implementare per il carico di lavoro.
- In questo caso, il cambio di SKU ha senso sia per gli scopi di utilizzo che per il vantaggio aggiunto della segmentazione di rete aggiuntiva possibile con un'implementazione dell'endpoint privato.