Progettare con una mentalità orientata all'efficienza dei costi

Completato
Spendere il minimo per ottenere il massimo ritorno sugli investimenti.

Ogni decisione relativa all’architettura 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, alla formazione, alle operazioni e così via.

Data una serie di requisiti, ottimizzare e prendere decisioni equilibrate in relazione ai costi, che effettivamente ancora risolvono le preoccupazioni che incrociano i carichi di lavoro.

Scenario di esempio

Contoso Manufacturing (CM) esegue un sistema di gestione del magazzino con compilazione personalizzata (WMS) per gestire i quattro magazzini in America del Sud; l’azienda ha deciso che è arrivato il momento di aggiornare la soluzione spostandola nel cloud. Stanno considerando di trasferire la soluzione corrente in modalità lift-and-shift o una compilazione greenfield con strumenti cloud moderni. I dirigenti senior di CM volendo controllare i costi, hanno chiesto ai responsabili del team del carico di lavoro come avrebbero affrontato la migrazione con l'obiettivo di mantenere l'efficienza dei costi.

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

Misurare il costo totale della progettazione del carico di lavoro

Misurare il costo totale sostenuto dalle scelte tecnologiche e di automazione considerando l'impatto sul ritorno sugli investimenti (ROI). Entro limiti accettabili la progettazione deve funzionare per tutti i requisiti funzionali e non funzionali. Anche la progettazione deve essere flessibile per supportare l'evoluzione prevista. Scomporre in fattori il costo di acquisizione, di formazione e di gestione del cambiamento.

Implementando un approccio equilibrato che considera il ROI si evita un sovraccarico della progettazione, che può aumentare i costi.

Sfida di Contoso

  • Il team di progettazione del carico di lavoro non vede l’ora di ricevere questo carico di lavoro nel cloud, aggiungendo altri team CM che hanno già eseguito lo sviluppo nativo del cloud.
  • Sono consapevoli che l’applicazione presenta un debito tecnico e pensano di risolverlo riscrivendo una notevole quantità di codice dell'applicazione e passando molti componenti a nuove soluzioni native del cloud.
  • Il team di progettazione spera di sfruttare questa opportunità per riprogettare completamente il sistema in microservizi e ospitarlo nel servizio Azure Kubernetes, una nuova ed entusiasmante tecnologia per il team.

Applicazione dell'approccio e risultati

  • Nonostante il chiaro desiderio del team del carico di lavoro di eseguire il refactoring su larga scala come parte della migrazione cloud, hanno capito che è il carico di lavoro a gestire il ROI. Per la gestione del ROI del carico di lavoro il team considererà l'uso di soluzioni che non richiedono una nuova formazione completa del team di progettazione, e come parte della migrazione ampie porzioni del carico di lavoro non potranno essere riscritte.
  • Il team del carico di lavoro adotta un approccio pragmatico alla progettazione del sistema, garantendone l’efficienza dei costi e lavorando con parametri previsti senza sovraccaricare la progettazione. Per garantire il mantenimento del ROI e l’esecuzione efficiente della migrazione il team ha deciso che l'approccio migliore sia adottare una soluzione nel cloud alternativa scegliendo il servizio app di Azure.
  • Durante la migrazione risolveranno in modo selettivo alcuni debiti tecnici - ciò consentirà loro di evolvere ulteriormente la piattaforma una volta che si trova su Azure - e considereranno il ROI come parte del processo di selezione.

Ottimizzare la progettazione

Ottimizzare la progettazione assegnando priorità ai servizi che possono ridurre il costo complessivo non richiede investimenti aggiuntivi o e non ha un impatto significativo sulle funzionalità. La definizione delle priorità deve considerare il modello di business e le scelte tecnologiche che producono un ROI elevato.

Sarà possibile esplorare opzioni più economiche che abilitano la flessibilità delle risorse o il ridimensionamento dinamico oppure giustificare l'uso degli investimenti esistenti. I parametri di definizione delle priorità possono tradursi in costi, determinati da carichi di lavoro, runtime e operazioni critici - e in altri costi che aiutano il team a lavorare in modo più efficiente.

Sfida di Contoso

  • Il carico di lavoro esistente è ospitato su 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 risultati

  • Dopo aver valutato diverse opzioni native del cloud, il team decide che lo spostamento dei componenti Web nel servizio app di Azure fornirà la compatibilità delle applicazioni IIS di Windows senza modifiche significative e senza una formazione significativa.
  • 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 ridimensionamento fino a zero nodi quando questi non vengono usati.

Progettare l'architettura per supportare misure di protezione dei costi

Implementare misure di protezione dei costi tramite soluzioni piattaforma, criteri, modelli di progettazione dell'infrastruttura e di applicazioni o automazione per garantire che i costi dell'ambiente cloud rispettino i limiti di spesa.

La tutela attraverso i criteri di governance o i modelli predefiniti di progettazione dell’applicazione possono evitare addebiti accidentali e non approvati.

Sfida di Contoso

  • A parte qualche rara modifica, il sistema esistente non prevede misure di protezione dei costi. Finora c’è stata una scarsa motivazione alla compilazione di simili misure.
  • I proprietari dell'ambiente HCI hanno impostato un limite alle risorse da applicare a questo carico di lavoro, impedendo così al carico di lavoro di consumare eccessive risorse di calcolo e di archiviazione.
  • Il team è preoccupato che con la migrazione nel cloud aumenti il rischio di incorrere in costi imprevisti, ma non sa bene come ridurre al minimo tale rischio.

Applicazione dell'approccio e risultati

  • Il team studia le soluzioni di Gestione dei costi Microsoft.
  • Il team prevede di configurare dei limiti di scalabilità ai piani del servizio app di Azure.
  • Il team prevede di configurare criteri di rifiuto per determinati SKU di macchine virtuali con 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 solo come spazio di archiviazione basandosi su criteri come la data dell'ultimo accesso. Questo tipo di automazione non è possibile in un ambiente HCI.

Verificare le conoscenze

1.

Quale tra questi fattori deve essere preso in considerazione nella misurazione del costo totale del carico di lavoro?

2.

Quando si ottimizza la progettazione del carico di lavoro in relazione ai costi quali tra queste priorità devono essere definite?

3.

Quale di queste operazioni deve eseguire il team del carico di lavoro per essere sicuro di mantenere il costo di Azure del carico di lavoro sotto controllo?