Delen via


Compromissen voor kostenoptimalisatie

Wanneer u een workload ontwerpt om het rendement op investeringen (ROI) onder financiële beperkingen te maximaliseren, hebt u eerst duidelijk gedefinieerde functionele en niet-functionele vereisten nodig. Een strategie voor prioriteitstelling van werk en inspanning is essentieel. De basis is een team dat een sterk gevoel van financiële verantwoordelijkheid heeft. Het team moet een goed begrip hebben van beschikbare technologieën en hun factureringsmodellen.

Nadat u de ROI van een workload hebt begrepen, kunt u beginnen met het verbeteren ervan. Als u het rendement wilt verbeteren, moet u overwegen hoe beslissingen op basis van de ontwerpprincipes voor kostenoptimalisatie en de aanbevelingen in de controlelijst voor ontwerpbeoordeling invloed kunnen hebben op de doelstellingen en optimalisaties van andere pijlers van Azure Well-Architected Framework. Voor kostenoptimalisatie is het belangrijk om te voorkomen dat u zich richt op een goedkopere oplossing. Keuzes die zich alleen richten op het minimaliseren van uitgaven, kunnen het risico verhogen dat de bedrijfsdoelen en reputatie van uw workload worden ondervangen. In dit artikel worden voorbeelden beschreven van de afwegingen die een workloadteam kan tegenkomen bij het overwegen van de doelinstelling, het ontwerp en de bewerkingen voor kostenoptimalisatie.

Compromissen voor kostenoptimalisatie met betrouwbaarheid

De kosten van een serviceonderbreking moeten worden gemeten tegen de kosten voor het voorkomen of herstellen van een serviceonderbreking. Als de kosten van onderbrekingen de kosten van betrouwbaarheidsontwerp overschrijden, moet u meer investeren om onderbrekingen te voorkomen of te beperken. Omgekeerd kunnen de kosten van de betrouwbaarheidsinspanningen meer zijn dan de kosten van een onderbreking, waaronder factoren zoals nalevingsvereisten en reputatie. U moet in dit scenario alleen rekening houden met strategische afstomping in het betrouwbaarheidsontwerp.

Compromis: verminderde tolerantie. Een workload bevat tolerantiemaatregelen om specifieke typen en hoeveelheden storingen te voorkomen en te weerstaan.

  • Om geld te besparen, kan het workloadteam een onderdeel onderverlenen of de schaal ervan overbelasten, waardoor het onderdeel waarschijnlijk zal mislukken tijdens plotselinge pieken in de vraag.

  • Het consolideren van workloadresources (toenemende dichtheid) voor kostenoptimalisatie maakt afzonderlijke onderdelen waarschijnlijker mislukken tijdens pieken in de vraag en tijdens onderhoudsbewerkingen, zoals updates.

  • Het verwijderen van onderdelen die ondersteuning bieden voor ontwerppatronen voor tolerantie, zoals een berichtenbus, en het maken van een directe afhankelijkheid vermindert de mogelijkheden voor zelfbehoud.

  • Besparen op geld door redundantie te verminderen, kan het vermogen van een workload om gelijktijdige storingen te verwerken beperken.

  • Het gebruik van budget-SKU's kan de maximale SLO (Service Level Objective) beperken die de workload kan bereiken.

  • Het instellen van harde bestedingslimieten kan voorkomen dat een workload wordt geschaald om te voldoen aan legitieme vraag.

  • Zonder hulpprogramma's of tests voor betrouwbaarheidstests is de betrouwbaarheid van een workload onbekend en is het minder waarschijnlijk dat deze voldoet aan de betrouwbaarheidsdoelen.

Compromis: Beperkte herstelstrategie. Een workload die betrouwbaar is, heeft een getest incidentrespons en herstelplan voor noodscenario's.

  • Minder testen of boren van het noodherstelplan van een workload kan van invloed zijn op de snelheid en effectiviteit van herstelbewerkingen.

  • Het maken of behouden van minder back-ups vermindert mogelijke herstelpunten en verhoogt de kans op verlies van gegevens.

  • Het kiezen van een goedkoper ondersteuningscontract met technologiepartners kan de hersteltijd van workloads verhogen vanwege mogelijke vertragingen in technische ondersteuning.

Compromis: Verhoogde complexiteit. Een workload die eenvoudige benaderingen gebruikt en onnodige of overgegineerde complexiteit vermijdt, is over het algemeen eenvoudiger te beheren in termen van betrouwbaarheid.

  • Met behulp van cloudpatronen voor kostenoptimalisatie kunnen nieuwe onderdelen, zoals een CDN (Content Delivery Network) worden toegevoegd of taken worden verplaatst naar edge- en clientapparaten waarvoor een workload betrouwbaarheidsdoelen moet bieden.

  • Schalen op basis van gebeurtenissen kan ingewikkelder zijn om af te stemmen en te valideren dan schalen op basis van resources.

  • Het verminderen van het gegevensvolume en het tieren van gegevens via acties voor de levenscyclus van gegevens, mogelijk in combinatie met het implementeren van geaggregeerde gegevenspunten vóór een levenscyclusgebeurtenis, introduceert betrouwbaarheidsfactoren die in de workload moeten worden overwogen.

  • Het gebruik van verschillende regio's om kosten te optimaliseren, kan beheer, netwerken en bewaking moeilijker maken.

Compromissen voor kostenoptimalisatie met beveiliging

De kosten van een inbreuk op vertrouwelijkheid, integriteit en beschikbaarheid in een workload moeten altijd worden verdeeld tegen de kosten van de inspanningen om dat compromis te voorkomen. Een beveiligingsincident kan een breed scala aan financiële en juridische gevolgen hebben en de reputatie van een bedrijf schaden. Investeren in beveiliging is een risicobeperkingsactiviteit. De kosten van het ervaren van de risico's moeten worden afgewogen tegen de investering. Maak in de regel geen inbreuk op beveiliging om kostenoptimalisaties te verkrijgen die onder het punt van verantwoordelijkheid liggen en overeengekomen risicobeperking. Het optimaliseren van de beveiligingskosten door oplossingen te rightsiseren is een belangrijke optimalisatiepraktijk, maar houd rekening met de afwegingen zoals het volgende wanneer u dit doet.

Compromis: verminderde beveiligingsmaatregelen. Beveiligingscontroles worden ingesteld op meerdere lagen, soms redundant, om diepgaande verdediging te bieden.

Een tactiek voor kostenoptimalisatie is om te zoeken naar manieren om onderdelen of processen te verwijderen die eenheids- of operationele kosten maken. Als u beveiligingsonderdelen verwijdert, zoals de volgende voorbeelden, is het besparen van geld van invloed op de beveiliging. U moet zorgvuldig een risicoanalyse uitvoeren op deze impact.

  • Door verificatie- en autorisatietechnieken te verminderen of te vereenvoudigen, wordt het verificatieprincipe van de architectuur met nulvertrouwen expliciet aangetast. Voorbeelden van deze vereenvoudigingen zijn het gebruik van een basisverificatieschema, zoals vooraf gedeelde sleutels, in plaats van tijd te investeren in het leren van OAuth-benaderingen in de branche of het gebruik van vereenvoudigde op rollen gebaseerde toewijzingen voor toegangsbeheer om de beheeroverhead te verminderen.

  • Het verwijderen van versleuteling tijdens overdracht of at-rest om de kosten voor certificaten te verlagen en hun operationele processen gegevens bloot te stellen aan mogelijke integriteits- of vertrouwelijkheidsschendingen.

  • Het verwijderen of verminderen van beveiligingsscans of controlehulpprogramma's of beveiligingstests vanwege de bijbehorende kosten en tijdsinvesteringen kan rechtstreeks van invloed zijn op de vertrouwelijkheid, integriteit of beschikbaarheid die de hulpprogramma's en tests zijn bedoeld om te beschermen.

  • Het verminderen van de frequentie van beveiligingspatching vanwege de operationele tijd die is geïnvesteerd in het catalogiseren en uitvoeren van patches, is van invloed op de mogelijkheid van een workload om zich te richten op veranderende bedreigingen.

  • Het verwijderen van netwerkbesturingselementen zoals firewalls kan leiden tot een fout bij het blokkeren van schadelijk binnenkomend en uitgaand verkeer.

Compromis: verhoogd oppervlakteoppervlak voor werkbelastingen. De beveiligingspijler geeft prioriteit aan een verminderd en ingesloten oppervlak om aanvalsvectoren en het beheer van beveiligingscontroles te minimaliseren.

Cloudontwerppatronen die kosten optimaliseren, vereisen soms de introductie van extra onderdelen. Deze extra onderdelen vergroten het oppervlak van de werkbelasting. De onderdelen en de gegevens in deze onderdelen moeten worden beveiligd, mogelijk op manieren die nog niet in het systeem worden gebruikt. Deze onderdelen en gegevens zijn vaak onderhevig aan naleving. Voorbeelden van patronen die onderdelen kunnen introduceren, zijn:

  • Het patroon Static Content Hosting gebruiken om gegevens te offloaden naar een nieuw CDN-onderdeel.

  • Met behulp van het valetsleutelpatroon voor het offloaden van de verwerking en beveiligde toegang tot resources voor client-compute.

  • Gebruik het patroon Load Leveling op basis van wachtrij om de kosten te verlagen door een berichtenbus te introduceren.

Compromis: segmentatie verwijderd. De beveiligingspijler geeft prioriteit aan sterke segmentatie om de toepassing van gerichte beveiligingscontroles te ondersteunen en om de straal te beheren.

Het delen van resources, bijvoorbeeld in situaties met meerdere tenants of het co-loceren van meerdere toepassingen op een gedeeld toepassingsplatform, is een benadering voor het verlagen van de kosten door de dichtheid te verhogen en het beheeroppervlak te verminderen. Deze verhoogde dichtheid kan leiden tot beveiligingsproblemen zoals deze:

  • Laterale verplaatsing tussen onderdelen die resources delen, is eenvoudiger. Een beveiligingsgebeurtenis die de beschikbaarheid van de toepassingsplatformhost of een afzonderlijke toepassing in gevaar heeft, heeft ook een grotere straal.

  • Co-locatieresources kunnen een workloadidentiteit delen en minder zinvolle audittrails hebben in toegangslogboeken.

  • Netwerkbeveiligingscontroles moeten breed genoeg zijn om alle co-locatiebronnen te dekken. Deze configuratie schendt mogelijk het principe van minimale bevoegdheden voor sommige resources.

  • Het zoeken naar verschillende toepassingen of gegevens op een gedeelde host kan ertoe leiden dat nalevingsvereisten en beveiligingscontroles worden uitgebreid naar toepassingen of gegevens die anders buiten het bereik vallen. Deze uitbreiding van het bereik vereist extra controle op de beveiliging en controle-inspanningen voor de co-locatieonderdelen.

Compromissen voor kostenoptimalisatie met Operational Excellence

Compromis: Gecompromitteerde SDLC-capaciteiten (Software Development Lifecycle). Het SDLC-proces van een workload biedt rigor, consistentie, specificiteit en prioriteitsbepaling voor wijzigingsbeheer in een workload.

  • Het verminderen van testinspanningen om tijd te besparen en de kosten die zijn gekoppeld aan testpersoneel, resources en hulpprogramma's, kunnen leiden tot meer fouten in de productieomgeving.

  • Het vertragen van de terugbetalen van technische schulden om de inspanningen van personeel op nieuwe functies te richten, kan leiden tot tragere ontwikkelingscycli en algehele verminderde flexibiliteit.

  • Deprioritisering van documentatie om personeel te concentreren op productontwikkeling kan leiden tot langere onboardingtijd voor nieuwe werknemers, invloed hebben op de effectiviteit van incidentrespons en nalevingsvereisten.

  • Een gebrek aan investeringen in training leidt tot gefaseerde vaardigheden, waardoor het team minder nieuwe technologieën en praktijken kan gebruiken.

  • Het verwijderen van automatiseringsprogramma's om geld te besparen, kan ertoe leiden dat personeel meer tijd besteedt aan de taken die niet meer worden geautomatiseerd. Het verhoogt ook het risico op fouten en inconsistenties.

  • Het verminderen van planningsinspanningen, zoals verkennende en prioriteitstelling van activiteiten, om de uitgaven te verminderen, kan de kans op herwerk vergroten als gevolg van vage specificaties en slechte uitvoering.

  • Het vermijden of verminderen van continue verbeteringsactiviteiten, zoals retrospectieven en incidentrapporten, om het workloadteam gefocust te houden op levering, kan gemiste kansen creëren om routine-, ongeplande en noodprocessen te optimaliseren.

Compromis: verminderde waarneembaarheid. Waarneembaarheid is nodig om ervoor te zorgen dat een workload zinvolle waarschuwingen en geslaagde reacties op incidenten heeft.

  • Het verlagen van het logboek- en metrische volume om te besparen op opslag en overdrachtskosten vermindert de waarneembaarheid van het systeem en kan leiden tot:

    • Minder gegevenspunten voor het maken van waarschuwingen met betrekking tot betrouwbaarheid, beveiliging en prestaties.
    • Dekkings hiaten in incidentresponsactiviteiten.
    • Beperkte waarneembaarheid in interacties of grenzen met betrekking tot beveiliging of naleving.
  • Ontwerppatronen voor kostenoptimalisatie kunnen onderdelen toevoegen aan een workload, waardoor de complexiteit ervan toeneemt. De strategie voor workloadbewaking moet deze nieuwe onderdelen bevatten. Sommige patronen kunnen bijvoorbeeld stromen introduceren die meerdere onderdelen omvatten of processen verplaatsen van de server naar de client. Deze wijzigingen kunnen de complexiteit van het correleren en bijhouden van informatie vergroten.

  • Verminderde investeringen in waarneembaarheidstooling en het onderhoud van effectieve dashboards kunnen de mogelijkheid om te leren van productie verminderen, ontwerpkeuzen valideren en productontwerp informeren. Deze vermindering kan ook incidentresponsactiviteiten belemmeren en het moeilijker maken om te voldoen aan de beoogde hersteltijd en SLO.

Compromis: uitgesteld onderhoud. Van workloadteams wordt verwacht dat code, hulpprogramma's, softwarepakketten en besturingssystemen op een tijdige en ordelijke manier worden bijgewerkt en bijgewerkt.

  • Het laten verlopen van onderhoudscontracten met hulpprogrammaleveranciers kan leiden tot gemiste optimalisatiefuncties, foutoplossingen en beveiligingsupdates.

  • Het verhogen van de tijd tussen systeempatches om tijd te besparen kan leiden tot gemiste foutoplossingen of een gebrek aan bescherming tegen veranderende beveiligingsrisico's.

Compromissen voor kostenoptimalisatie met prestatie-efficiëntie

De pijlers Kostenoptimalisatie en Prestatie-efficiëntie geven beide prioriteit aan het maximaliseren van de waarde van een workload. Prestatie-efficiëntie benadrukt het voldoen aan prestatiedoelen zonder dat er meer dan nodig is. Kostenoptimalisatie benadrukt het maximaliseren van de waarde die wordt geproduceerd door de resources van een workload zonder de prestatiedoelen te overschrijden. Als gevolg hiervan verbetert Kostenoptimalisatie vaak prestatie-efficiëntie. Er zijn echter compromissen voor prestatie-efficiëntie gekoppeld aan Kostenoptimalisatie. Deze compromissen kunnen het moeilijker maken om prestatiedoelen te bereiken en doorlopende prestatieoptimalisatie te belemmeren.

Compromis: niet-ingerichte of onderschalingse resources. Een prestatie-efficiënte workload heeft voldoende resources om aan de vraag te voldoen, maar heeft geen overmatige ongebruikte overhead, zelfs niet wanneer gebruikspatronen fluctueren.

  • Als u de kosten verlaagt door resources te verlagen, kunnen toepassingen van resources worden onteigend. De toepassing kan mogelijk geen aanzienlijke gebruikspatroonschommelingen verwerken.

  • Het beperken of vertragen van schaalaanpassing tot het maximum of het verlagen van de kosten kan ertoe leiden dat er onvoldoende aanbod is om aan de vraag te voldoen.

  • Instellingen voor automatisch schalen die agressief omlaag schalen om de kosten te verlagen, kunnen ervoor zorgen dat een service niet voorbereid is op plotselinge pieken in de vraag of frequente schaalschommelingen veroorzaken (flapping).

Compromis: Gebrek aan optimalisatie in de loop van de tijd. Het evalueren van de effecten van wijzigingen in functionaliteit, wijzigingen in gebruikspatronen, nieuwe technologieën en verschillende benaderingen van de workload is een manier om de efficiëntie te verhogen.

  • Het beperken van de focus op het ontwikkelen van expertise in prestatieoptimalisatie om prioriteit te geven aan levering kan leiden tot gemiste kansen om de efficiëntie van het resourcegebruik te verbeteren.

  • Als u hulpprogramma's voor het testen van toegangsprestaties of bewakingshulpprogramma's verwijdert, neemt het risico op niet-gedetecteerde prestatieproblemen toe. Het beperkt ook de mogelijkheid voor een workloadteam om uit te voeren op maateenheid-/verbeteringscycli.

  • Het negeren van gebieden die gevoelig zijn voor prestatievermindering, zoals gegevensarchieven, kan de prestaties van query's geleidelijk verslechteren en het algehele systeemgebruik verhogen.

Verken de compromissen voor de andere pijlers: