Designprinciper för Azure-landningszoner
Konceptuell arkitektur för Azure-landningszoner gäller universellt för alla processer eller implementeringar av Azure-landningszoner. I grunden för arkitekturen fungerar en uppsättning grundläggande designprinciper som en kompass för efterföljande designbeslut inom kritiska tekniska domäner.
Principerna är avsiktligt ambitiösa för att hjälpa dig att sträva efter en optimal design av målarkitekturen. Om du väljer att distribuera en implementering som är en Azure-landningszonaccelerator eller någon version av kodbasen för landningszoner i företagsskala bygger du vidare på arkitekturen genom att tillämpa de designprinciper som beskrivs i den här artikeln.
Använd dessa principer i implementeringen som en användbar guide för att dra nytta av fördelarna med molntekniker. Den här molnorienterade eller molnbaserade metoden representerar sätt att arbeta och tekniska alternativ för din organisation som äldre teknikmetoder vanligtvis inte erbjuder.
Bekanta dig med dessa principer för att bättre förstå deras inverkan och kompromisser som är associerade med avvikelse.
Påverkan av designavvikelser
Det kan finnas giltiga skäl att avvika från designprinciperna. Organisationskrav kan till exempel diktera specifika resultat eller metoder för att utforma en Azure-miljö. I sådana fall är det viktigt att förstå vilken inverkan avvikelsen har på designen och framtida åtgärder. Överväg noggrant de kompromisser som varje princip beskriver.
Som en allmän regel bör du vara beredd på att balansera krav och funktioner. Din resa till en konceptuell arkitektur utvecklas med tiden när kraven förändras och du lär dig av implementeringen. Om du till exempel använder förhandsversionstjänster och beroende på tjänstöversikter kan du ta bort tekniska blockerare under implementeringen.
Demokratisering av prenumeration
Använd prenumerationer som hanteringsenheter och skala för att påskynda programmigreringar och ny programutveckling. Anpassa prenumerationer efter affärsbehov och prioriteringar för att stödja affärsområden och portföljägare. Tillhandahålla prenumerationer på affärsenheter för att stödja design, utveckling och testning av nya arbetsbelastningar och migrering av befintliga arbetsbelastningar.
För att hjälpa organisationen att fungera effektivt i stor skala kan du stödja en prenumeration med en lämplig hanteringsgruppshierarki. Den här hierarkin möjliggör effektiv prenumerationshantering och organisation.
Tips
Mer information om demokratisering av prenumerationer finns i den senaste YouTube-videon Azure Landing Zones – Hur många prenumerationer ska jag använda i Azure?
Påverkan av avvikelse
Decentraliserade kontra centraliserade åtgärder. Ett sätt att implementera den här principen är att övergå till affärsenheter och arbetsbelastningsteam. Med den här omtilldelningen kan arbetsbelastningsägare få mer kontroll och självständighet över sina arbetsbelastningar, inom plattformsgrundens skyddsmekanismer. Organisationer som kräver centrala åtgärder kanske inte vill delegera kontrollen över produktionsmiljöer till arbetsbelastningsteam eller affärsenheter. Dessa organisationer kan behöva ändra sin resursorganisationsdesign för att avvika från den här principen.
Justering av driftsmodell. Konceptuell arkitekturdesign för Azure-landningszoner förutsätter en specifik hanteringsgrupps- och prenumerationshierarki för alla prenumerationer för drifthantering. Den här hierarkin kanske inte överensstämmer med din driftsmodell. När din organisation växer och utvecklas kan din driftsmodell ändras. Att flytta resurser till separata prenumerationer kan leda till komplicerade tekniska migreringar. Läs riktlinjerna för Justering innan du genomför en metod.
Principdriven styrning
Använd Azure Policy för att tillhandahålla skyddsmekanismer och se till att de program som du distribuerar följer organisationens plattform. Azure Policy ger programägare oberoende och en säker, obehindrat väg till molnet.
Mer information finns i Använda principdrivna skyddsräcken.
Påverkan av avvikelse
Ökade drift- och hanteringskostnader. Om du inte använder principer för att skapa skyddsmekanismer i din miljö ökar du drift- och hanteringskostnaderna för att upprätthålla efterlevnaden. Azure Policy hjälper dig att begränsa och automatisera ditt önskade efterlevnadstillstånd i din miljö.
Enskild kontroll och hanteringsplan
Undvik beroende av abstraktionslager som kundutvecklade portaler eller verktyg. Det är bäst att ha en konsekvent upplevelse för både centrala åtgärder och arbetsbelastningsåtgärder. Azure tillhandahåller ett enhetligt och konsekvent kontrollplan som gäller för alla Azure-resurser och etableringskanaler. Kontrollplanet omfattas av rollbaserad åtkomst och principdrivna kontroller. Du kan använda det här Azure-kontrollplanet för att upprätta en standardiserad uppsättning principer och kontroller som styr hela företagets egendom.
Påverkan av avvikelse
Ökad integrationskomplexitet. En multivendormetod för kontroll- och hanteringsplan kan leda till integrering och funktioner som stöder komplexitet. Att ersätta enskilda komponenter för att uppnå en "best of breed"-design eller multivendoråtgärder har begränsningar och kan orsaka oavsiktliga fel på grund av inbyggda beroenden.
Om du lägger till en befintlig verktygsinvestering i drift, säkerhet eller styrning granskar du Azure-tjänsterna och eventuella beroenden.
Programcentrerad tjänstmodell
Fokusera på programcentrerade migreringar och utveckling i stället för rena lift and shift-migreringar av infrastrukturen, till exempel att flytta virtuella datorer. Designval bör inte skilja mellan gamla och nya program, IaaS-program (infrastruktur som en tjänst) eller PaaS-program (plattform som en tjänst).
Oavsett tjänstmodell bör du sträva efter att tillhandahålla en säker miljö för alla program som du distribuerar på Azure-plattformen.
Påverkan av avvikelse
Ökad komplexitet för styrningsprinciper. Om du segmenterar arbetsbelastningar på ett annat sätt än implementeringsalternativen för hanteringsgruppshierarkin ökar du komplexiteten i styrningsprinciper och strukturer för åtkomstkontroll som styr din miljö. Exempel är avvikelse från organisationens hierarkistruktur eller gruppering efter Azure-tjänst.
Ökade driftkostnader. Den här kompromissen medför en risk för oavsiktlig principduplicering och undantag, vilket ökar drift- och hanteringskostnaderna.
Dev/Test/Production är en annan vanlig metod som organisationer överväger. Mer information finns i Hur hanterar vi landningszoner för "dev/test/production"-arbetsbelastningar i Azure-landningszonarkitekturen.
Anpassning med azure-inbyggd design och översikter
Använd azure-interna plattformstjänster och -funktioner när det är möjligt. Metoden bör överensstämma med Azures plattformsöversikter för att säkerställa att nya funktioner är tillgängliga i dina miljöer. Azure-plattformsöversikter bör hjälpa till att informera migreringsstrategin och den konceptuella banan för Azure-landningszonen.
Påverkan av avvikelse
Ökad integrationskomplexitet. Genom att introducera lösningar från tredje part i din Azure-miljö kan du skapa ett beroende av dessa lösningar för att tillhandahålla funktionsstöd och integrering med azure-tjänster från första part.
Ibland är det ofrånkomligt att föra in befintliga tredjepartslösningar i en miljö. Överväg den här principen och dess kompromisser noggrant för att uppfylla dina krav.
Nästa steg
Organisationer kan vara i olika skeden av sina molnresor när de granskar den här vägledningen. Därför kan de åtgärder och rekommendationer som krävs för att gå vidare mot föregående resultat variera. Om du vill förstå de bästa nästa åtgärderna för din molnimplementeringsfas kan du gå igenom resan till målarkitekturen.
Om du vill välja rätt implementeringsalternativ för Azure-landningszoner kan du förstå designområdena för Azure-landningszoner.