Progettare con una mentalità orientata all'efficienza dei costi

Completato
Spendere solo su ciò che è necessario per ottenere il massimo ritorno sugli investimenti.

Ogni decisione architetturale ha implicazioni finanziarie dirette e indirette. Comprendere i costi associati alla compilazione rispetto alle opzioni di acquisto, alle scelte tecnologiche, al modello di fatturazione e alle licenze, al training, alle operazioni e così via.

Data una serie di requisiti, ottimizzare e prendere decisioni di compromesso, in relazione ai costi, che ancora rispondono efficacemente alle preoccupazioni trasversali del carico di lavoro.

Scenario di esempio

Contoso Manufacturing (CM) esegue un sistema di gestione del magazzino personalizzato (WMS) per gestire i quattro magazzini in America del Sud e ha deciso che è il momento di aggiornare la soluzione e spostarla nel cloud. Stanno prendendo in considerazione uno spostamento lift-and-shift della soluzione corrente o una compilazione di campo verde con strumenti cloud moderni. La leadership senior di CM vuole controllare i costi e ha chiesto ai responsabili del team del carico di lavoro come si avvicineranno alla migrazione con l'obiettivo di mantenere l'efficienza dei costi.

La soluzione WMS è un'applicazione .NET in esecuzione in IIS e usa SQL Server per i relativi database.

Misurare il costo totale della progettazione del carico di lavoro

Misurare il costo totale sostenuto dalle scelte tecnologico e di automazione, tenendo conto dell'impatto sul ritorno sugli investimenti (ROI). La progettazione deve funzionare entro i limiti accettabili per tutti i requisiti funzionali e non funzionali. La progettazione deve anche essere flessibile per supportare l'evoluzione stimata. Fattore del costo dell'acquisizione, della formazione e della gestione delle modifiche.

L'implementazione di un approccio bilanciato che tiene conto del ROI impedisce l'over-engineering, che potrebbe aumentare i costi.

Sfida di Contoso

  • Il team di progettazione del carico di lavoro è entusiasta di ottenere questo carico di lavoro nel cloud, aggiungendo altri team cm che hanno già eseguito lo sviluppo nativo del cloud.
  • Sono consapevoli del debito tecnico nell'applicazione e si aspettano di risolverlo riscrivendo una notevole quantità di codice dell'applicazione e passando a nuove soluzioni native del cloud per molti componenti.
  • Il team di progettazione spera di sfruttare questa opportunità per riprogettare completamente il sistema in microservizi e ospitarlo nel servizio Azure Kubernetes, una nuova tecnologia ma interessante per il team.

Applicazione dell'approccio e dei risultati

  • Anche se il team del carico di lavoro ha un chiaro desiderio di eseguire il refactoring su larga scala come parte della migrazione cloud, si rende conto che il carico di lavoro deve gestire il ROI. La gestione del ROI del carico di lavoro punterà probabilmente il team verso l'uso di soluzioni che non richiedono una formazione completa del nuovo team di progettazione e non sarà in grado di riscrivere di grandi dimensioni nel carico di lavoro come parte della migrazione.
  • Il team del carico di lavoro adotta un approccio pragmatico alla progettazione del sistema, assicurandosi che rimanga conveniente e funzioni all'interno dei parametri previsti e non sia ingegnere eccessivo. Per garantire che il ROI venga mantenuto e che la migrazione venga eseguita in modo efficiente, si è deciso che l'approccio migliore consiste nell'adottare una soluzione simile a quella nel cloud, ad esempio app Azure Servizio.
  • Durante la migrazione, affronteranno in modo selettivo alcuni debiti tecnici che consentiranno loro di evolvere ulteriormente la piattaforma una volta che si trova in Azure e considereranno il ROI come parte del processo di selezione.

Perfezionare la progettazione

Ottimizzare la progettazione assegnando priorità ai servizi che possono ridurre il costo complessivo, non richiedono investimenti aggiuntivi o non hanno un impatto significativo sulle funzionalità. La definizione delle priorità deve tenere conto del modello di business e delle scelte tecnologico che comportano un roi elevato.

Sarà possibile esplorare le opzioni più economiche che potrebbero abilitare la flessibilità delle risorse o il ridimensionamento dinamico oppure giustificare l'uso degli investimenti esistenti. I parametri di definizione delle priorità possono determinare i costi necessari per carichi di lavoro, runtime e operazioni critici e altri costi che potrebbero aiutare il team a lavorare in modo più efficiente.

Sfida di Contoso

  • Il carico di lavoro esistente è ospitato in un'appliance HCI (Hyper-Converged) e il centro di costo del team viene addebitato per i costi di calcolo, rete e archiviazione.
  • Il carico di lavoro ha distribuito gli ambienti di pre-produzione e di produzione nelle macchine virtuali Windows.
  • GitHub Actions con strumenti di esecuzione self-hosted viene usato per l'esecuzione di processi GitHub Actions.

Applicazione dell'approccio e dei risultati

  • Dopo aver valutato diverse opzioni native del cloud, il team decide che lo spostamento dei componenti Web nel servizio app Azure fornirà la compatibilità delle applicazioni IIS di Windows senza modifiche significative e non richiederebbe un training significativo.
  • Il team decide di continuare a usare GitHub Actions con strumenti di esecuzione self-hosted, ma eseguirà la migrazione a un set di scalabilità di macchine virtuali con la possibilità di ridimensionare fino a zero nodi quando non vengono usati.

Progettare l'architettura per supportare le protezioni dei costi

Implementare protezioni dei costi tramite soluzioni di piattaforma, criteri, modelli di progettazione dell'infrastruttura e delle applicazioni o automazione per garantire che i costi dell'ambiente cloud vengano mantenuti entro i budget.

L'applicazione tramite criteri di governance o modelli di progettazione di applicazioni predefiniti può impedire addebiti accidentali o non approvati.

Sfida di Contoso

  • Il sistema esistente non ha protezioni dei costi, ma raramente cambia, quindi c'è stata poca motivazione a costruire tali guardrail.
  • I proprietari dell'ambiente HCI hanno impostato un limite di risorse applicabile a questo carico di lavoro, impedendo così al carico di lavoro di consumare risorse di calcolo e archiviazione in eccesso.
  • Il team è preoccupato che il passaggio al cloud rappresenti il rischio di incorrere in costi imprevisti e non sa come ridurre al minimo il rischio.

Applicazione dell'approccio e dei risultati

  • Il team si informa sulle soluzioni di Gestione costi Microsoft.
  • Il team prevede di configurare i limiti di scalabilità per i piani di servizio app Azure.
  • Il team prevede di configurare criteri di negazione per determinati SKU di macchine virtuali a prezzi più elevati per impedire la distribuzione di tali SKU.
  • Il team prevede di implementare l'automazione per controllare i costi di archiviazione. Alcuni tipi di dati passeranno automaticamente dall'archiviazione ad accesso frequente all'archiviazione ad accesso sporadico o archivio in base a criteri come la data dell'ultimo accesso. Questo tipo di automazione non è possibile nell'ambiente HCI.

Verificare le conoscenze

1.

Quale di questi è uno dei fattori da tenere in considerazione quando si misura il costo totale del carico di lavoro?

2.

Quando si ottimizza la progettazione del carico di lavoro per i costi, quale di queste è consigliabile definire le priorità?

3.

Se il team del carico di lavoro vuole assicurarsi che il costo di Azure del carico di lavoro venga mantenuto sotto controllo, quale di queste operazioni deve eseguire?