Ontwerpprincipes voor Azure-landingszones
De conceptuele architectuur van de Azure-landingszone is universeel van toepassing op elk azure-landingszoneproces of -implementatie. Aan de basis van de architectuur dient een set kernprincipes voor ontwerp als kompas voor latere ontwerpbeslissingen in kritieke technische domeinen.
De principes zijn opzettelijk aspiratief, om u te helpen streven naar een optimaal ontwerp van de doelarchitectuur. Als u ervoor kiest om een implementatie te implementeren die een Azure-landingszoneversneller is, of een versie van de codebasis van de landingszone op ondernemingsniveau, bouwt u voort op de architectuur door de ontwerpprincipes toe te passen die in dit artikel worden beschreven.
Gebruik deze principes in uw implementatie als een nuttige handleiding om de voordelen van cloudtechnologieën te realiseren. Deze cloudgeoriënteerde 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 afwegingen 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 van de afwijking op het ontwerp en toekomstige bewerkingen. Overweeg zorgvuldig de compromissen die elk principe beschrijft.
Als algemene regel moet u voorbereid zijn op het afwegen van vereisten en functionaliteit. Uw reis 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 en afhankelijk van serviceroadmaps gebruikt, kunnen technische obstakels tijdens de ingebruikname worden verwijderd.
Democratisering van abonnementen
Gebruik abonnementen als beheereenheden en schaal om toepassingsmigraties en de ontwikkeling van nieuwe toepassingen te versnellen. Abonnementen afstemmen op zakelijke behoeften en prioriteiten om bedrijfsgebieden en portfolioeigenaren te ondersteunen. Abonnementen bieden aan bedrijfseenheden ter ondersteuning van het ontwerp, de ontwikkeling en het testen van nieuwe workloads en de migratie van bestaande workloads.
Om de organisatie te helpen effectief op schaal te werken, moet u een abonnement met een geschikte hiërarchie van beheergroepen ondersteunen. Deze hiërarchie maakt efficiënt abonnementsbeheer en organisatie mogelijk.
Tip
Zie de recente YouTube-video Azure Landing Zones - Hoeveel abonnementen moet ik gebruiken in Azure? voor meer informatie over de democratisering van abonnementen.
Impact van deviatie
Gedecentraliseerde versus gecentraliseerde bewerkingen. Een manier om dit principe te implementeren, is de overgang van bewerkingen naar bedrijfseenheden en workloadteams. Met deze hertoewijzing hebben eigenaren van workloads meer controle en autonomie over hun workloads, binnen de kaders van de platformbasis. Organisaties die centrale bewerkingen vereisen, willen het beheer van productieomgevingen mogelijk niet 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 bedrijfsmodel. Bij het ontwerp van de conceptuele architectuur van de Azure-landingszone wordt uitgegaan van een specifieke beheergroep en abonnementshiërarchie voor alle operations management-abonnementen. Deze hiërarchie is mogelijk niet afgestemd op uw operationele model. 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 voor uitlijnen voordat u een benadering doorvoert.
Governance op basis van beleid
Gebruik Azure Policy om kaders te bieden en ervoor te zorgen dat de toepassingen die u implementeert, voldoen aan het platform van uw organisatie. Azure Policy biedt toepassingseigenaren onafhankelijkheid en een veilig, onbelemmerd pad naar de cloud.
Zie Beleidgestuurde kaders goedkeuren voor meer informatie.
Impact van deviatie
Verhoogde operationele en beheeroverhead. Als u geen beleidsregels gebruikt om kaders te maken binnen uw omgeving, verhoogt u de operationele en beheeroverhead voor het handhaven van naleving. Azure Policy helpt u de gewenste nalevingsstatus binnen uw omgeving te beperken en te automatiseren.
Eén besturings- en beheervlak
Vermijd afhankelijkheid van abstractielagen, zoals door de klant ontwikkelde portals of hulpprogramma's. Het is het beste om een consistente ervaring te hebben voor zowel centrale bewerkingen als workloadbewerkingen. Azure biedt een geïntegreerd en consistent besturingsvlak dat van toepassing is op alle Azure-resources en inrichtingskanalen. Het besturingsvlak is onderhevig aan op rollen gebaseerde toegangs- en beleidsgestuurde besturingselementen. U kunt dit Azure-besturingsvlak gebruiken om een gestandaardiseerde set beleidsregels en besturingselementen op te stellen die van toepassing zijn op uw hele bedrijfsomgeving.
Impact van deviatie
Verhoogde integratiecomplexiteit. Een multivendor-benadering van besturings- en beheervlakken kan leiden tot complexiteit van integratie en functieondersteuning. Het vervangen van afzonderlijke onderdelen voor een 'best of breed'-ontwerp of hulpprogramma's voor multivendor-bewerkingen heeft beperkingen en kan onbedoelde fouten veroorzaken vanwege inherente afhankelijkheden.
Als u een bestaande investering in hulpprogramma's wilt gebruiken voor bewerkingen, beveiliging of governance, bekijkt u de Azure-services en eventuele afhankelijkheden.
Toepassingsgericht 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 kunt u een veilige omgeving bieden voor alle toepassingen die u op het Azure-platform implementeert.
Impact van deviatie
Meer complexiteit van governancebeleid. Als u workloads op een andere manier segmenteert dan de implementatieopties voor de beheergroephiërarchie, verhoogt u de complexiteit van het governancebeleid en de toegangsbeheerstructuren die van toepassing zijn op uw omgeving. Voorbeelden hiervan zijn afwijkingen van de organisatiehiërarchiestructuur of groepering per Azure-service.
Verhoogde operationele overhead. Deze afweging brengt het risico met zich mee van onbedoelde duplicatie van beleid en uitzonderingen, waardoor operationele en beheeroverheads worden verhoogd.
Dev/Test/Production is een andere algemene benadering die organisaties overwegen. Zie How do we handle 'dev/test/production' workload landing zones in Azure landing zone architecture (Hoe verwerken we 'dev/test/production'-landingszones in de architectuur van azure-landingszones) voor meer informatie.
Afstemming met azure-systeemeigen ontwerp en roadmaps
Gebruik waar mogelijk azure-systeemeigen platformservices en -mogelijkheden. Deze benadering moet in lijn worden gebracht met roadmaps voor het Azure-platform om ervoor te zorgen dat er in uw omgevingen nieuwe mogelijkheden beschikbaar zijn. Azure-platformroadmaps moeten helpen bij de migratiestrategie en het conceptuele traject van de Azure-landingszone.
Impact van deviatie
Verhoogde integratiecomplexiteit. Het introduceren van oplossingen van derden in uw Azure-omgeving kan een afhankelijkheid van deze oplossingen creëren om functieondersteuning en integratie met eigen Azure-services te bieden.
Soms is het onontkoombaar om bestaande oplossingen van derden naar een omgeving te brengen. Overweeg dit principe en de bijbehorende compromissen zorgvuldig om af te stemmen op uw vereisten.
Volgende stappen
Organisaties bevinden zich mogelijk in verschillende fasen van hun cloudtrajecten wanneer ze deze richtlijnen bekijken. Daarom kunnen de vereiste acties en aanbevelingen voor de voortgang naar de voorgaande resultaten variëren. Bekijk de reis 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, begrijpt u de ontwerpgebieden voor Azure-landingszones.