Ontwerpprincipes voor Azure-landingszones

De referentiearchitectuur van de Azure-landingszone is universeel van toepassing op elk proces of implementatie van een Azure-landingszone. Bij de basis van de architectuur dienen een set kernontwerpprincipes als kompas voor latere ontwerpbeslissingen in kritieke technische domeinen.

De principes zijn opzettelijk aspiratief, om u te helpen bij het streven naar een optimaal ontwerp van de doelarchitectuur. Als u ervoor kiest om een implementatie te implementeren die een referentiearchitectuur voor een Azure-landingszone is of een versie van de basis van de landingszone op ondernemingsniveau, bouwt u voort op de architectuur door de ontwerpprincipes in dit artikel toe te passen.

Gebruik deze principes in uw implementatie als een nuttige handleiding om de voordelen van cloudtechnologieën te realiseren. Deze cloudgerichte of cloudeigen benadering vertegenwoordigt manieren van werken en technische opties voor uw organisatie die verouderde technologiemethoden doorgaans niet bieden.

Maak uzelf vertrouwd met deze principes om meer inzicht te krijgen in hun impact en de compromissen die verband houden met afwijkingen.

Impact van ontwerpdeviaties

Er kunnen geldige redenen zijn om af te wijken van de ontwerpprincipes. Organisatievereisten kunnen bijvoorbeeld specifieke resultaten of benaderingen dicteren voor het ontwerpen van een Azure-omgeving. In dergelijke gevallen is het belangrijk om inzicht te hebben in de impact die de afwijking heeft op het ontwerp en toekomstige bewerkingen. Houd zorgvuldig rekening met de compromissen die elk principe schetst.

Wees in de regel voorbereid op het evenwicht tussen vereisten en functionaliteit. Uw traject naar een conceptuele architectuur ontwikkelt zich in de loop van de tijd naarmate de vereisten veranderen en u leert van uw implementatie. Als u bijvoorbeeld preview-services gebruikt en afhankelijk van serviceschema's, kunnen technische obstakels tijdens de ingebruikname worden verwijderd.

Democratisering van abonnementen

Democratisering van abonnementen biedt een schaalbare manier om toepassingsmigraties en nieuwe toepassingsontwikkeling te versnellen. Met deze aanpak kunnen workloadteams onafhankelijk van elkaar Azure-abonnementen openen en beheren, terwijl ze binnen platformgovernance en operationele kaders blijven.

1. Abonnementen gebruiken als beheereenheden. Abonnementen vertegenwoordigen de basisgrens voor het organiseren en beheren van Azure-resources. Wijs abonnementen toe aan bedrijfseenheden ter ondersteuning van het ontwerp, de ontwikkeling, het testen en de migratie van workloads. Dankzij deze afstemming op bedrijfsbehoeften en -prioriteiten kunnen portfolioeigenaren en workloadteams sneller waarde leveren.

2. Gebruik abonnementen om toepassingsomgevingen te scheiden. Abonnementen moeten ook worden gebruikt voor het beheren en scheiden van omgevingen in de levenscyclus van softwareontwikkeling (SDLC), zoals ontwikkeling, testen en productie. Deze scheiding verbetert governance, vermindert risico's en biedt ondersteuning voor consistent workloadbeheer. Volg de richtlijnen voor het beheren van toepassingsontwikkelingsomgevingen in Azure-landingszones.

3. Schakel een verkoopproces voor selfserviceabonnementen in. Stel een proces in waarmee toepassings- en serviceteams abonnementen kunnen aanvragen en ontvangen met minimale wrijving. Een selfservicemodel of bijna selfservicemodel vermindert vertragingen die worden veroorzaakt door handmatige goedkeuringen en complexe zakelijke afmeldingen. Volg de richtlijnen in abonnementsverkoop om de inrichting te stroomlijnen en innovatie te versnellen.

4. Bied meerdere abonnementstypen aan om verschillende vereisten te ondersteunen. Geef een reeks abonnementsproductlijnen op die zijn afgestemd op verschillende workloadscenario's. Dankzij deze flexibiliteit kunnen teams het meest geschikte abonnementstype kiezen voor hun behoeften. Raadpleeg algemene productlijnen voor verkoopautomaten voor abonnementen.

5. Ondersteuning voor abonnementen met een schaalbare beheergroephiërarchie. Gebruik een goed gedefinieerde hiërarchie van beheergroepen om effectief abonnementen op schaal te gebruiken, te beheren en te beveiligen. Deze hiërarchie maakt gecentraliseerde beleidsafdwinging en efficiënte organisatie met meerdere abonnementen mogelijk. Volg de aanbevolen hiërarchie- en abonnementsontwerpoverwegingen en aanbevelingen voor de Azure-landingszone om consistentie te garanderen.

Impact van afwijking

• Gedeeld beheer versus gecentraliseerde bewerkingen. Eén manier om dit principe te implementeren is door bewerkingen over te dragen aan bedrijfseenheden en workloadteams. Met deze hertoewijzing kunnen eigenaren van workloads meer controle en autonomie hebben over hun workloads, binnen de kaders van de platforminfrastructuur. Organisaties die centrale bewerkingen vereisen, willen mogelijk geen controle over productieomgevingen delegeren aan workloadteams of bedrijfseenheden. Deze organisaties moeten mogelijk het ontwerp van hun resourceorganisatie wijzigen om af te wijken van dit principe.

• Onjuiste uitlijning van het operationele model. Ontwerp van referentiearchitectuur voor Azure-landingszones gaat uit van een specifieke beheergroep en abonnementshiërarchie voor alle operations management-abonnementen. Deze hiërarchie is mogelijk niet afgestemd op uw bewerkingsbenadering. Naarmate uw organisatie groeit en zich ontwikkelt, kan uw operationele model veranderen. Het verplaatsen van resources naar afzonderlijke abonnementen kan leiden tot ingewikkelde technische migraties. Bekijk de richtlijnen uitlijnen voordat u een benadering doorvoert.

• Gebrek aan abonnementsverkoop en automatisering. Als u geen verkoopproces voor abonnementen en bijbehorende automatisering beschikbaar stelt, zullen toepassings- en serviceteams vertraagd worden in het leveren van waarde voor uw organisatie, terwijl abonnementen voor hen worden aangemaakt en geplaatst in de juiste beheergroep in de hiërarchie. Als het proces voor het ophalen van nieuwe abonnementen ingewikkeld is en lang duurt, kunnen toepassings- en serviceteams ervoor kiezen om zelf abonnementen te maken via alternatieve factureringsaccounts en misschien ook in niet-beheerde of beheerde Microsoft Entra-tenants, wat betekent dat schaduw-IT nu bestaat.

Beleidsgestuurde governance

Gebruik Azure Policy om kaders te bieden en ervoor te zorgen dat de toepassingen die u implementeert, voldoen aan de beveiligings-, governance- en regelgevingscontroles van uw organisatie die agnostisch zijn voor implementatie- en configuratiehulpprogramma's. Azure Policy biedt platformteams de vereiste hulpprogramma's voor het implementeren, afdwingen, controleren en beheren van Bewerkingen en configuraties van Azure-besturings- en gegevensvlakken. Hierdoor kunnen de abonnementen worden ge democratiseerd, idealiter via een selfserviceproces, aan toepassings- en serviceteams, zodat ze snel bedrijfswaarde voor de organisatie kunnen leveren.

Raadpleeg beleidsgestuurde kaders gebruiken voor meer informatie over het gebruik van Azure Policy.

Impact van afwijking

Verhoogde operationele en beheeroverhead. Als u Azure Policy niet gebruikt om kaders in uw omgeving te maken, verhoogt u de operationele en beheeroverhead voor het onderhouden van naleving. Met Azure Policy kunt u de gewenste nalevingsstatus in uw omgeving beperken en automatiseren.

Eén besturings- en beheervlak

Vermijd afhankelijkheid van abstractielagen, zoals door de klant ontwikkelde portals of hulpprogramma's. Het is raadzaam om een consistente gebruikerservaring te hebben voor zowel centrale bewerkingen als werklastbewerkingen. Azure biedt een uniform en consistent besturingsvlak dat van toepassing is op alle Azure-resources en inrichtingskanalen, ook wel Azure Resource Manager genoemd. Het besturingsvlak is onderhevig aan op rollen gebaseerd toegangsbeheer en beleidsgestuurde besturingselementen. U kunt dit Azure-besturingsvlak gebruiken om een gestandaardiseerde set beleidsregels en besturingselementen tot stand te brengen die van toepassing zijn op uw hele bedrijfsomgeving.

Impact van afwijking

Verbeterde integratiecomplexiteit. Een multivendor-benadering voor besturings- en beheervlakken kan de complexiteit van integratie en functieondersteuning introduceren. Het vervangen van individuele componenten om een "best of breed" ontwerp of hulpmiddelen voor multivendor-operaties te bereiken heeft beperkingen en kan onbedoelde fouten veroorzaken door inherente afhankelijkheden.

Als u een bestaande investering in hulpprogramma's naar bewerkingen, beveiliging of governance brengt, bekijkt u de Azure-services en eventuele afhankelijkheden.

Applicatiegericht servicemodel

Richt u op toepassingsgerichte migraties en ontwikkeling, in plaats van pure lift-and-shift-migraties van infrastructuur, zoals het verplaatsen van virtuele machines. Ontwerpkeuzen mogen geen onderscheid maken tussen oude en nieuwe toepassingen, IaaS-toepassingen (Infrastructure as a Service) of PaaS-toepassingen (Platform as a Service).

Ongeacht het servicemodel moet u streven naar een veilige omgeving voor alle toepassingen die u implementeert op het Azure-platform.

Impact van afwijking

• Verhoogde complexiteit van governancebeleid. Als u werkbelastingen anders segmenteert dan de implementatieopties voor de beheergroephiërarchie, verhoogt u de complexiteit van governancebeleid en toegangsbeheerstructuren die uw omgeving beheren. Voorbeelden zijn afwijking van de organisatiehiërarchiestructuur of groepering per Azure-service.

• Verhoogde operationele overhead. Dit compromis introduceert het risico op onbedoelde duplicatie van beleid en uitzonderingen, wat leidt tot operationele en beheeroverheads.

• Dev/Test/Production is een andere veelgebruikte benadering die organisaties overwegen. Voor meer informatie, zie Hoe gaan we om met ontwikkelings-, test- en productieworkload-landingszones in de Azure-landingszone-architectuur.

Uitlijning met systeemeigen Azure-ontwerp en roadmaps

Gebruik waar en waar mogelijk systeemeigen platformservices en -mogelijkheden van Azure. Deze aanpak moet worden afgestemd op roadmaps van het Azure-platform om ervoor te zorgen dat er nieuwe mogelijkheden beschikbaar zijn in uw omgevingen. Roadmaps voor Azure-platformen moeten helpen bij het informeren van de migratiestrategie en het conceptuele traject van de Azure-landingszone.

Impact van afwijking

Verbeterde integratiecomplexiteit. Als u oplossingen van derden in uw Azure-omgeving introduceert, kunt u een afhankelijkheid van deze oplossingen maken om functieondersteuning en integratie met eigen Azure-services te bieden.

Soms is het onvermijdelijk om bestaande investeringen in oplossingen van derden in een omgeving te brengen. Houd rekening met dit principe en de bijbehorende afwegingen zorgvuldig om te voldoen aan uw vereisten.

Volgende stappen

Organisaties kunnen zich in verschillende fasen van hun cloudtrajecten bevinden wanneer ze deze richtlijnen bekijken. Daarom kunnen de vereiste acties en aanbevelingen voor de voortgang van de voorgaande resultaten variëren. Bekijk het traject naar de doelarchitectuur om inzicht te krijgen in de beste volgende acties voor uw cloudimplementatiefase.

Als u de juiste implementatieoptie voor Azure-landingszones wilt kiezen, moet u de ontwerpgebieden van de Azure-landingszone begrijpen.