Designprinciper för Azure-landningszoner
Den konceptuella arkitekturen för Azure-landningszoner tillämpas universellt på alla processer eller implementeringar av landningszoner. I grunden för arkitekturen finns en uppsättning grundläggande designprinciper som fungerar som en kompass för efterföljande designbeslut inom kritiska tekniska domäner.
Principerna hjälper dig att sträva efter en optimal design av målarkitekturen. Om du väljer att distribuera 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 här.
Att använda dessa principer som en del av implementeringen fungerar som en användbar guide för att förverkliga fördelarna med molntekniker. Det här molnorienterade perspektivet, som ofta kallas molnbaserat, representerar sätt att arbeta och tekniska alternativ för din organisation som äldre teknikmetoder vanligtvis inte erbjuder.
Påverkan av designavvikelser
Det kan finnas giltiga skäl att avvika från principerna, till exempel när det gäller Tailwind Traders. Organisatoriska krav kan diktera specifika resultat eller metoder för att utforma en Azure-miljö. I dessa fall är det viktigt att förstå vilken inverkan avvikelsen kommer att ha på designen och framtida åtgärder. Överväg noggrant de kompromisser som beskrivs för varje princip.
Som en allmän regel bör du vara beredd att balansera krav och funktioner. Din resa till den konceptuella arkitekturen kommer att utvecklas med tiden när kraven ändras och du lär dig av implementeringen. Om du till exempel använder förhandsversionstjänster och använder beroenden i tjänstöversikter kan du ta bort tekniska blockerare under implementeringen.
Demokratisering av prenumeration
Använd prenumerationer som en hanteringsenhet 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 göra det möjligt för organisationen att fungera effektivt i stor skala stöder du en prenumeration med en lämplig hanteringsgruppshierarki. Det här stödet gör att prenumerationen kan hanteras och organiseras effektivt.
Avvikelsens inverkan
En metod för att implementera den här principen är att decentralisera åtgärder genom att överföra dem till affärsenheter och arbetsbelastningsteam. Den här metoden gör det möjligt för arbetsbelastningsägare att ha mer kontroll och autonomi över sina arbetsbelastningar inom de skyddsräcken som plattformsgrunden har upprättat.
Kunder som behöver centraliserade åtgärder och som inte vill delegera kontrollen över produktionsmiljöer till arbetsbelastningsteam eller affärsenheter kan behöva ändra sin resursorganisationsdesign och avvika från den här principen.
Utformningen av den konceptuella arkitekturen för Azure-landningszoner förutsätter en specifik hanteringsgrupp och prenumerationshierarki för alla operations management-prenumerationer. Det här antagandet kanske inte överensstämmer med din driftsmodell.
Med den här avvikelsen kan din driftsmodell ändras när din organisation växer och utvecklas. Den här ändringen kan leda till en migrering av resurser till separata prenumerationer igen, följt av komplicerade tekniska migreringar. Innan du checkar in på en metod kan du läsa Riktlinjerna för Justering .
Principdriven styrning
Använd Azure Policy för att tillhandahålla skyddsräcken och säkerställa fortsatt efterlevnad av organisationens plattform och de program som distribueras till den. Azure Policy ger även programägare oberoende och en säker väg till molnet.
Avvikelsens inverkan
Genom att inte använda Azure Policy för att skapa skyddsräcken 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ö.
Som en del av designövervägandena kan du läsa om hur du använder Azure Policy i en implementering av landningszoner.
Enskild kontroll och hanteringsplan
Undvik beroende av abstraktionslager, till exempel kundutvecklade portaler eller verktyg. Vi rekommenderar starkt att du har en konsekvent upplevelse för både centrala åtgärder och arbetsbelastningsåtgärder.
Azure tillhandahåller ett enhetligt och konsekvent kontrollplan som omfattas av rollbaserad åtkomst och principdrivna kontroller. Detta gäller för alla Azure-resurser och etableringskanaler. Du kan använda Azure för att upprätta en standardiserad uppsättning principer och kontroller för att styra hela företagsegendomen.
Avvikelsens inverkan
Om du väljer en metod för flera leverantörer för att använda kontroll- och hanteringsplan kan det medföra komplexiteten i integrerings- och funktionsstöd. Att ersätta enskilda komponenter för att uppnå en "best of breed"-design eller verktyg för flera leverantörer kan ha begränsningar och orsaka oavsiktliga fel på grund av inbyggda beroenden.
För kunder som tar med sig en befintlig verktygsinvestering till drift, säkerhet eller styrning rekommenderar vi en granskning av Azure-tjänsterna och eventuella beroenden.
Programcentrerad tjänstmodell
Fokusera på programcentrerade migreringar och utveckling snarare än rena lift-and-shift-migreringar för infrastruktur, till exempel att flytta virtuella datorer. Designvalen 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 distribueras på Azure-plattformen.
Avvikelsens inverkan
Genom att segmentera arbetsbelastningar på ett sätt som skiljer sig från implementeringsalternativen för hanteringsgruppshierarkin kan du skapa en komplex princip- och åtkomstkontrollstruktur för att styra din miljö. Exempel är avvikelse från organisationshierarkistrukturen eller gruppering efter Azure-tjänst. Den här kompromissen medför risk för oavsiktlig principduplicering och undantag, vilket ökar drift- och hanteringskostnaderna.
En annan vanlig metod som kunderna överväger är användningen av landningszoner för utvecklings-/test-/produktionsarbetsbelastningar. Mer information finns i faq-frågan Hur hanterar vi landningszoner för "dev/test/production"-arbetsbelastningar i arkitektur i företagsskala?.
Anpassning till azure-intern design och översikter
Använd azure-inbyggda plattformstjänster och -funktioner när det är möjligt. Anpassa den här metoden till Azure-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-landningszoner.
Avvikelsens inverkan
Att introducera lösningar från tredje part i din Azure-miljö kan skapa ett beroende av dessa lösningar för att tillhandahålla funktionsstöd och integrering med Azure-tjänster.
Ibland är det oundvikligt att föra in befintliga tredjepartslösningsinvesteringar i en miljö. Tänk på den här principen och dess kompromisser noggrant, i enlighet med dina krav.
Rekommendationer
Var beredd på att kompromissa med funktioner, eftersom det är osannolikt att allt kommer att krävas på dag ett. Använd förhandsversionstjänster och hämta beroenden i tjänstöversikter för att kunna avlägsna tekniska hinder.
Tänk på att inte alla aspekter av den önskade driftsmodellen är allmänt tillgängliga när du använder den här metoden.