Dela via

Upprätta vanliga produktrader för prenumerationsautomater

  • Artikel

Prenumerationsautomater hjälper organisationer att uppnå designprinciperna för prenumerationsdemokratisering i Azure-landningszoner , vilket är viktigt för konsekvent skalning, säkerhet och styrning av Azure-miljöer. Prenumerationsautomater hjälper också organisationer att anpassa sig till plattformstekniska principer. Mer information finns i Anta ett produkttänk och Ge utvecklare självbetjäning med skyddsmekanismer.

Många organisationer har svårt att ge sina programteam den flexibilitet de behöver för att leverera sina arbetsbelastningar och tjänster på ett effektivt sätt. Ett viktigt hinder är bristen på en standardiserad metod för prenumerationsautomater, vilket kan leda till förvirring, fördröjning och ineffektivitet.

I den här artikeln beskrivs hur plattformsteam kan etablera vanliga produktlinjer för prenumerationsautomater som tillgodoser olika programteams olika behov. Artikeln beskriver fördelarna med att erbjuda olika produktlinjer och innehåller exempel på vanliga scenarier som baseras på verkliga kunddistributioner. Du får också lära dig varför prenumerationsautomater inte har en "one size fits all"-design och varför du måste tillhandahålla olika produktlinjer till programteamen.

Följande diagram visar organisationen av hanteringsgrupper och prenumerationer i en Azure-miljö.

Ett diagram som visar organisationen av hanteringsgrupper och prenumerationer i en Azure-miljö.

Följande vägledning beskriver varför du kan behöva olika produktlinjer och beskriver produktlinjeexempel för kunder som använder Azure-landningszoner och prenumerationsautomater.

Dra nytta av olika produktlinjer

Prenumerationer som programteamen behöver för att leverera sina arbetsbelastningar och tjänster finns i många typer och format. Utanför programteamen kan din organisation ha andra krav som kräver användning av en Azure-prenumeration, till exempel olika efterlevnads- och datahanteringsregler eller arkitekturmönster.

När du bestämmer dig för organisationens metod för att utforma och implementera prenumerationsautomater kan du ställa följande frågor:

  • Vilka andra resurser ska plattformsteamet ta del av som en del av prenumerationsautomatprocessen?

  • Distribuerar du flera prenumerationer, till exempel en per miljö, som standard för varje programteam?

  • Ansluter du det virtuella ekernätverket till dina anslutningshubbar som standard för varje program?

  • Hur ska du strukturera rollbaserad åtkomstkontroll (RBAC) i varje prenumeration?

  • Hur ska du styra och kontrollera resurser och arkitekturformat, eller arketyper, som du använder i prenumerationer?

Du kan inte hantera alla program- och plattformsteams unika krav med någon enskild prenumerationstyp eller prenumerationsformat som du har. Plattformsteam måste ge programteam flexibilitet att välja mellan flera typer och typer av prenumerationer som teamet kan överföra till dem via ett självbetjäningssystem. Dessa typer av prenumerationer kallas produktrader.

Organisationer som endast tillhandahåller en "en storlek passar alla"-metoden för prenumerationsautomater begränsar ofta sina interna kunders flexibilitet. Bristande flexibilitet kan till exempel begränsa ett programteams arkitekturdesignval och potentiellt leda till kompromisser på grund av vad de har fått.

Därför måste plattformsteam tillhandahålla olika produktlinjer för att tillgodose organisationens behov. Den här flexibiliteten säkerställer att konsumenterna kan välja den produktlinje som bäst passar deras krav.

Hantera programmiljöer

Din organisation måste hantera programmiljöer för programteam som en del av dina processer och implementeringar av prenumerationsautomater. Du bör dock också ge flexibilitet så att programteamen kan hantera sina programmiljöer, till exempel dev/test/prod, hur de vill när de levererar program. Mer information finns i Miljöer, prenumerationer och hanteringsgrupper.

Vissa Azure-tjänster tillhandahåller inbyggda funktioner som hjälper till att isolera en miljö inom en enskild resursinstans i en enda Azure-prenumeration, till exempel Azure App Service med dess funktion för distributionsplatser. Det här exemplet tvingar programteam att använda separata prenumerationer, så att teamen inte kan dra nytta av den fullständiga funktionsuppsättningen med tjänster som Azure tillhandahåller. Separata prenumerationer kan också öka kostnaderna för programleverans, inklusive drift- och underhållskostnader.

Utforma vanliga produktrader för prenumerationsautomater

Nu när du förstår att plattformsteam måste tillhandahålla flera Typer och format för Azure-prenumerationer, eller produktlinjer, till konsumenter av deras Azure-plattform, beskriver det här avsnittet flera vanliga produktlinjer som du kan använda i olika branscher och länder eller regioner.

Ditt plattformsteam bör använda dessa vanliga produktrader för prenumerationsautomater som baslinje. Ditt team kan tillhandahålla flera alternativ till sina konsumenter direkt, vilket överensstämmer med principen för att prioritera kundernas plattformsteknik. Den här metoden ger interna kunder friheten att använda designprinciper för Azure-landningszoner och designområdesrekommendationer för att leverera sina arbetsbelastningar och tjänster och ger även Azure-plattformsstyrning.

Kommentar

Använd de här exemplen som utgångspunkt. Du kan anpassa och utöka dessa produktlinjer för att tillgodose organisationens behov.

Vanliga produktrader för prenumerationsautomater är:

  • Corp-ansluten: Arbetsbelastningar som kräver traditionell Ip-routningsanslutning i Layer-3 till andra program och lokala miljöer via anslutningsprenumerationen.

  • Online: Arbetsbelastningar som ansluter till andra program via moderna anslutningstjänster och arkitekturer, till exempel Azure Private Link eller interaktion via exponerade API:er eller slutpunkter från varje program.

  • Teknisk plattform: Arbetsbelastningar som skapar en plattform där du kan skapa andra program. Till exempel kan en Azure Kubernetes Service-flotta (AKS) med kluster som ett AKS-plattformsteam hanterar vara värd för andra program i sina AKS-kluster på uppdrag av andra programteam.

  • Delad programportfölj: Delade arbetsbelastningar mellan samma programteam för en gemensam uppsättning nära kopplade program. Du vill inte vara värd för programmen på egen hand eller med någon specifik arbetsbelastning.

  • Sandbox: Ett område där programteam kan skapa ett konceptbevis (PoC) eller en lägsta livskraftig produkt (MVP) och införa färre kontroller, så att teamet kan främja utveckling, uppfinningar och frihet att skapa bästa möjliga program från katalogen med tillgängliga Azure-tjänster.

Den corp-anslutna produktlinjen

Den corp-anslutna produktlinjen, även kallad en intern eller privat produktlinje, för prenumerationsautomater för programlandningszoner ger anslutning via traditionella Layer-3 IP-metoder. Du kan använda den här produktraden för att tillhandahålla anslutning mellan resurser som är:

  • I samma programlandningszon.

  • I olika corp-anslutna programlandningszoner via en virtuell Azure-brandvägg eller virtuell nätverksinstallation (NVA).

  • Lokalt eller i olika moln via Azure ExpressRoute eller VPN-anslutningar.

Organisationer som använder prenumerationsautomater använder ofta den här produktlinjen eftersom den överensstämmer med hur de flesta lokala miljöer fungerar idag. Du bör dock endast använda den corp-anslutna produktlinjen när du behöver det. Vi rekommenderar att du föredrar mer moderna molnbaserade metoder, till exempel produktlinjen Online, när du kan.

Dricks

Information om skillnader mellan corp- och onlinearbetsbelastningar finns i Vad är syftet med anslutnings-, corp- och onlinehanteringsgrupper ?.

Följande diagram visar ett exempel på produktraden för företagsanslutna prenumerationer. Du kan använda den här konfigurationen för en hub-and-spoke-nätverksmodell för att effektivt hantera nätverkstrafik och principer.

Diagram som visar ett exempel på produktraden för företagsanslutna prenumerationer.

När du ska använda den corp-anslutna produktlinjen

Använd den corp-anslutna produktlinjen när:

  • Du vill utföra rehost- och refaktormigreringar och programversioner baserat på de fem R:na för rationalisering.

  • Du vill börja din resa i Azure och är bekant med en liknande lokal arkitektur.

  • Du vill "lyfta och flytta" program till Azure.

  • Du vill förbättra säkerheten mellan arbetsbelastningar genom att isolera program till sina egna prenumerationer i landningszonen och gå mot principer för mikrosegmentering från nollförtroende utan att behöva göra om programmet så att det blir helt molnbaserat.

Notera dessa andra överväganden för den corp-anslutna produktlinjen:

  • Ditt plattformsteam kan skicka det virtuella nätverket till prenumerationen för programlandningszonen och peer-koppla det virtuella nätverket till det regionala virtuella hubbnätverket eller Azure Virtual WAN-hubben. Ditt team kan sedan använda ett IPAM-verktyg (IP Address Management) för att styra IP-adressallokeringen.

  • Plattformsteamen varuautomater vanligtvis inte undernät eller andra resurser i det virtuella nätverket. I stället tilldelar plattformsteamen dessa aktiviteter till programteamen så att de kan utforma sina programnätverk som de vill.

  • Plattformsteam använder en Azure-princip som har tilldelats till hanteringsgrupperna ovanför prenumerationen för att framtvinga önskat beteende, till exempel standardiserade nätverkssäkerhetsgrupper (NSG:er) som är kopplade till varje undernät. Programteamet ärver den här Azure-principen och kan inte redigera den. Den här metoden följer designprincipen för azure-landningszonen för prenumerationsdemokratisering.

Online-produktlinjen

Online-produktlinjen, även kallad en extern eller offentlig produktlinje, för prenumerationsautomater för programlandningszoner tillhandahåller inte anslutning via traditionella Layer-3 IP-metoder mellan resurser i andra programlandningszoner eller lokalt via ExpressRoute- eller VPN-anslutningar. Resurser i samma onlineprograms landningszonprenumeration kan använda virtuella nätverk för att kommunicera med varandra via Ip-metoder för Layer-3. Men de virtuella nätverken peerkopplas vanligtvis inte tillbaka till regionala anslutningshubbar eller andra programlandningszoner.

I stället kan du tillhandahålla anslutning via offentliga gränssnitt mellan resurser som är:

  • I olika programlandningszoner.

  • Lokalt.

  • I arbetsbelastningar som finns i olika moln.

Du kan skydda anslutningarna med nätverkskontroller, autentiseringsfunktioner och auktoriseringsfunktioner som exponeras av de olika PaaS-lösningar (plattform som en tjänst) som du använder för att skapa programmet.

Du kan använda Private Link-tjänsten och privata Azure-slutpunkter i och mellan onlineprograms landningszonprenumerationer för att aktivera och exponera privata, Layer 3-baserade anslutningar mellan program. Du kan också använda den här metoden mellan De PaaS-tjänster som du använder i programlandningszoner för att förhindra användning av dessa PaaS-tjänsters offentliga gränssnitt för säkerhets- eller regelkontroll.

Du kan också använda Private Link-tjänsten med privata slutpunkter för att exponera och publicera program som du är värd för i landningszoner för onlineprogram för att skapa anslutna programlandningszoner, lokala platser eller andra moln. Du kan placera privata slutpunkter i antingen corp-anslutna programlandningszoner eller direkt i anslutningshubbar, som sedan beviljar åtkomst till dessa privata slutpunkter via traditionella Layer-3-anslutningsmetoder som peering för virtuella nätverk, ExpressRoute-anslutningar eller VPN-anslutningar.

Tänk på produktlinjen för onlineprogramlandningszonen som isolerade öar. Som standard är de enda resurser som kan komma åt resurser i prenumerationen de resurser som du distribuerar i samma onlineprograms landningszonprenumeration. Som tidigare nämnts kan du sedan använda teknikerna i den här artikeln för att utöka anslutningen till andra programlandningszoner, lokala platser eller andra moln.

Dricks

Mer information om skillnaderna mellan corp- och onlinearbetsbelastningar finns i Vad är syftet med anslutnings-, corp- och onlinehanteringsgrupper ?.

Följande diagram visar ett exempel på en produktlinje för onlineprenumeration.

Diagram som visar ett exempel på produktraden för onlineprenumeration.

När du ska använda online-produktlinjen

Använd onlineproduktlinjen när du vill:

  • Omstrukturera, bygga om, återskapa och utföra migreringar och programversioner baserat på de fem R:na för rationalisering.

  • Ge programteamen en fullständigt demokratiserad programlandningszon att använda, även när det gäller nätverkskonfiguration.

  • Dra nytta av molnbaserade tjänster och arkitekturer.

  • Förbättra anpassningen avsevärt med principer för noll förtroende.

  • Använd den corp-anslutna produktlinjen, men det privata IP-adressutrymmet är inte tillgängligt eller begränsat.

Produktlinjen techplattform

Team som använder teknikplattformar, till exempel Azure VMware Solution eller Azure Virtual Desktop, bör implementera produktlinjen för teknikplattformen. Produktlinjen för den tekniska plattformen är i huvudsak en produktlinje för prenumerationsautomater som bättre passar höga tekniska krav. Du kan använda produktlinjen för teknikplattformen som värd för och hantera stora och komplexa arbetsbelastningar som vanligtvis är värdar för flera program för flera andra programteam i organisationen. Använd den här produktraden om ditt programteam endast hanterar programdelarna och inte de underliggande teknikplattformsdelarna.

Dricks

Tänk på följande exempel för att bättre förstå den här produktlinjen. Ett teknikplattformsteam, som ett AKS-team, syftar till att erbjuda AKS som en hanterad tjänst till andra programteam som behöver köra sina program på AKS-plattformen. AKS tekniska plattformsteam tillhandahåller hantering, underhåll, säkerhet och konfiguration av AKS. Så programteamet underhåller bara sitt program och distribuerar det på plattformen.

Du kan inkludera följande produkter i en produktlinje för teknikplattformen:

  • En App Service-miljö, vanligtvis via separata App Service-planer.

  • AKS, vanligtvis via namnområden i ett eller flera kluster.

  • Azure Virtual Machines på Azure VMware Solution-kluster eller -värdar.

  • Azure Virtual Desktop för att tillhandahålla virtuella skrivbord eller program till hela organisationen.

Du kan inkludera dessa produkter i antingen corp-anslutna eller online produktlinjer, beroende på kraven för den teknikplattform som ditt team vill tillhandahålla som en tjänst till andra programteam i din organisation.

Portfölj för delat program

Produktraden för den delade programportföljen för prenumerationsautomater för programlandningszoner är för arbetsbelastningar som inte behöver flera separata programlandningszonprenumerationer för enkla program som kan konstrueras från endast ett litet antal Azure-resurser.

Dina programteam och avdelningar kan använda den här produktraden som värd för flera små program eller delade komponenter, till exempel lagringskonton eller SQL-servrar. Teamen delar dessa komponenter mellan flera av sina egna program i en enda prenumeration eller ett litet antal prenumerationer.

Viktigt!

Ett vanligt team äger prenumerationer som du varuautomater under den här produktraden. Det här teamet hanterar den relaterade portföljen med program som du distribuerar i den här prenumerationen för den här produktraden. Använd inte den här produktraden för allmänna distributioner av orelaterade programarbetsbelastningar som har distinkta ägare av programportföljer.

Planera noggrant för att säkerställa kontinuerlig flexibilitet, åtkomstkontroll, styrning och underhåll om din organisation ändras till en enda prenumeration och använder resursgrupper för att delegera åtkomst.

Om du överväger resursgruppsdelegering i en enda prenumeration mellan flera team bör du tänka på följande innan du fattar ett slutgiltigt beslut:

Ytdiagram Att tänka på
Gemensamt ägarskap för relaterad programportfölj – Ha en gemensam ägare, till exempel en affärsenhet på en avdelning, som hanterar program för att förenkla ändringshanteringen så att den förblir inom godkännandeomfånget för samma entitet.

– Se till att arbetsbelastningar följer konsekventa principtilldelningar i prenumerationen, inklusive loggning, övervakning och säkerhet.
Regelefterlevnad – Använd IAM- och Azure-principer för att skapa prenumerationer för arbetsbelastningar som har krav på regelefterlevnad, inklusive National Institute of Standards and Technology (NIST), Center for Internet Security (CIS), Payment Card Industry Security Standards Council (PCI SSC), branschkrav och regionala krav. Mer information finns i Skräddarsy Azure-landningszoner.

– Skapa prenumerationer för arbetsbelastningar som använder sekretess- och datahanteringskrav för styrning. Enskilda prenumerationer minskar åtkomsten.
Azure Policy Omfång för Azure-principer för hanteringsgrupper, prenumerationer, resursgrupper och resurser. Tilldela Azure-principer på hög omfångsnivå för effektiv styrning när du distribuerar resurser i resursgrupper.

Tänk på följande begränsningar när du hanterar Azure Policy på resursgruppsomfångsnivå:
– Ökar hanteringskostnaderna för att skapa Azure Policy-tilldelningar när du lägger till nya resursgrupper i prenumerationer

– Ökar arbetsbelastningen när du hanterar ändringar i principtilldelningar

– Ökar säkerhets- och styrningsluckorna när du inte omedelbart tilldelar principer till resursgrupper

– Minskar möjligheten att samla in efterlevnadsstatus i stora omfattningar, till exempel hanteringsgrupper och prenumerationer
Prenumerationsgränser – Kontrollera gränserna för att säkerställa att program inte når hårda gränser som förhindrar tillväxt. Varje prenumeration har mjuka och hårda gränser för Azure-tjänster.

– Skapa separata prenumerationer för program som förväntar sig stora tillväxtmönster som uppfyller prenumerationsgränserna.

– Dela inte prenumerationer med programteam från olika affärsenheter eller avdelningar för att förhindra störningar i grannens problem.
Azure-tjänster och funktionsjustering Du kan distribuera tjänster som tillhandahåller grundläggande Primitiva Azure-tjänster, till exempel virtuella datorer, virtuella nätverk och enkla PaaS-tjänster, i en enda resursgrupp. Men komplexiteten i moderna sammansatta erbjudanden kan kräva att du distribuerar dessa mer komplexa tjänster utanför gränserna för en enskild resursgrupp. Använd andra demokratiserade prenumerationsmetoder som beskrivs tidigare i den här artikeln för dessa distributionsscenarier.
Endast plattformsteam kan skapa resursgrupper När du delar en prenumeration mellan olika programteam mellan affärsenheter eller avdelningar kan du begränsa teamets möjlighet att skapa nya resursgrupper i den delade prenumerationen.

Den här begränsningen begränsar resursgruppens utbredning. Endast plattformsteamet kan skapa och styra nya resursgrupper.

Den här metoden ökar komplexiteten i RBAC-tilldelningar och ökar beroendet av plattformsteam för att hantera programdistributioner, vilket kan hindra programteamens flexibilitet och egenmakt.

Du kan placera de prenumerationer som du får i produktraden för den delade programportföljen under antingen Corp- eller Online-hanteringsgrupper. Den här metoden överensstämmer med standardhierarkin för Azure-landningszoner. Du kan också placera prenumerationerna under nya hanteringsgrupper om organisationens hanteringsgruppshierarki följer riktlinjerna i Anpassa Arkitekturen för Azure-landningszoner för att uppfylla kraven.

I följande diagram visas ett exempel på produktraden för en delad programportföljsprenumeration.

Diagram som visar ett exempel på produktraden för en delad programportföljsprenumeration.

Använd produktraden för den delade programportföljen om:

  • Ditt programteam måste leverera flera små resurser eller komponenter som deras program delar, men komponenterna passar inte direkt i någon av de dedikerade programlandningszonerna.

  • Du har resurser eller komponenter som du behöver dela mellan program på samma avdelning, men komponenterna passar inte direkt i någon av de dedikerade programlandningszonerna.

  • Teknikplattformsteam vill vara värdar för stora, delade tjänster som hanteras, till exempel AKS, Azure Virtual Desktop och Azure VMware Solution, så att andra programteam kan använda eller vara värdar för sina program på tjänsterna.

Begränsat läge

Använd sandbox-produktraden för prenumerationsautomater för programlandningszoner för att tillhandahålla säkra, lättstyrda och synliga testområden för att skapa pocs eller MVP:er i Azure.

Mer information finns i Sandbox-miljöer för landningszoner och Hantera programutvecklingsmiljöer i Azure-landningszoner.

Sandbox-miljön är ofta tidsbegränsad eller budgetbegränsad, vilket innebär att de har en tidsgräns eller budgetgräns. I dessa fall måste du antingen utöka eller ta bort och inaktivera sandbox-miljön.

Om din organisation inte tillhandahåller en sandbox-produktlinje för programteam eller andra för att testa och experimentera med tjänster i Azure kan team använda skugg-IT-konfigurationer . I så fall kan din organisation ha svårt att tillhandahålla rapportering och synlighet och tillämpa styrning på prenumerationer som företagsanvändare skapar utanför plattformsteamets kontroll och tillsyn.

Ditt plattformsteam måste tillhandahålla lättillgänglig, helst självbetjäning och automatiskt godkänd åtkomst till sandbox-prenumerationer för organisationens användare och team. Ge användare och team åtkomst till en miljö som ditt plattformsteam kan visa och styra för att förhindra skugg-IT-miljöer som plattformsteamet inte kan komma åt eller kontrollera, vilket skapar risker.

Sandbox-miljöer följer ofta nätverkskonfigurationsmetoden för online-produktlinjeprenumerationer eftersom du inte peerkopplar dem till andra virtuella nätverk utanför sandbox-miljöns prenumerationsgräns. Sandbox-miljöer har också ofta extra kontroller för att förhindra hybridanslutning till lokala platser eller andra platser. Använd dessa kontroller så att okända källor inte kan exfiltera data från sandbox-miljöer till ej godkända platser. Du kan använda en Azure-princip för att framtvinga dessa kontroller.

Precis som produktlinjerna för den delade programportföljen och teknikplattformen kan du också dela produktlinjen för sandbox-miljön mellan team på samma avdelning med samma överväganden. Skapa inte en enskild sandbox-prenumeration och dela den mellan team via resursgrupper. Skapa i stället ytterligare sandbox-prenumerationer.

Använd sandbox-produktlinjen om du behöver tillhandahålla en säker, säker och styrd Azure-prenumeration till alla i organisationen som vill experimentera, skapa poCs eller skapa MVP:er i Azure. Du måste lätt styra dessa användare och ge dem åtkomst till alla tjänster för att förhindra skugg-IT-metoder .

Sammanfattning och takeaways

Den här artikeln beskriver beskrivande vägledning som hjälper dig att navigera i komplexa prenumerationsautomatprocesser och gå mot implementering.

Fastställ kraven för dina framtida programteam för att välja produktraden för prenumerationsautomater som passar dem bäst. Identifiera kraven för den första uppsättningen arbetsbelastningar som du skapar eller migrerar för att prioritera produktraderna för prenumerationsautomater som du vill aktivera och exponera via ett självbetjäningsgränssnitt.

Varje produktrad har en implementeringskostnad och en underhållskostnad. Utvärdera den långsiktiga kostnaden jämfört med långsiktiga fördelar och användning.

Kunder aktiverar vanligtvis följande produktrader för prenumerationsautomater från början:

Ytterligare resurser

För att ytterligare stödja din plattformstekniska metod kan du granska följande resurser när du utformar och implementerar din organisations produktlinjer och erbjudanden för prenumerationsautomater:

Gå vidare

För bästa resultat bör du automatisera så mycket av prenumerationsautomatprocessen som möjligt. Använd vägledningen om hur du implementerar automatisering av prenumerationsautomatisering.

Implementeringsvägledning för prenumerationsautomater