Afwegingen voor kostenoptimalisatie

  • Artikel

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

Zodra u de ROI van een workload begrijpt, kunt u deze gaan verbeteren. Als u de ROI wilt verbeteren, moet u overwegen hoe beslissingen op basis van de ontwerpprincipes van Cost Optimization en de aanbevelingen in de controlelijst voor ontwerpbeoordeling voor Kostenoptimalisatie van invloed kunnen zijn op de doelstellingen en optimalisaties van andere Azure Well-Architected Framework-pijlers. Voor kostenoptimalisatie is het belangrijk dat u zich niet op een goedkopere oplossing richt. Keuzes die alleen gericht zijn op het minimaliseren van uitgaven, kunnen het risico vergroten dat de bedrijfsdoelen en reputatie van uw workload worden ondermijnd. In dit artikel worden voorbeelden van afwegingen beschreven die een workloadteam kan tegenkomen bij het overwegen van de doelinstelling, het ontwerp en de bewerkingen voor kostenoptimalisatie.

Afwegingen tussen kostenoptimalisatie en betrouwbaarheid

De kosten van een serviceonderbreking moeten worden gemeten tegen de kosten van het voorkomen of herstellen van een onderbreking van een service. Als de kosten van onderbrekingen hoger zijn dan de kosten van het ontwerp van betrouwbaarheid, moet u meer investeren om onderbrekingen te voorkomen of te beperken. Omgekeerd kunnen de kosten van de betrouwbaarheidsinspanningen groter zijn dan de kosten van een onderbreking, inclusief factoren zoals nalevingsvereisten en reputatie. U moet alleen in dit scenario strategische afstoting overwegen bij het ontwerpen van betrouwbaarheid.

Afweging: 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 te weinig inrichten of de schaal ervan te beperken, waardoor het onderdeel waarschijnlijk zal mislukken tijdens plotselinge pieken in de vraag.

  • Het consolideren van workloadresources (toenemende dichtheid) voor kostenoptimalisatie maakt de kans groter dat afzonderlijke onderdelen 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.

  • Geld besparen door redundantie te verminderen, kan de mogelijkheid van een workload om gelijktijdige storingen af te handelen, beperken.

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

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

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

Afweging: Beperkte herstelstrategie. Een betrouwbare workload heeft een geteste reactie op incidenten en een herstelplan voor noodscenario's.

  • Het minder testen of analyseren van het noodherstelplan van een workload kan van invloed zijn op de snelheid en effectiviteit van herstelbewerkingen.

  • Het maken of bewaren van minder back-ups vermindert mogelijke herstelpunten en vergroot de kans op gegevensverlies.

  • Een goedkoper ondersteuningscontract kan de hersteltijd van workloads verhogen vanwege mogelijke vertragingen in technische ondersteuning.

Tradeoff: Verhoogde complexiteit. Een workload die gebruikmaakt van eenvoudige benaderingen en onnodige of te veel complexe complexiteit voorkomt, is over het algemeen eenvoudiger te beheren in termen van betrouwbaarheid.

  • Met behulp van cloudpatronen voor kostenoptimalisatie kunnen nieuwe onderdelen worden toegevoegd, zoals een netwerk voor contentlevering (CDN), 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 waarmee rekening moet worden gehouden bij de workload.

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

Afwegingen tussen kostenoptimalisatie en beveiliging

De kosten van een inbreuk op de vertrouwelijkheid, integriteit en beschikbaarheid in een workload moeten altijd worden afgewogen tegen de kosten van het voorkomen van die inbreuk. 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. In de regel moet u geen inbreuk maken op beveiliging om kostenoptimalisaties te verkrijgen die lager zijn dan het punt van verantwoordelijkheid en overeenstemming zijn over risicobeperking. Het optimaliseren van beveiligingskosten door het vastleggen van rechten voor oplossingen is een belangrijke optimalisatiepraktijk, maar houd rekening met de volgende compromissen wanneer u dit doet.

Afweging: minder beveiligingscontroles. Beveiligingscontroles worden ingesteld in 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 genereren. Houd er rekening mee dat het verwijderen van beveiligingsonderdelen zoals de volgende voorbeelden om geld te besparen van invloed is op de beveiliging. U moet zorgvuldig een risicoanalyse uitvoeren op deze impact.

  • Het verminderen of vereenvoudigen van verificatie- en autorisatietechnieken brengt het expliciete verificatieprincipe van de architectuur zonder vertrouwen in gevaar. 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 toewijzingen voor op rollen gebaseerd toegangsbeheer om beheeroverhead te verminderen.

  • Het verwijderen van versleuteling in transit of at rest om de kosten voor certificaten en hun operationele processen te verlagen, stelt gegevens bloot aan mogelijke schendingen van de integriteit of vertrouwelijkheid.

  • Het verwijderen of verminderen van beveiligingsscans of inspectiehulpprogramma's of beveiligingstests vanwege de bijbehorende kosten en tijdsinvestering kan rechtstreeks van invloed zijn op de vertrouwelijkheid, integriteit of beschikbaarheid die de hulpprogramma's en tests moeten beschermen.

  • Het verminderen van de frequentie van beveiligingspatching vanwege de operationele tijd die is geïnvesteerd in het catalogiseren en uitvoeren van de patching, is van invloed op het vermogen van een workload om veranderende bedreigingen aan te pakken.

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

Afweging: Groter werklastoppervlak. De pijler Beveiliging geeft prioriteit aan een beperkt en beperkt 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 de oppervlakte van de werkbelasting. De onderdelen en de gegevens erin moeten worden beveiligd, mogelijk op manieren die nog niet in het systeem worden gebruikt. Deze onderdelen en gegevens zijn vaak onderworpen 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.

  • Het valetsleutelpatroon gebruiken om de verwerking te offloaden en resourcetoegang tot clientberekeningen te beveiligen.

  • Gebruik het patroon Queue-Based load leveling om de kosten te verlagen door een berichtenbus te introduceren.

Tradeoff: segmentatie verwijderd. De pijler Beveiliging geeft prioriteit aan sterke segmentatie ter ondersteuning van de toepassing van gerichte beveiligingscontroles en om de straal van de explosie onder controle te houden.

Het delen van resources, bijvoorbeeld in situaties met meerdere tenants of het co-lokaliseren van meerdere toepassingen op een gedeeld toepassingsplatform, is een benadering om de kosten te verlagen door de dichtheid te vergroten en het beheeroppervlak te verkleinen. 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 brengt, heeft ook een grotere straal.

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

  • Netwerkbeveiligingscontroles moeten breed genoeg zijn om alle resources op dezelfde locatie te omvatten. Deze configuratie schendt mogelijk het principe van minimale bevoegdheden voor sommige resources.

  • Het co-lokaliseren van verschillende toepassingen of gegevens op een gedeelde host kan leiden tot uitbreiding van nalevingsvereisten en beveiligingscontroles naar toepassingen of gegevens die anders buiten het bereik zouden vallen. Deze uitbreiding van het toepassingsgebied vereist extra beveiligingscontrole en controle-inspanningen voor de co-locatieonderdelen.

Compromissen tussen kostenoptimalisatie en operationele uitmuntendheid

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

  • Het verminderen van testinspanningen om tijd en de kosten te besparen die gepaard gaan met testpersoneel, resources en hulpprogramma's, kan leiden tot meer fouten in de productie.

  • Het uitstellen van het terugbetalen van technische schulden om personeel te richten op nieuwe functies kan leiden tot tragere ontwikkelingscycli en een algehele verminderde flexibiliteit.

  • Deprioritisering van documentatie om de inspanningen van het personeel te richten op productontwikkeling kan leiden tot langere onboardingtijd voor nieuwe werknemers, kan invloed hebben op de effectiviteit van incidentrespons en nalevingsvereisten in gevaar komen.

  • Een gebrek aan investeringen in training leidt tot stagnatie van vaardigheden, waardoor het team minder in staat is om nieuwere technologieën en procedures te gebruiken.

  • Het verwijderen van automatiseringshulpprogramma's om geld te besparen, kan ertoe leiden dat medewerkers meer tijd besteden aan taken die niet meer geautomatiseerd zijn. Het verhoogt ook het risico op fouten en inconsistenties.

  • Het verminderen van planningsinspanningen, zoals het bepalen van het bereik en het prioriteren van activiteiten, om uitgaven te verminderen, kan de kans op herwerk vergroten vanwege vage specificaties en slechte implementatie.

  • Het vermijden of verminderen van continue verbeteringsactiviteiten, zoals retrospectieven en incidentrapporten na incidenten, 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 een geslaagde reactie op incidenten heeft.

  • Het verminderen van het volume van logboeken en metrische gegevens 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.
    • Hiaten in de dekking van 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 toeneemt. De strategie voor workloadbewaking moet deze nieuwe onderdelen bevatten. Sommige patronen kunnen bijvoorbeeld stromen introduceren die meerdere onderdelen omvatten of processen van de server naar de client verplaatsen. Deze wijzigingen kunnen de complexiteit van het correleren en bijhouden van informatie vergroten.

  • Minder investeringen in waarneembaarheidshulpprogramma's en het onderhoud van effectieve dashboards kunnen de mogelijkheid om te leren van productie verminderen, ontwerpkeuzen valideren en productontwerp informeren. Deze vermindering kan ook een belemmering vormen voor incidentresponsactiviteiten en het moeilijker maken om te voldoen aan de hersteltijddoelstelling en SLO.

Afweging: uitgestelde onderhoud. Van workloadteams wordt verwacht dat ze code, hulpprogramma's, softwarepakketten en besturingssystemen op een tijdige en ordelijke manier up-to-date houden.

  • Het laten verlopen van onderhoudscontracten met leveranciers van hulpprogramma's kan leiden tot gemiste optimalisatiefuncties, oplossingen voor fouten en beveiligingsupdates.

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

Afwegingen tussen kostenoptimalisatie en 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 legt de nadruk op het voldoen aan prestatiedoelen zonder meer uit te geven dan nodig is. Kostenoptimalisatie legt de nadruk op 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 de efficiëntie van de prestaties. Er zijn echter compromissen tussen prestatie-efficiëntie en kostenoptimalisatie. Deze compromissen kunnen het moeilijker maken om prestatiedoelen te bereiken en de continue optimalisatie van prestaties te belemmeren.

Afweging: Onder- of onderschaalde 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 verkleinen, kunnen toepassingen resources ontnemen. De toepassing kan mogelijk geen aanzienlijke schommelingen in het gebruikspatroon verwerken.

  • Het beperken of uitstellen van schalen tot limiet of het verlagen van de kosten kan leiden tot onvoldoende aanbod 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 is voorbereid op plotselinge pieken in de vraag of frequente schaalschommelingen veroorzaken (flappingen).

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 op de workload is een manier om de efficiëntie te verhogen.

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

  • Het verwijderen van hulpprogramma's voor het testen of bewaken van toegangsprestaties verhoogt het risico op niet-gedetecteerde prestatieproblemen. Het beperkt ook de mogelijkheid voor een workloadteam om uit te voeren op metings-/verbeteringscycli.

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

Verken de compromissen voor de andere pijlers: