Progettare per l'ottimizzare l'utilizzo
 Ottimizzare l'uso di risorse e operazioni. Applicarli ai requisiti funzionali e non funzionali negoziati della soluzione. |
|---|
I servizi e le offerte offrono diverse funzionalità e piani tariffari. Dopo aver acquistato un set di funzionalità, evitare di sottoutilizzarle. Trovare modi per massimizzare l'investimento nel livello. Allo stesso modo, valutare continuamente i modelli di fatturazione per trovare quelli più allineati all'utilizzo, in base ai carichi di lavoro di produzione correnti.
Scenario di esempio
Contoso University ospita attualmente una soluzione commerciale off-the-shelf che consente alla facoltà universitaria di creare e aggiornare i corsi per l'anno scolastico ed è il portale di registrazione principale usato dagli studenti per tali corsi. La soluzione ha un'integrazione personalizzata con un sistema di gestione dell'istruzione SaaS (Software-as-a-Service), che spera di eseguire la migrazione di tutte le funzioni in pochi anni. Nel frattempo, vogliono ottimizzare i costi per i componenti di integrazione personalizzati.
La soluzione tecnologica dell'offerta HANDLE viene in genere considerata come una scatola nera, ad eccezione del database di Azure per MySQL. L'integrazione personalizzata è una funzione durevole di Azure, che viene eseguita in un piano di servizio Standard nel servizio app di Azure. Questo servizio app ha ospitato in precedenza un sito Web universitario, ma ora non più. Questa funzione durevole è un'applicazione Python supportata da un account di Archiviazione di Azure dedicato che esegue una sincronizzazione notturna dal database MySQL all'API SaaS.
Usare i prezzi basati sul consumo quando è conveniente
Potrebbero esserci servizi che offrono prezzi basati sul consumo, il che significa che vengono fatturati solo per l'utilizzo del servizio ed è possibile arrestare il servizio quando non è necessario per non in ulteriori costi. Se si dispone di componenti del carico di lavoro utilizzati solo sporadicamente, ciò può contribuire a ridurre al minimo gli sprechi rispetto a pagare per eseguire il componente 24 ore 24, 365 giorni all'anno.
Usando i prezzi basati sul consumo, si paga solo per quello che si usa. Questa opzione è una scelta ottimale quando non è previsto che il calcolo del carico di lavoro venga effettuato a tempo pieno.
Sfida di Contoso
- Il processo di sincronizzazione viene in genere eseguito per circa un'ora ogni notte, in un momento specifico. Le sue prestazioni sono state storicamente soddisfacenti. I malfunzionamenti sono rari e gli errori temporanei vengono gestiti correttamente, nella configurazione corrente.
- Poiché il calcolo necessario per il processo di sincronizzazione viene usato solo circa un'ora al giorno, e si paga per 24 ore indipendentemente dall'utilizzo, il team del carico di lavoro è interessato a un'alternativa.
- Il team ha considerato la scrittura di uno script per arrestare il servizio ogni notte dopo l'esecuzione della sincronizzazione e ridistribuirlo il giorno successivo, ma questa soluzione avrebbe un alto livello di rischio e complessità.
Applicazione dell'approccio e risultati
- Il team analizza la cronologia dei processi e rileva che la durata della funzione più lunga è stata appena di due ore. Confrontano il costo del piano dedicato con il costo del piano a consumo di Funzioni di Azure nel scenario peggiore e arrivano alla conclusione che il piano a consumo sarà meno costoso.
- Il team esegue un test delle prestazioni per garantire che le prestazioni siano sufficienti e notano un lieve aumento del tempo di esecuzione, ma è ancora entro limiti accettabili.
- Il costo complessivo del carico di lavoro viene ridotto usando il piano a consumo, perché comporta costi solo quando il processo è in esecuzione.
Ottimizzare la progettazione della disponibilità elevata
Dare priorità alla distribuzione di modelli attivi-attivi o solo-attivi rispetto a modelli attivi-passivi, come parte del piano di ripristino, se si è già pagato per le risorse.
Se per impostazione predefinita la progettazione usa modelli attivi-passivi, potrebbero essere presenti risorse inattive che potrebbero essere usate. La conversione in attivo-attivo potrebbe consentire di soddisfare i requisiti di livellamento del carico e ridimensionamento del bursting senza sovraccarico. Se è possibile soddisfare le destinazioni di ripristino con un modello solo attivo, i costi di tali risorse possono essere rimossi completamente.
Sfida di Contoso
- L'applicazione ENCLOSURE usa il server flessibile di Database di Azure per MySQL configurato per la disponibilità elevata della stessa zona, che fornisce un server standby nella stessa zona di disponibilità del server primario. Hanno anche abilitato i backup automatici.
- L'RPO del carico di lavoro è relativamente lungo se a 12 ore e l'obiettivo RTO è di tre ore durante i giorni di lezione.
- In base ai test di ripristino precedenti, il team sa che può soddisfare le destinazioni RPO e RTO tramite failover automatico nel server di standby. Hanno anche testato il ripristino del database da un backup e possono soddisfare le destinazioni in questo scenario.
Applicazione dell'approccio e risultati
- Il team del carico di lavoro valuta nuovamente il vantaggio della progettazione a disponibilità elevata rispetto al costo del servizio pari al doppio di una singola istanza.
- Il team testa la creazione di una nuova istanza e il ripristino di un database dal backup e sono soddisfatti, perché saranno ancora conformi alle destinazioni di ripristino, quindi decidono di eliminare l'istanza di standby.
- Il team aggiorna il piano di ripristino di emergenza per riflettere la nuova strategia di ripristino e ottenere risparmi sui costi tramite la nuova configurazione.
Mantenere l'ambiente cloud pulito di risorse e dati inutilizzati
Esaminare regolarmente e rigorosamente le distribuzioni per le risorse e i dati inutilizzati e rimuoverli. Nel corso del tempo, le risorse e i dati necessari per qualche scopo in passato, ma non vengono più usati possono rimanere negli ambienti cloud e accumulare inutilmente costi. Prestare attenzione a mantenere puliti gli ambienti per ottimizzare l'efficienza dei costi.
Arrestare le risorse inutilizzate ed eliminare i dati quando non sono più necessari riduce i rifiuti e libera fondi in modo da poterli investire altrove.
Sfida di Contoso
- L'università ha storicamente adottato un approccio conservativo per rimuovere le soluzioni, temendo che possano dover ripristinare una configurazione precedente. Questa cautela fa portato all'abbandono, anche per mesi, di servizi in esecuzione in uno o più ambienti che sono stati dimenticati in alcuni casi.
- Quando vengono individuati servizi abbandonati, in genere succede per caso perché non esiste un processo formale per esaminare l'ambiente e cercare tali servizi.
Applicazione dell'approccio e risultati
- Il team aggiunge la rimozione delle autorizzazioni del servizio app al backlog come parte della migrazione dal servizio app all'hosting a consumo per Durable Function. Come parte dello sprint successivo, verranno arrestate le distribuzioni del servizio app in tutti gli ambienti.
- Per facilitare il rilevamento proattivo delle risorse abbandonate, il team configura gli avvisi in Azure Advisor per notificare loro le risorse inutilizzate.
- Il team implementa un nuovo criterio che richiede al team di eseguire revisioni complete mensili degli ambienti di pre-produzione e revisioni complete trimestrali dell'ambiente di produzione, per identificare le risorse abbandonate. Tutte le risorse abbandonate trovate verranno aggiunte al backlog per essere rimosse.