Azure Well-Architected Framework-workloads

  • Artikel

In de context van het Azure Well-Architected Framework verwijst de term workload naar een verzameling toepassingsresources, gegevens en ondersteunende infrastructuur die samen werken om gedefinieerde bedrijfsresultaten te bereiken. Een workload bestaat uit onderdelen en ook uit ontwikkel- en operationele procedures.

Architecten ontwerpen workloads en een workloadteam implementeert deze. Een workload is ontworpen en geïmplementeerd om te voldoen aan functionele en niet-functionele bedrijfsvereisten. Workloads kunnen worden ingedeeld in veel typen.

Typische criteria voor workloadclassificatie zijn onder andere:

  • Hulpprogramma's, kenmerken en gebruikspatronen van een workload, zoals webtoepassingen, batchverwerking en realtime analyses.

  • Belangrijke invloedrijke factoren, zoals technologieplatforms of afstemming met een branche.

  • Beoogde doelgroep. Voorbeelden van oplossingen met verschillende doelgroepen zijn interne Line-Of-Business-toepassingen binnen ondernemingen, een aangeschafte onafhankelijke softwareleverancier (ISV)-oplossing of een SaaS-oplossing (Software as a Service) voor openbaar gebruik met meerdere tenants.

Workloads die zich in dezelfde klasse bevinden, kunnen overeenkomsten hebben, waaronder hun doelgroep, nalevingsvereisten en technologiestacks. De vijf pijlers van het Well-Architected Framework, hun principes, controlelijsten en compromissen zijn relevant voor alle workloadklassen.

In de workloadrichtlijnen van het Well-Architected Framework worden algemene prioriteiten en compromissen beschreven, aangezien deze betrekking hebben op specifieke workloadklassen. In de workloadrichtlijnen is de pijlerrichtlijnen van toepassing op technische ontwerpprincipes en ontwerpgebieden die de prioriteiten van een workload vertegenwoordigen. Volg de aanbevelingen voor het instellen van een geslaagde workload en om deze af te stemmen op het Well-Architected Framework.

Wat is een Well-Architected Framework-workload?

Het ontwerp en de bewerkingen van elke workload hebben te maken met de vijf architectuurpijlers: betrouwbaarheid, beveiliging, kostenoptimalisatie, operationele uitmuntendheid en prestatie-efficiëntie.

Als u een succesvolle workload wilt maken, moet u deze ontwikkelen in overeenstemming met de Well-Architected Framework-principes, die zijn gebaseerd op de volgende idealen.

Een Well-Architected Framework-workload:

  • Heeft functionele en niet-functionele vereisten die zijn gedefinieerd en prioriteit hebben om een doel te bereiken.
  • Is zo ontworpen dat u aan deze vereisten kunt voldoen door resources te gebruiken en ontwerppatronen en compromissen op te nemen.
  • Wordt gebouwd en gebruikt volgens de specificaties van een ontwerp en doel.
  • Wordt gemeten aan de mate waarin het zijn doel bereikt.
  • Kan zich aanpassen als het doel wordt verfijnd of gewijzigd.
  • Is net zo betrouwbaar als nodig is.
  • Is net zo veilig als nodig is.
  • Levert een voldoende rendement op de investering.
  • Wordt op verantwoorde wijze ontwikkeld en gebruikt.
  • Bereikt het doel binnen een acceptabele periode.

Een samenwerking tussen het workloadteam en de centrale teams van een organisatie moet een workload maken met de voorgaande kenmerken. In de volgende secties worden deze teams en hun functies beschreven.

Workloadteam

Maak een workloadteam met teamleden met een breed scala aan technische en zakelijke disciplines. De primaire focus van alle teamleden moet het succes van de workload zijn.

Voorbeelden van workloadteamleden  
Toepassingsbeveiligingstechnici
Zakelijke belanghebbenden
Cloudontwikkelaars of softwaretechnici
Cloudoplossingsarchitecten
Gegevenswetenschappers of analisten
Databasebeheerders
 DevOps-technici
Infrastructuurtechnici
Productmanagers of eigenaren
Qa-technici (Quality Assurance)
Leden van het ondersteuningsteam

Gecentraliseerde teams en belanghebbenden

Gecentraliseerde teams ondersteunen vaak het workloadteam. Ze bieden ondersteuningsfuncties en passen governance toe voor veel of alle cloudworkloads binnen een organisatie. Gecentraliseerde teams richten zich op het succes van de organisatie, die deels wordt bereikt door het succes van de workloads van de organisatie. Ze bieden services, richtlijnen en kaders voor workloads.

Voorbeelden van gecentraliseerde teams en teamleden  
Business Intelligence-analisten
Zakelijke belanghebbenden
CCoE-bord (Cloud Center of Excellence)
Cloudplatformteam
Cyberbeveiligingsanalisten
Databasebeheerders
Ondernemingsarchitecten
 Financiële analisten
Infrastructuurtechnici
Juridische en nalevingsfunctionarissen
Netwerktechnici
Inkoopspecialisten
Projectmanagers

Een Well-Architected Framework-workloadteam richt zich op workloadresultaten. Ze coördineren met en profiteren van de gespecialiseerde ondersteuning van gecentraliseerde teamleden.

Het model van gedeelde verantwoordelijkheid

Een workload moet worden geïmplementeerd en gebruikt om waarde te kunnen leveren. Als onderdeel van het workloadteam hebt u de verantwoordelijkheid om uw workload te ontwerpen, implementeren en implementeren op een manier die waarde creëert voor uw organisatie.

Workloads bestaan binnen de context van uw organisatie. Een organisatie heeft vaak gereguleerde bestuurs- en autoriteitsrollen. Uw workloadteam is verantwoordelijk voor het ontwerpen, implementeren en implementeren van een workload binnen de basis van uw organisatie.

In overeenstemming met de Cloud Adoption Framework voor Azure kunt u de cloudresources van uw workload standaardiseren. Pas de standaardisatie strikt toe om een beheerd platform te bieden om te helpen bij het onboarden van workloadteams. Pas deze governance toe in overeenstemming met het operationele cloudmodel van uw organisatie.

U kunt Azure-landingszones gebruiken om standaardisatie uit te voeren. Platformlandingszones en landingszones voor toepassingen zijn beschikbaar in Azure. Implementeer uw workload in een toepassingslandingszone.

Uw organisatie heeft mogelijk een cloudplatform dat strikt is geformaliseerd en volledig is afgestemd op Azure-landingszones. Of uw organisatie heeft mogelijk een andere acceptatiestrategie of geen implementatie. Als er geen implementatie is, zijn workloadteams bijna volledig autonome entiteiten.

Voor elk platform en beheer dat uw organisatie gebruikt, moet u de principes van het Well-Architected Framework toepassen op uw workloads. Het Well-Architected Framework verwijst vaak naar Azure-landingszones, maar is niet afhankelijk van een specifieke platform-implementatie. De pijlers, principes, controlelijsten en handleidingen van Well-Architected Framework zijn voor alle cloudplatforms en de meeste typen werkbelastingen.

Voldoen aan vereisten

In het Well-Architected Framework, zoals de kernpijlers en de richtlijnen voor workloads, vallen aanbevelingen samen met de verplichting van de workload. Aanbevelingen impliceren meestal niet welk teamlid of team deze verplichtingen faciliteert. U kunt bepalen wie elke actie moet uitvoeren. Voer een toewijzing op workloadniveau uit om de rollen en verantwoordelijkheden van uw team te bepalen met betrekking tot de topologie, het type workload en de ernst.

Het directe workloadteam verwerkt de meeste workloadvereisten. Sommige vereisten worden afgehandeld als een gezamenlijke inspanning met gecentraliseerde teams. De implementatieopties kunnen bijvoorbeeld zijn gebaseerd op kaders die een gecentraliseerd team instelt. Of een gecentraliseerd team kan uitsluitend de implementatiekeuzes afhandelen.

Uw workloadteam moet een werkrelatie opbouwen met andere teams om code te helpen bij het bepalen van workloaddoelen. Als u onderdelen of verantwoordelijkheden uitbesteedt, moet u aan deze verplichtingen voldoen.

Meer informatie over de beperkingen

Een gecentraliseerd team ondersteunt diverse workloads op basis van de kernmogelijkheden en kerninfrastructuur van het team. Om deze ondersteuning op organisatieschaal te bieden, kan het gecentraliseerde team uniformiteit en beperkingen implementeren voor de aangeboden service of de infrastructuur. Bij het ontwerpen van uw workload is het essentieel dat u deze beperkingen begrijpt en waar mogelijk samenwerkt met ondernemingsarchitecten die deze beperkingen kennen. Leer zoveel mogelijk van eerdere implementaties.

Elke implementatie van platformgovernance is anders, maar de volgende beperkingen zijn gebruikelijk voor veel workloads:

  • Acceptatielijsten voor cloudresources
  • Configuratiemandaten voor cloudresources
  • Regionale acceptatielijsten voor cloudresources en beschikbaarheid van cross-premises connectiviteit
  • Beperkte of geen platformondersteuning buiten kantooruren
  • Patchvereisten
  • Specifieke hub-spoke-implementatie, die dns-implementaties (Domain Name System) en privé-eindpunten aanstuurt
  • Vereisten voor toeleveringsketenbeheer

Vereisten expliciet communiceren

Als uw workloadvereiste te maken heeft met een beperking of een Service Level Agreement (SLA) die een kernmogelijkheid of infrastructuuraanbod niet duidelijk definieert, behandelt u die situatie als een risico. Om dit risico aan te pakken, moet uw workloadteam de andere teams duidelijkheid geven over hoe de zorg van invloed is op de workload. Mogelijk moet u de workloadvereisten, het ontwerp of de implementatie wijzigen of het infrastructuuraanbod wijzigen.

Wanneer u de verplichtingen van het platformteam met betrekking tot organisatierichtlijnen en de verplichtingen van uw workloadteam begrijpt, kunt u de workloadvereisten communiceren met realistische verwachtingen en aanbevelingen.

Algemene workloadvereisten communiceren

Elk platformpartnerschap is anders, maar de volgende gebieden zijn veelvoorkomende onderwerpen in gesprekken met gedeelde verantwoordelijkheid:

  • Nalevings- en wettelijke vereisten
  • Netwerkspecifieke informatie, zoals de noodzaak van statische IP-adressen voor inkomend verkeer of uitgaande IP-adressen
  • Waarneembaarheidsvereisten voor effectieve live-site-triage
  • Prestatievereisten, zoals netwerkdoorvoer, beschikbaarheid van cloudresources of regionale beschikbaarheid
  • Verwachtingen voor openbare internettoegang vanuit het perspectief van uitgaand verkeer en inkomend verkeer
  • Serviceniveaudoelstellingen (SLO's) of SLA's die worden aangeboden aan de gebruikers van de workload
  • De beschikbaarheid van technische ondersteuning

Zoeken naar uniforme overwinningen

Gedeelde verantwoordelijkheid gaat niet alleen over compromissen, beperkingen en compromissen. Platformteams hebben vaak zeer gespecialiseerde vaardigheden en toegewezen budgetten die verder kunnen gaan dan wat een individueel workloadteam kan ondersteunen. Bekijk de volgende voorbeelden.

Beveiligingsspecialisten. Uw workload heeft mogelijk een veilige ontwikkelingslevenscyclus. Als een gecentraliseerd beveiligingsteam veilige ontwikkelingstaken op schaal in uw organisatie uitvoert, kan het routinematige penetratietests uitvoeren die uw inspanningen te boven gaan. Het kan ook helpen bij het plannen en uitvoeren van een strategie voor het reageren op incidenten.

Richtlijnen voor bedrijfsarchitectuur. U kunt tijd en moeite besparen als u bent afgestemd op de patronen en procedures van een architectuurteam van een onderneming, omdat het team de processen al heeft gestroomlijnd. U kunt ook voorkomen dat er nieuwe bewerkingen worden uitgevoerd als een oplossing niet mogelijk is binnen het partnerschap zonder onderhandeling.

Grote uitgaven voor tickets. Platformteams hosten vaak onderdelen of services die te duur zijn of te uitgebreid worden beheerd voor een individueel workloadteam. Platformteams kunnen zich deze onderdelen en services veroorloven omdat ze de kosten verdelen over workloads.

Vaak worden deze services of gecentraliseerde platforms aangeboden als een showback, zodat ze helpen om de workloadkosten geoptimaliseerd te houden. En wanneer ze worden aangeboden als terugstorting, zijn ze vaak goedkoper vanwege schaalvoordelen en centralisatie.

Platformteams bieden vaak selfserviceopties voor workloadteams voor verschillende activiteiten. Bijvoorbeeld:

  • Een documentatieopslagplaats bieden voor zelfgestuurd onderwijs
  • Onboarding naar kostenbeheer via specifieke resourcetags
  • Abonnementen aanbieden via een formeel proces voor het kopen van abonnementen

Verken selfserviceopties die mogelijk geschikt zijn voor uw workload.

Deel successen en uitdagingen

Gedeelde verantwoordelijkheid met andere teams betekent ook dat successen en uitdagingen van een workload worden gedeeld. Wanneer uw workload aan zijn verplichtingen voldoet en de beoogde waarde krijgt, deelt u die met uw partnerteams. Vertel hen hoe ze hebben bijgedragen aan het succes van de workload. Wanneer uw workload niet aan de verplichtingen voldoet, deelt u wat niet werkt en werkt u samen en herkalibreert u om weer op schema te komen.

Platformteams hebben ook verplichtingen en succescriteria. U moet van uw partners verwachten dat ze u vertellen of uw workload goed werkt met een aanbieding of dat deze het risico loopt om een luidruchtige buurman te worden.

Streven naar continue verbetering

Doorlopende verbetering is een thema voor alle Well-Architected Framework-pijlers. Neem een progressieve houding aan. U kunt te maken krijgen met nieuwe benaderingen van bestaande problemen, nieuwe technologie gebruiken, nieuwe vereisten aanpakken of onder nieuwe beperkingen werken. Naarmate uw workload in de loop van de tijd toeneemt, kunt u dezelfde mindset verwachten van uw partnerteams. Elke verbeteringsmogelijkheid betekent echter ook veranderingen en moet worden ondersteund door een goed beheerproces.

Workloadteams hebben de verplichting om te communiceren met platformteams over voorgestelde wijzigingen in de workloadvereisten die van invloed kunnen zijn op de services van het platformteam. Op dezelfde manier zijn platformteams verplicht om hun workloadpartners op te nemen in veranderingsbeheerprocessen en de impactvolle platformwijzigingen duidelijk te communiceren. Stel een regelmatig communicatieritme met partners tot stand om meer te weten te komen over en te delen hoe een product zich ontwikkelt.

Een succesvol resultaat behalen

Workloads hebben veel verwachtingen van gebruikers, aandeelhouders, regelgevende instanties, werknemers, het center of excellence en chief experience officers. Verwachtingen kunnen het richtingskompas laten draaien. Het Well-Architected Framework biedt duidelijkheid met betrekking tot het ontwerp en de implementatie door expliciete rationalisaties te bieden voor architectuurbeslissingen om een succesvol resultaat te bereiken. Ontwikkel een succesvolle workload en deel dat succes met uw organisatie.