Ontwerpprincipes voor Azure-landingszones
De conceptuele architectuur voor Azure-landingszones wordt universeel toegepast op elk proces of implementatie van landingszones. De basis van de architectuur is een set kernontwerpprincipes die dienen als kompas voor latere ontwerpbeslissingen in kritieke technische domeinen.
De principes helpen u bij het streven naar een optimaal ontwerp van de doelarchitectuur. Als u ervoor kiest om een Azure-landingszoneversneller of een versie van de basis voor landingszones op ondernemingsniveau te implementeren, bouwt u voort op de architectuur door de hier beschreven ontwerpprincipes toe te passen.
Het gebruik van deze principes als onderdeel van uw implementatie is een handige handleiding voor het realiseren van de voordelen van cloudtechnologieën. Dit cloudgeoriënteerde perspectief, ook wel cloudeigengenoemd, vertegenwoordigt manieren van werken en technische opties voor uw organisatie die oudere technologiemethoden doorgaans niet bieden.
Impact van ontwerpdeviaties
Er kunnen geldige redenen zijn om af te wijken van de principes, zoals in het geval van Tailwind Traders. Organisatievereisten kunnen specifieke resultaten of benaderingen dicteren bij het ontwerpen van een Azure-omgeving. In deze gevallen is het belangrijk om inzicht te krijgen in de impact die de afwijking heeft op het ontwerp en toekomstige bewerkingen. Houd zorgvuldig rekening met de compromissen die voor elk principe worden beschreven.
Wees in de regel voorbereid op het evenwicht tussen vereisten en functionaliteit. Uw reis naar de conceptuele architectuur zal zich na verloop van tijd ontwikkelen naarmate de vereisten veranderen en u leert van uw implementatie. Als u bijvoorbeeld preview-services gebruikt en afhankelijkheden van serviceroadmaps gebruikt, kunnen technische obstakels tijdens de ingebruikname worden verwijderd.
Democratisering van abonnementen
Gebruik abonnementen als een beheereenheid en schaal om de migratie van toepassingen en de ontwikkeling van nieuwe toepassingen te versnellen. Abonnementen afstemmen op bedrijfsbehoeften en -prioriteiten om bedrijfsgebieden en portfolioeigenaren te ondersteunen. Abonnementen bieden voor bedrijfseenheden ter ondersteuning van het ontwerp, de ontwikkeling en het testen van nieuwe workloads en de migratie van bestaande workloads.
Om de organisatie in staat te stellen effectief op schaal te werken, ondersteunt u een abonnement met een geschikte hiërarchie van beheergroepen. Met deze ondersteuning kan het abonnement efficiënt worden beheerd en georganiseerd.
Impact van afwijking
Een benadering voor het implementeren van dit principe is het decentraliseren van bewerkingen door ze over te zetten naar bedrijfseenheden en workloadteams. Met deze aanpak kunnen eigenaren van workloads meer controle en autonomie hebben over hun workloads binnen de kaders die de platformbasis heeft vastgesteld.
Klanten die gecentraliseerde bewerkingen nodig hebbenen die de controle van productieomgevingen niet willen delegeren aan workloadteams of bedrijfseenheden, moeten mogelijk hun resourceorganisatie wijzigen ontwerp en afwijken van dit principe.
Bij het ontwerp van de conceptuele architectuur voor Azure-landingszones wordt uitgegaan van een specifieke beheergroep en abonnementshiërarchie voor alle operations management-abonnementen. Deze aanname is mogelijk niet afgestemd op uw operationele model.
Met deze afwijking kan uw operationele model veranderen naarmate uw organisatie groeit en zich ontwikkelt. Deze wijziging kan leiden tot een migratie van resources in afzonderlijke abonnementen, gevolgd door ingewikkelde technische migraties. Raadpleeg de Align richtlijnen voordat u een aanpak kiest.
Beleidsgestuurde governance
Gebruik Azure Policy om kaders te bieden en ervoor te zorgen dat het platform van uw organisatie en de toepassingen die erop zijn geïmplementeerd, blijven voldoen. Azure Policy biedt ook toepassingseigenaren onafhankelijkheid en een veilig pad naar de cloud.
Impact van afwijking
Door Azure Policy niet te gebruiken 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.
Als onderdeel van uw ontwerpoverwegingen bekijkt u hoe u Azure Policy gebruikt in een implementatie van een landingszone.
Eén besturings- en beheervlak
Vermijd afhankelijkheid van abstractielagen, zoals door de klant ontwikkelde portals of hulpprogramma's. We raden een consistente ervaring sterk aan voor zowel centrale operaties als workload-operaties.
Azure biedt een geïntegreerd en consistent besturingsvlak dat onderhevig is aan op rollen gebaseerde toegang en beleidsgestuurde besturingselementen. Dit geldt voor alle Azure-resources en inrichtingskanalen. U kunt Azure gebruiken om een gestandaardiseerde set beleidsregels en besturingselementen tot stand te brengen voor het beheren van de gehele bedrijfsomgeving.
Impact van afwijking
Het kiezen van een benadering van meerdere leveranciers voor het bedienen van besturings- en beheervlakken kan leiden tot complexiteit van integratie- en functieondersteuning. Het vervangen van afzonderlijke onderdelen voor het bereiken van een 'best of breed' ontwerp of bewerkingen van meerdere leveranciers kan beperkingen hebben en onbedoelde fouten veroorzaken vanwege inherente afhankelijkheden.
Voor klanten die een bestaande toolinginvestering naar operaties, beveiliging of governance brengen, adviseren we een evaluatie van de Azure-services en eventuele afhankelijkheden.
Applicatiegericht servicemodel
Focus op toepassingsgerichte migraties en ontwikkeling in plaats van pure lift-and-shift-migraties voor infrastructuur, zoals het verplaatsen van virtuele machines. De 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, streeft u ernaar om een veilige omgeving te bieden voor alle toepassingen die zijn geïmplementeerd op het Azure-platform.
Impact van afwijking
Door workloads te segmenteren op een manier die verschilt van de implementatieopties voor de hiërarchie van beheergroepen, kan een complexe structuur voor beleid en toegangsbeheer worden gemaakt om uw omgeving te beheren. Voorbeelden zijn afwijking van de organisatiehiërarchiestructuur of groepering per Azure-service. Dit compromis introduceert het risico op onbedoelde duplicatie van beleid en uitzonderingen, wat leidt tot operationele en beheeroverhead.
Een andere veelgebruikte benadering die klanten overwegen, is het gebruik van landingszones voor workloads voor ontwikkelen/testen/productie. Voor meer informatie, zie FAQ-vraag Hoe gaan we om met landingszones voor dev/test/productie workloads in een ondernemingsarchitectuur?.
Uitlijning met systeemeigen Azure-ontwerp en roadmaps
Gebruik waar mogelijk systeemeigen platformservices en -mogelijkheden van Azure. Lijn deze benadering af met roadmaps voor Azure-platformen 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 Azure-landingszones.
Impact van afwijking
Introductie van oplossingen van derden in uw Azure-omgeving kan een afhankelijkheid maken van deze oplossingen om functieondersteuning en integratie met 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 zijn compromissen zorgvuldig, in overeenstemming met uw vereisten.
Aanbevelingen
Wees voorbereid op het afruilen van functionaliteit, omdat het onwaarschijnlijk is dat alles nodig is op dag één. Gebruik preview-services en ga afhankelijkheden van serviceroadmaps aan om technische obstakels te verwijderen.
Houd er rekening mee dat niet alle aspecten van het gewenste operationele model algemeen beschikbaar zijn wanneer u deze aanpak gebruikt.