Överväganden för oberoende programvaruleverantörer (ISV) för Azure-landningszoner

För många organisationer representerar konceptarkitekturen för Azure-landningszoner målet för deras molnimplementeringsresa. Landningszonerna beskriver hur du skapar en Azure-miljö med flera prenumerationer. Varje landningszon står för skalning, säkerhet, styrning, nätverk och identitet, och baseras på feedback och lärdomar från många kunder.

Som oberoende programvaruleverantör (ISV) som skapar och använder din lösning i Azure bör du referera till följande resurser när du skapar din Azure-miljö:

• Azure-landningszoner: Ger vägledning för din övergripande Azure-miljö.
• Azure Well-Architected Framework: Ger arkitekturvägledning som gäller för alla arbetsbelastningar.
• Utforma lösningar för flera klientorganisationer i Azure: Ger specifik arkitekturvägledning för lösningar för flera klientorganisationer i Azure.

Azure-landningszonerna hjälper dig att välja riktning för din övergripande Azure-miljö. Men som ISV, SaaS-provider eller start kan dina specifika implementeringsbehov skilja sig från mer standardkundscenarier. Följande är bara några exempel på olika implementeringsscenarion:

• Du skapar programvara som kunder distribuerar till sina egna prenumerationer.
• Du har ett eget kontrollplan och använder automationsskript eller programvara för att distribuera och konfigurera Azure-resurser för dina SaaS-lösningar.
• Du är en liten ISV eller start och vill börja med lägsta möjliga kostnad och kanske inte vill använda tjänster som Azure Firewall och Azure DDoS Protection från början.
• Du är en stor SaaS ISV och planerar att dela upp saaS-programmet i flera prenumerationer för skalning. Du vill också gruppera prenumerationerna så att de motsvarar dina utvecklings-, test-, mellanlagrings- och produktionsmiljöer.
• Organisationens driftsmodell separerar rollerna för företagets IT-team och dina SaaS-produktteam. Din organisations it-team kan hantera resurser som Microsoft kancelarija 365 och Microsoft Teams, och saaS-produktteamet kan ansvara för att skapa och driva din SaaS-produkt (inklusive dess centrala plattform och identitetskomponenter).

ISV-distributionsmodeller

ISV-lösningar passar ofta in i någon av tre distributionsmodeller: ren SaaS, kunddistribuerad eller saaS med dubbla distributioner. Det här avsnittet beskriver varje modells olika överväganden för Azure-landningszoner.

Ren SaaS

I den rena SaaS-modellen distribueras programvaran helt endast i dina Azure-prenumerationer. Slutanvändarna använder din programvara utan att distribuera den i sina egna Azure-prenumerationer. I följande diagram använder användarna ett rent SaaS-program som tillhandahålls av en ISV:

Exempel på ren SaaS-programvara är e-post som en tjänst, Kafka-as-a-service, cloud-data-warehouse-as-a-service och många SaaS-listor på Azure Marketplace.

Om du är en liten SaaS ISV behöver du kanske inte använda flera Azure-prenumerationer för att distribuera dina resurser direkt. Men när du skalar kan Azures prenumerationsgränser påverka din möjlighet att skala inom en enda prenumeration. Granska designprinciperna för landningszoner i företagsskala, särskilt prenumerationsdemokratisering, och bekanta dig med arkitekturmetoderna för flera klientorganisationer för att planera för din framtida tillväxt.

ISV:er som skapar rena SaaS-lösningar bör överväga följande frågor:

• Ska alla Azure-resurser som utgör vår SaaS-lösning finnas i en Azure-prenumeration eller partitioneras över flera Azure-prenumerationer?
• Ska vi vara värdar för varje kund i en egen dedikerad Azure-prenumeration eller kan vi skapa resurser inom en eller några delade prenumerationer?
• Hur kan vi tillämpa mönstret Distributionsstämpel (skalningsenhet) på alla våra lösningsnivåer?
• Hur kan vi använda Azure-resursorganisationen i lösningar med flera klientorganisationer för att hindra oss från att möta skalningsutmaningar och Azure-prenumerationsgränser?

Kunddistribuerad

I den kunddistribuerade modellen köper dina slutkunder programvara från dig och distribuerar den sedan till sina egna Azure-prenumerationer. De kan initiera distributionen från Azure Marketplace eller göra det manuellt genom att följa instruktionerna och använda skript som du anger.

I följande diagram tillhandahåller en ISV ett programvarupaket eller en Azure Marketplace-katalogprodukt och användarna distribuerar resursen till sina egna Azure-prenumerationer tillsammans med sina andra arbetsbelastningar:

Kundens andra arbetsbelastningselement i diagrammet kan representera antingen en kunds egen arbetsbelastning eller en annan ISV-produkt som kunden har distribuerat i sin Azure-prenumeration. Kunder distribuerar ofta flera produkter från olika ISV:er till sina Azure-prenumerationer. De kombinerar dessa enskilda produkter för att skapa lösningar. En kund kan till exempel distribuera en databasprodukt från en ISV, en virtuell nätverksinstallation från en annan ISV och ett webbprogram från en tredje ISV.

Exempel på kunddistribuerade ISV-produkter är de många virtuella datorbilderna (till exempel virtuella nätverks- och lagringsinstallationer) och Azure-program på Azure Marketplace.

För vissa kunddistribuerade lösningar kan en organisation tillhandahålla hantering av och uppdateringar för lösningen som distribueras i deras Azure-prenumerationer för slutkund med hjälp av Azure Lighthouse eller Azure Managed Applications. ISV:er, Solution Integrators (SIs) och Managed Service Providers (MSP: er) kan alla använda den här strategin när den uppfyller deras specifika behov.

Kunddistribuerade ISV-lösningar betraktas som en standardprogramarbetsbelastning ur Azures landningszoners perspektiv. Överväg vägledningen för Azure-landningszoner när du utformar din produkt så att den fungerar med de designprinciper för Azure-landningszoner som dina Azure-kunder antar.

Det är särskilt viktigt att du har en god förståelse för begreppen i Azure-landningszonen när du migrerar dina befintliga kunders arbetsbelastningar till Azure.

ISV:er som skapar kunddistribuerade lösningar bör överväga följande frågor:

• Ska en kund distribuera vår lösning till en egen dedikerad prenumeration eller till en befintlig prenumeration som innehåller relaterade arbetsbelastningar?
• Hur ska kunder upprätta nätverksanslutning mellan befintliga arbetsbelastningar (inom och utanför Azure) och vår lösning?
• Stöder vår lösning autentiseringsmekanismer från Microsoft Entra-ID eller kräver andra protokoll som LDAP eller Kerberos?
• Hur minskar eller eliminerar vi Azure Policy-överträdelser, som de som orsakas av konflikter mellan våra lösningsmallar och en kunds Azure-principer?

Kundens Azure-principer som kan orsaka Azure Policy-överträdelser inkluderar exempel som "Alla undernät måste ha en nätverkssäkerhetsgrupp" och "Inga offentliga IP-adresser kan kopplas till nätverksgränssnitt i Corp-landningszonen". Tänk på risken för dessa konfliktframkallande principer när du planerar distributionen.

SaaS med dubbel distribution

Vissa SaaS-lösningar interagerar med eller använder resurser som distribueras i kundernas Azure-prenumerationer. Den här distributionsmodellen kallas ibland saaS - eller SaaS-hybrid för dubbel distribution. I följande diagram tillhandahåller en ISV en värdbaserad SaaS-lösning som interagerar med resurser som distribueras till en slutkunds Azure-prenumeration:

Ett verkligt exempel på saaS med dubbel distribution är Microsoft Power BI, en SaaS-tjänst som kan använda en lokal Power BI-datagateway som distribueras på en virtuell dator i en kunds Azure-prenumeration.

Andra exempel på SaaS-scenarier med dubbel distribution är:

• Din organisation skapar Virtual Desktop Manager, en produkt som tillhandahåller ett SaaS-konsolgränssnitt för att styra Azure Virtual Desktop-resurser i varje kunds Azure-prenumeration.
• Din organisation tillhandahåller en SaaS-konsol för dataanalys och skapar och tar dynamiskt bort virtuella datorer för beräkningsnoder i varje kunds Azure-prenumeration.

Som ISV för dubbel distribution bör du gå till Azure-landningszonen för vägledning inom två områden: strukturera din egen Azure-miljö som värd för SaaS-tjänsten och säkerställa korrekt interaktion mellan dina distributioner i kundernas Azure-prenumerationer och dina kunders landningszoner.

ISV:er som skapar SaaS-lösningar med dubbla distributioner bör överväga följande frågor:

• Har vi granskat alla överväganden för att skapa både rena SaaS- och kunddistribuerade lösningar?
• Vilka komponenter i vår lösning ska finnas i våra Azure-prenumerationer och vilka komponenter ska distribueras av kunden?
• Hur kan vi säkerställa säker etablering och interaktion med resurser som distribueras i våra kunders Azure-prenumerationer?

Designprinciper och implementeringar för Azure-landningszoner

Azures designprinciper för landningszoner rekommenderar att du anpassar dig till azure-inbyggda plattformsfunktioner som Log Analytics, Azure Monitor och Azure Firewall. Vägledningen för landningszonen innehåller även specifika implementeringsalternativ för Azure-landningszoner.

Som ISV kan du välja att implementera dina egna landningszonmiljöer. Du kan behöva använda din egen automatisering för att distribuera Azure-resurser mellan prenumerationer. Eller så kanske du vill fortsätta använda verktyg som du redan använder för loggning, övervakning och andra plattformslagertjänster.

Om du implementerar dina egna miljöer för landningszoner rekommenderar vi att du använder vägledning och exempelimplementeringar för Azure-landningszoner som referens och anpassar din metod med beprövade design för Azure-landningszoner.

Microsoft Entra-klienter

Varje Azure-landningszon och dess hanteringsgruppshierarki är rotade i en enda Microsoft Entra-klientorganisation. Det innebär att det första beslutet du behöver fatta är vilken Microsoft Entra-klientorganisation som ska användas som identitetskälla för att hantera dina Azure-resurser. Identiteter i Microsoft Entra-ID:t omfattar användare, grupper och tjänstens huvudnamn.

Vägledningen för Azure-landningszoner och Microsoft Entra-klienter rekommenderar starkt att du använder en enda Microsoft Entra-klientorganisation, och det här är rätt metod för de flesta situationer. Men som SaaS ISV kan du ha anledning att använda två klienter.

För vissa SaaS ISV:er hanterar ett team företagsresurser och ett separat team driver SaaS-lösningen. Den här separationen kan vara av driftsskäl eller för att uppfylla regelkraven. Företagets IT-team kanske inte får hantera några SaaS-relaterade prenumerationer och resurser, så de kan inte vara administratörer för Microsoft Entra-klientorganisationen. Om det här scenariot gäller för dig kan du överväga att använda två separata Microsoft Entra-klienter: en klientorganisation för företagets IT-resurser som Office 365 och en klientorganisation för Azure-resurser som utgör din SaaS-lösning.

Varje Microsoft Entra-klient måste ha ett eget domännamn. Om din organisation använder två klienter kan du välja ett namn som contoso.com för företagets Microsoft Entra-klientorganisation och contoso-saas-ops.com för Din SaaS Microsoft Entra-klientorganisation, enligt följande diagram.

Undvik att använda separata Microsoft Entra-klienter för förproduktions- och produktionsmiljöer. I stället för att skapa två klienter som contoso-saas-ops-preprod.com och contoso-saas-ops-prod.com med separata Azure-prenumerationer under varje, bör du skapa en Microsoft Entra-klientorganisation. Du kan använda hanteringsgrupper och Azure RBAC för att styra åtkomsten till prenumerationer och resurser under den här enda klientorganisationen.

Mer information om hur du använder flera Microsoft Entra-klienter finns i Azure-landningszoner och flera Microsoft Entra-klienter och resursisolering med flera klienter.

Hanteringsgrupper

Den konceptuella arkitekturen i Azure-landningszonen rekommenderar att du använder en specifik hanteringsgruppshierarki. ISV:er kan dock ha andra krav än andra organisationer. I det här avsnittet beskrivs några sätt som din ISV-organisation kan välja att använda andra metoder än vad den konceptuella arkitekturen i landningszonen rekommenderar.

Hanteringsgrupp på högsta nivå

Hierarkin för hanteringsgruppen är kapslad under den Azure-skapade rotgruppshanteringsgruppen för klientorganisation. Du använder inte rotgruppen Klientorganisation direkt.

En standardorganisation som har ett centraliserat företags IT-team som hanterar sina plattforms- och delade tjänster (t.ex. loggning, nätverk, identitet och säkerhet) skapar vanligtvis en hanteringsgrupp på den högsta nivån under den Azure-skapade klientrotgruppen och distribuerar resten av sina hanteringsgrupper under den. Den här toppnivåhanteringsgruppen namnges vanligtvis efter själva organisationen (till exempel Contoso).

Som SaaS ISV kan du ha en SaaS-produkt eller ha några separata SaaS-produkter eller verksamhetslinjer. Du bör vanligtvis använda samma Microsoft Entra-klientorganisation för att hantera Azure-resurser i alla dina produkter (som beskrivs i avsnittet Microsoft Entra-klientorganisationer ), men i vissa scenarier kan du välja att distribuera flera hanteringsgruppshierarkier.

Överväg hur oberoende dina produkter är från varandra och fråga dig själv:

• Använder alla våra produkter samma plattformar för DevOps, identitet, säkerhet, anslutning och loggning?
• Drivs dessa delade tjänster av ett enda centralt team?

Om du svarade ja på båda frågorna skapar du en enda saaS-produkthanteringsgrupp på toppnivå under rotgruppen Klientorganisation.

Om du i stället svarade nej och var och en av dina SaaS-produkter hanteras och drivs av separata plattformsteam kan du överväga att skapa en separat hanteringsgrupp på högsta nivån för varje produkt, till exempel de två högsta hanteringsgrupperna SaaS Product-01 och SaaS Product-02.

Den här hanteringsmetoden liknar testmetoden för landningszoner i företagsskala. Men i stället för att skapa Contoso och Contoso-Canary under rotgruppen Klientorganisation skapar exempelföretaget i den här metoden produktspecifika hanteringsgrupperna Contoso-SaaS-Product-01, Contoso-SaaS-Product-02 och Contoso-SaaS-Product-03 under den i stället. Det här scenariot illustreras i följande diagram:

Plattformshanteringsgrupp

I resursorganisationshierarkin i Azure-landningszonen innehåller plattformshanteringsgruppen alla Azure-prenumerationer som är värdar för komponenter och delade tjänster som används av arbetsbelastningar i prenumerationerna i landningszonen. Exempel på komponenter som distribueras till plattforms- och delade tjänstprenumerationer är centraliserad loggningsinfrastruktur (till exempel Log Analytics-arbetsytor), DevOps, säkerhet, automatiseringsverktyg, centrala nätverksresurser (till exempel hub-VNet- och DDos Protection-planer) och en ISV:s kontrollplanstjänster.

Plattformshanteringsgruppen partitioneras ofta i underordnade grupper för identitet, hantering och anslutning för att tillhandahålla en bekväm uppdelning av roller och principer för företagskunder.

I din organisation kan du ha ett enda team som hanterar alla delade plattformskomponenter som identitet, nätverk och hantering. I så fall, och om du inte har några planer på att separera den hanteringen mellan flera team, bör du överväga att använda en enda plattformshanteringsgrupp .

Om du i stället har separata team som hanterar olika delar av din centraliserade plattform bör du distribuera ytterligare nivåer i hanteringsgruppshierarkin under plattformshanteringsgruppen . På så sätt kan du tilldela separata principer för varje del av din centraliserade plattform.

Följande diagram illustrerar två potentiella implementeringar av plattformshanteringsgruppen . Alternativ A visar ett mer omfattande scenario, där plattformshanteringsgruppen innehåller tre underordnade hanteringsgrupper: Hantering och DevOps, identitet och säkerhet samt anslutning. Varje underordnad hanteringsgrupp innehåller en prenumeration med relevanta resurser. Alternativ B visar ett enklare scenario där plattformshanteringsgruppen innehåller en enskild plattformsprenumeration.

Hanteringsgrupp för landningszoner

Hanteringsgruppen Landningszoner innehåller De Azure-prenumerationer som är värdar för saaS-lösningens faktiska undersystem och arbetsbelastningar.

Den här hanteringsgruppen innehåller en eller flera underordnade hanteringsgrupper. Var och en av de underordnade hanteringsgrupperna under Landningszoner representerar en arketyp för arbetsbelastningar eller undersystem, med konsekventa princip- och åtkomstkrav som ska gälla för alla prenumerationer. Orsaker till att använda flera arketyper är:

• Efterlevnad: Om ett undersystem av din SaaS-produkt måste vara PCI-DSS-kompatibelt bör du överväga att skapa en PCI DSS-underordnad hanteringsgrupp för arketyp under Landningszoner. Alla Azure-prenumerationer som innehåller resurser inom ramen för PCI-DSS-efterlevnad bör placeras i den hanteringsgruppen.
• Nivåer: Överväg att skapa separata arketyper för landningszoner för saaS-lösningens dedikerade kunder och kunder på den kostnadsfria nivån. Var och en av de underordnade hanteringsgrupperna innehåller olika Azure Policy-inställningar. Principerna på den kostnadsfria nivån kan till exempel begränsa distributioner till att endast aktivera specifika SKU:er för virtuella datorer, och principerna på den dedikerade nivån kan kräva att resurser distribueras till specifika regioner.

Miljöspecifika hanteringsgrupper

SaaS ISV:er organiserar ofta sina molnmiljöer genom att modellera sina livscykelmiljöer för programvaruutveckling i en sekvens. Detta kräver vanligtvis distribution först till en utvecklingsmiljö , sedan till en testmiljö , sedan till en mellanlagringsmiljö och slutligen till en produktionsmiljö .

En vanlig skillnad mellan miljöerna är deras Azure RBAC-regler, till exempel vem som kan komma åt varje grupp med prenumerationer. Till exempel kan DevOps-, SaaSOps-, utvecklings- och testteamen ha olika åtkomstnivåer till olika miljöer.

SaaS ISV:er behöver ibland gruppera flera prenumerationer som representerar shards eller partitioner i samma undersystem, program eller arbetsbelastning. Du kan behöva tillämpa principer eller rolltilldelningar på grupper av prenumerationer på ett märkbart annat sätt än i hanteringsgruppen för arketyp. I det här fallet bör du överväga att skapa underordnade hanteringsgrupper som motsvarar varje miljö under hanteringsgruppen för arketyp.

Följande diagram illustrerar två möjliga alternativ. Alternativ A visar ett scenario med separata prenumerationer för varje miljö men inga miljöspecifika hanteringsgrupper. Alternativ B visar ett SaaS ISV-scenario med miljöspecifika hanteringsgrupper under hanteringsgruppen Vanliga stämplar . Varje miljöspecifik hanteringsgrupp innehåller flera prenumerationer. Med tiden skalar ISV sina Azure-resurser i varje miljö över ett ökande antal prenumerationer med en gemensam uppsättning principer och rolltilldelningar.

Välj varje flik för att se de två diagrammen.

Inaktiverade och sandbox-hanteringsgrupper

Vägledningen för resursorganisationen i Azure-landningszonen rekommenderar att du inkluderar hanteringsgrupper för inaktiverade och sandbox-miljöer direkt under din hanteringsgrupp på högsta nivå.

Den inaktiverade hanteringsgruppen är en lagringsplats för Azure-prenumerationer som inaktiveras och så småningom tas bort. Du kan flytta en prenumeration som inte längre används till den här hanteringsgruppen för att spåra den tills alla resurser i prenumerationen tas bort permanent.

Sandbox-hanteringsgruppen innehåller vanligtvis Azure-prenumerationer som används i utforskningssyfte och har lösa eller inga principer som tillämpas på dem. Du kan till exempel ge enskilda utvecklare egna prenumerationer för utveckling och testning. Du kan undvika att tillämpa normala principer och styrning på dessa prenumerationer genom att placera dem i sandbox-hanteringsgruppen . Detta ökar utvecklarnas flexibilitet och gör det möjligt för dem att enkelt experimentera med Azure.

Följande diagram illustrerar två möjliga alternativ. Alternativ A inkluderar inte hanteringsgrupperna Inaktiverad och Sandbox , medan alternativ B gör det.

Exempel på ISV-landningszoner

Det här avsnittet innehåller två exempel på Azure-landningszonstrukturer för en SaaS ISV. Välj varje flik för att jämföra de två exempellandningszonerna.

Nästa steg

• Om du skapar en lösning för flera klientorganisationer kan du lära dig mer om att skapa lösningar för flera klientorganisationer i Azure.
• Lär dig vad som är en Azure-landningszon.
• Läs mer om designområden för Azure-landningszoner.