Algemene abonnementsautomaat productlijnen instellen

Met abonnementsverkoop kunnen organisaties de ontwerpprincipes voor abonnements democratisering van Azure-landingszones realiseren. Dit is essentieel voor consistente schaalaanpassing, beveiliging en governance van Azure-omgevingen. Abonnementsverkoop helpt organisaties ook in overeenstemming te zijn met de principes van platformengineering. Zie Adopt a product mindset and Empower developers through selfservice with guardrails (Selfservice met kaders) voor meer informatie.

Veel organisaties hebben moeite om hun toepassingsteams de flexibiliteit te geven die ze nodig hebben om hun workloads en services effectief te leveren. Een van de belangrijkste obstakels is het ontbreken van een gestandaardiseerde benadering van abonnementsautomaat, wat kan leiden tot verwarring, vertraging en inefficiëntie.

In dit artikel wordt beschreven hoe platformteams algemene abonnementsautomaat productlijnen kunnen opzetten die voldoen aan de diverse behoeften van verschillende toepassingsteams. Het artikel bespreekt de voordelen van het aanbieden van verschillende productlijnen en biedt voorbeelden van veelvoorkomende scenario's op basis van echte klantimplementaties. U leert ook waarom abonnementsautomaat niet beschikt over een 'een maat voor alles' ontwerp en waarom u verschillende productlijnen moet leveren aan toepassingsteams.

In het volgende diagram ziet u de organisatie van beheergroepen en abonnementen in een Azure-omgeving.

In het diagram ziet u elementen zoals beheergroepen, landingszones en platforms met de naam Connectiviteit en Identiteit. In het diagram ziet u ook connectiviteitsabonnementen met onderdelen zoals een regionale hub en abonnementsautomaat automatisering, waarmee de stroom en relaties tussen verschillende organisatieonderdelen worden aangegeven. Deze architectuur is afgestemd op Azure-landingszones.

In de volgende richtlijnen wordt beschreven waarom u verschillende productlijnen nodig hebt en productlijnvoorbeelden beschrijft voor klanten die Gebruikmaken van Azure-landingszones en abonnementsautomaat.

Profiteer van verschillende productlijnen

Abonnementen die toepassingsteams nodig hebben om hun workloads en services te leveren, zijn beschikbaar in veel typen en stijlen. Buiten toepassingsteams heeft uw organisatie mogelijk andere vereisten die het gebruik van een Azure-abonnement vereisen, zoals verschillende nalevings- en gegevensverwerkingsregels of architectuurpatronen.

Wanneer u besluit over de aanpak van uw organisatie voor het ontwerpen en implementeren van abonnementsautomaat, kunt u overwegen deze vragen te stellen:

• Welke andere resources moet het platformteam als onderdeel van het abonnementsautomaat proces gebruiken?

• Implementeert u voor elk toepassingsteam standaard meerdere abonnementen, zoals één per omgeving?

• Peert of verbindt u het virtuele spoke-netwerk standaard met uw connectiviteitshubs?

• Hoe moet u op rollen gebaseerd toegangsbeheer (RBAC) binnen elk abonnement structuren?

• Hoe moet u resources en stijlen van architectuur of archetypen beheren en beheren die u binnen abonnementen gebruikt?

U kunt niet voldoen aan de unieke vereisten van elk toepassings- en platformteam met één abonnementstype of abonnementsstijl die u verkrijgt. Platformteams moeten toepassingsteams flexibiliteit bieden om te kiezen uit meerdere typen en stijlen van abonnementen die het team aan hen kan toewijzen via een selfservicesysteem. Deze typen abonnementen worden productlijnen genoemd.

Organisaties die slechts een 'één grootte past bij alle'-benadering bieden om abonnementsautomaat beperken vaak de flexibiliteit van hun interne klanten. Zo kan een gebrek aan flexibiliteit de ontwerpopties voor architectuur van een toepassingsteam beperken en mogelijk leiden tot compromissen vanwege wat ze zijn verwed.

Daarom moeten platformteams verschillende productlijnen bieden om tegemoet te komen aan de behoeften van hun organisatie. Deze flexibiliteit zorgt ervoor dat consumenten de productlijn kunnen kiezen die het beste bij hun behoeften past.

Toepassingsomgevingen beheren

Uw organisatie moet toepassingsomgevingen beheren voor toepassingsteams als onderdeel van uw abonnementsautomaat processen en implementaties. U moet echter ook flexibiliteit bieden, zodat toepassingsteams hun toepassingsomgevingen kunnen beheren, zoals dev/test/prod, hoe ze dat willen wanneer ze toepassingen leveren. Zie Omgevingen, abonnementen en beheergroepen voor meer informatie.

Sommige Azure-services bieden systeemeigen functies om een omgeving binnen één resource-exemplaar in één Azure-abonnement te isoleren, zoals Azure-app Service met de functie implementatiesites. In dit voorbeeld worden toepassingsteams gedwongen afzonderlijke abonnementen te gebruiken, zodat teams niet kunnen profiteren van de volledige functieset services die Azure biedt. Afzonderlijke abonnementen kunnen ook de leveringskosten van toepassingen verhogen, inclusief operationele en onderhoudsoverhead.

Algemene productlijnen ontwerpen voor abonnementsautomaat

Nu u begrijpt dat platformteams meerdere typen en stijlen voor Azure-abonnementen of productlijnen moeten bieden aan consumenten van hun Azure-platform, worden in deze sectie verschillende algemene productlijnen beschreven die u kunt gebruiken in verschillende branches en landen of regio's.

Uw platformteam moet deze algemene abonnementsautomaat productlijnen gebruiken als basislijn. Uw team kan standaard meerdere opties bieden aan de consumenten, die overeenkomen met het principe van de platformengineering van klanten . Deze aanpak biedt interne klanten de vrijheid om ontwerpprincipes en ontwerpgebiedaanvelingen van Azure-landingszones te gebruiken om hun workloads en service te leveren en biedt ook Azure-platformgovernance.

Notitie

Gebruik deze voorbeelden als uitgangspunt. U kunt deze productlijnen aanpassen en uitbreiden om tegemoet te komen aan de behoeften van uw organisatie.

Algemene productlijnen voor abonnementsautomaat zijn onder andere:

• Verbonden met corp: workloads waarvoor traditionele LAYER-3 IP-routeringsconnectiviteit met andere toepassingen en on-premises omgevingen is vereist via het connectiviteitsabonnement.

• Online: Workloads die verbinding maken met andere toepassingen via moderne connectiviteitsservices en architecturen, zoals Azure Private Link of interactie via blootgestelde API's of eindpunten van elke toepassing.

• Tech-platform: Workloads die een platform bouwen waarop u andere toepassingen kunt bouwen. Een AKS-vloot (Azure Kubernetes Service) met clusters die een AKS-platformteam beheert, kan bijvoorbeeld andere toepassingen binnen de AKS-clusters hosten namens andere toepassingsteams.

• Gedeelde toepassingsportfolio: Gedeelde workloads tussen dezelfde toepassingsteams voor een gemeenschappelijke set nauw gekoppelde toepassingen. U wilt de toepassingen niet zelf of met een specifieke workload hosten.

• Sandbox: Een gebied waar toepassingsteams een proof of concept (PoC) of minimum viable product (MVP) kunnen bouwen en minder controles kunnen opleggen, zodat het team ontwikkeling, uitvinding en vrijheid kan bevorderen om de best mogelijke toepassing te bouwen vanuit de catalogus met beschikbare Azure-services.

De verbonden productlijn van corp

De corp verbonden productlijn, ook wel een interne of privéproductlijn genoemd, voor de landingszone van de toepassing abonnementsautomaat biedt connectiviteit via traditionele Laag-3 IP-methoden. U kunt deze productregel gebruiken om connectiviteit te bieden tussen resources die:

• In dezelfde landingszone voor toepassingen.

• In verschillende bedrijfsgebonden toepassingslandingszones via een Azure-firewall of een virtueel netwerkapparaat (NVA).

• On-premises of in verschillende clouds via Azure ExpressRoute- of VPN-verbindingen.

Organisaties die abonnementsautomaat gebruiken, nemen deze productlijn vaak op omdat deze nauw aansluit bij de werking van de meeste on-premises omgevingen. U moet echter alleen de bedrijfsproductlijn gebruiken wanneer u dat nodig hebt. We raden u aan de voorkeur te geven aan modernere cloud-native benaderingen, zoals de online productlijn, wanneer u dat kunt.

Tip

Zie Wat is het doel van connectiviteits-, corp- en onlinebeheergroepen voor informatie over verschillen tussen corp- en onlineworkloads.

In het volgende diagram ziet u een voorbeeld van de bedrijfsverbinding abonnementsautomaat productlijn. U kunt deze installatie gebruiken voor een hub-and-spoke-netwerkmodel om het netwerkverkeer en beleid effectief te beheren.

Het diagram toont een voorbeeld van de corp verbonden abonnementsautomaat productlijn met een netwerkarchitectuur die een centrale routeerbare hub met een IP-adres van 10.1.0.0/24 bevat. De routeerbare hub maakt verbinding met twee spokes: Landingszone A en Landingszone B, met RESPECTIEVELIJK IP-adressen 10.1.1.0/24 en 10.1.2.0/24. In het diagram ziet u ook peeringverbindingen voor virtuele netwerken tussen de hub en de landingszones en andere niet-opgegeven landingszones. Deze installatie is gebruikelijk voor een hub-and-spoke-netwerkmodel en helpt bij het efficiënt beheren van netwerkverkeer en beleid.

Wanneer gebruikt u de verbonden bedrijfsproductlijn

Gebruik de verbonden bedrijfsproductlijn wanneer:

• U wilt rehost- en herstructureringsmigraties en -toepassingen uitvoeren op basis van de vijf R's van rationalisatie.

• U wilt uw reis in Azure starten en bekend zijn met een vergelijkbare on-premises architectuur.

• U wilt 'lift-and-shift'-toepassingen naar Azure verplaatsen.

• U wilt de beveiliging tussen workloads verbeteren door toepassingen te isoleren in hun eigen landingszoneabonnementen en door te gaan naar microsegmentatieprincipes van nulvertrouwen zonder de toepassing opnieuw te ontwerpen om volledig cloudeigen te zijn.

Noteer deze andere overwegingen voor de verbonden productlijn van corp:

• Uw platformteam kan het virtuele netwerk overdragen aan het abonnement voor de landingszone van de toepassing en het virtuele netwerk koppelen aan het virtuele netwerk van de regionale hub of de Azure Virtual WAN-hub. Uw team kan vervolgens een IPAM-hulpprogramma (IP Address Management) gebruiken om de TOEWIJZING van IP-adressen te beheren.

• Platformteams bieden meestal geen subnetten of andere resources in het virtuele netwerk. In plaats daarvan wijzen platformteams deze activiteiten toe aan de toepassingsteams, zodat ze hun toepassingsnetwerken kunnen ontwerpen zoals ze willen.

• Platformteams gebruiken een Azure-beleid dat is toegewezen aan de beheergroepen boven het abonnement om gewenst gedrag af te dwingen, zoals gestandaardiseerde netwerkbeveiligingsgroepen (NSG's) die aan elk subnet zijn gekoppeld. Het toepassingsteam neemt dit Azure-beleid over en kan het niet bewerken. Deze benadering volgt het ontwerpprincipe voor het ontwerpen van azure-landingszones voor het democratiseren van abonnementen.

De online productlijn

De onlineproductlijn, ook wel een externe of openbare productlijn genoemd, voor landingszone van toepassingen abonnementsautomaat biedt geen connectiviteit via traditionele Laag-3 IP-methoden tussen resources in andere landingszones van toepassingen of on-premises via ExpressRoute- of VPN-verbindingen. Resources in hetzelfde abonnement op de landingszone voor onlinetoepassingen kunnen virtuele netwerken gebruiken om met elkaar te communiceren via IP-methoden van laag-3. Maar de virtuele netwerken worden doorgaans niet teruggezet naar regionale connectiviteitshubs of andere landingszones van toepassingen.

In plaats daarvan kunt u connectiviteit bieden via openbare interfaces tussen resources die:

• In verschillende landingszones voor toepassingen.

• On-premises.

• In workloads die zich in verschillende clouds bevinden.

U kunt de verbindingen beveiligen met netwerkbesturingselementen, verificatiefuncties en autorisatiefuncties die worden weergegeven door de verschillende PaaS-oplossingen (Platform as a Service) die u gebruikt om de toepassing samen te stellen.

U kunt de Private Link-service en privé-eindpunten van Azure binnen en tussen abonnementen op de landingszone voor onlinetoepassingen gebruiken om privéconnectiviteit op laag 3-niveau tussen toepassingen mogelijk te maken en beschikbaar te maken. U kunt deze benadering ook gebruiken tussen de PaaS-services die u binnen landingszones van toepassingen gebruikt om te voorkomen dat de openbare interfaces van deze PaaS-services worden gebruikt voor beveiliging of regelgeving.

U kunt de Private Link-service ook gebruiken met privé-eindpunten om toepassingen die u host in onlinetoepassingslandingszones beschikbaar te maken en te publiceren naar landingszones voor bedrijfstoepassingen, on-premises locaties of andere clouds. U kunt privé-eindpunten plaatsen in landingszones voor bedrijfstoepassingen of rechtstreeks in connectiviteitshubs, die vervolgens toegang verlenen tot deze privé-eindpunten via traditionele laag-3-connectiviteitsmethoden, zoals peering van virtuele netwerken, ExpressRoute-verbindingen of VPN-verbindingen.

Denk aan de productlijn voor de landingszone voor onlinetoepassingen als geïsoleerde eilanden. Standaard zijn de enige resources die toegang hebben tot resources binnen het abonnement de resources die u implementeert binnen hetzelfde abonnement op de landingszone voor onlinetoepassingen. Zoals eerder vermeld, kunt u vervolgens de technieken in dit artikel gebruiken om de connectiviteit met andere landingszones van toepassingen, on-premises locaties of andere clouds uit te breiden.

Tip

Zie Wat is het doel van connectiviteits -, corp- en onlinebeheergroepen voor meer informatie over de verschillen tussen corp- en onlineworkloads.

In het volgende diagram ziet u een voorbeeld van een online abonnementsautomaat productlijn.

In dit diagram ziet u een voorbeeld van een online abonnementsautomaat productlijn met een netwerkarchitectuurdiagram met secties landingszone A, Landingszone B, Landingszone C en Landingszone D. Elke sectie bevat pictogrammen voor netwerkelementen, zoals databases en cloudservices, die zijn verbonden met pijlen om de gegevensstroom weer te geven. Een centrale routeerbare hub 10.0.0/24 met een beveiligingsvergrendelingspictogram maakt verbinding met andere landingszones die worden weergegeven door cloudpictogrammen. Belangrijk is dat geen van de virtuele netwerken aan elkaar is gekoppeld en alle moderne services en benaderingen gebruiken, zoals privékoppelingen, om met elkaar te communiceren.

Wanneer u de online productlijn gebruikt

Gebruik de online productlijn als u het volgende wilt doen:

• Herstructureren, opnieuw ontwerpen, herbouwen en uitvoeren van migraties en toepassings builds, op basis van de vijf R's van rationalisatie.

• Bied toepassingsteams een volledig ge democratiseerde landingszone voor toepassingen, zelfs met betrekking tot de netwerkconfiguratie.

• Profiteer van cloudeigen services en architecturen.

• Verbetert de uitlijning aanzienlijk met de principes van nulvertrouwen.

• Gebruik de bedrijfsverbindingsproductregel, maar de privé-IP-adresruimte is niet beschikbaar of beperkt.

  • In dit scenario moet u de richtlijnen in IPv4-uitputting voorkomen in Azure bekijken.

De productlijn van het Tech-platform

Teams die gebruikmaken van technologieplatforms, zoals Azure VMware Solution of Azure Virtual Desktop, moeten de productlijn van het tech-platform implementeren. De productlijn van het tech-platform is in wezen een abonnementsautomaat productlijn die beter aansluit bij zeer technische vereisten. U kunt de productlijn van het tech-platform gebruiken om grote en complexe workloads te hosten en te beheren die doorgaans meerdere toepassingen hosten voor verschillende andere toepassingsteams in uw organisatie. Gebruik deze productlijn als uw toepassingsteam alleen de toepassingsonderdelen beheert en niet de onderliggende onderdelen van het technologieplatform.

Tip

Bekijk het volgende voorbeeld om deze productlijn beter te begrijpen. Een technologieplatformteam, zoals een AKS-team, wil AKS als een beheerde service aanbieden aan andere toepassingsteams die hun toepassingen op het AKS-platform moeten uitvoeren. Het AKS tech platform-team biedt het beheer, onderhoud, beveiliging en configuratie van AKS. Het toepassingsteam onderhoudt dus alleen de toepassing en implementeert deze op het platform.

U kunt de volgende producten opnemen in een productlijn van het tech-platform:

• Een App Service-omgeving, meestal via afzonderlijke App Service-abonnementen.

• AKS, meestal via naamruimten binnen een of meer clusters.

• Azure Virtual Machines in Azure VMware Solution-clusters of -hosts.

• Azure Virtual Desktop om virtuele bureaubladen of toepassingen aan uw hele organisatie te bieden.

U kunt deze producten opnemen in verbonden bedrijfs - of onlineproductlijnen , afhankelijk van de vereisten voor het technologieplatform dat uw team wil aanbieden als een service aan andere toepassingsteams in uw organisatie.

Portfolio van gedeelde toepassingen

De productlijn voor de gedeelde toepassingsportfolio voor landingszone voor toepassingen abonnementsautomaat is bedoeld voor workloads waarvoor geen verschillende afzonderlijke abonnementen voor toepassingslandingszones nodig zijn voor eenvoudige toepassingen die kunnen worden samengesteld uit slechts een klein aantal Azure-resources.

Uw toepassingsteams en afdelingen kunnen deze productregel gebruiken om verschillende kleine toepassingen of gedeelde onderdelen te hosten, zoals opslagaccounts of SQL-servers. De teams delen deze onderdelen tussen verschillende van hun eigen toepassingen in één abonnement of een klein aantal abonnementen.

Belangrijk

Een gemeenschappelijk team is eigenaar van abonnementen die u onder deze productlijn hebt. Dit team beheert het gerelateerde portfolio met toepassingen die u in dit abonnement implementeert voor deze productlijn. Gebruik deze productregel niet voor algemene implementaties van niet-gerelateerde toepassingsworkloads met afzonderlijke eigenaren van toepassingsportfolio's.

Plan zorgvuldig om doorlopende flexibiliteit, toegangsbeheer, governance en onderhoudbaarheid te garanderen als uw organisatie verandert in één abonnement en resourcegroepen gebruikt om toegang te delegeren.

Als u delegering van resourcegroepen in één abonnement tussen meerdere teams beschouwt, moet u rekening houden met de volgende overwegingen voordat u een definitieve beslissing neemt:

Gebied	Overwegingen
Algemeen eigendom van gerelateerde toepassingsportfolio	- Een gemeenschappelijke eigenaar hebben, zoals een bedrijfseenheid van een afdeling, toepassingen beheren om wijzigingsbeheer te vereenvoudigen, zodat het binnen het goedkeuringsbereik van dezelfde entiteit blijft. - Zorg ervoor dat workloads consistente beleidstoewijzing in het abonnement volgen, inclusief logboekregistratie, bewaking en beveiliging.
Naleving van regelgeving	- Gebruik IAM- en Azure-beleid om abonnementen te maken voor workloads met wettelijke nalevingsvereisten, waaronder National Institute of Standards and Technology (NIST), Center for Internet Security Security (CIS), PCI SSC (Payment Card Industry Security Standards Council), industrievereisten en regionale vereisten. Zie Landingszones van Azure aanpassen voor meer informatie. - Abonnementen maken voor workloads die gebruikmaken van privacy- en gegevensverwerkingsvereisten voor governance. Afzonderlijke abonnementen verminderen de toegang.
Azure Policy	Bereik van Azure-beleid voor beheergroepen, abonnementen, resourcegroepen en resources. Wijs Azure-beleidsregels toe op een hoog bereik voor efficiënt beheer wanneer u resources in resourcegroepen implementeert. Houd rekening met de volgende beperkingen wanneer u Azure Policy beheert op het bereikniveau van de resourcegroep: - Verhoogt de beheeroverhead om Azure Policy-toewijzingen te maken wanneer u nieuwe resourcegroepen toevoegt aan abonnementen - Verhoogt de werkbelasting wanneer u wijzigingen in beleidstoewijzingen beheert - Verhoogt de beveiligings- en governance-hiaten wanneer u niet onmiddellijk beleid toewijst aan resourcegroepen - Vermindert de mogelijkheid om de nalevingsstatus bij hoge bereiken samen te rollen, zoals beheergroepen en abonnementen
Abonnementslimieten	- Controleer de limieten om ervoor te zorgen dat toepassingen geen harde limieten bereiken die groei voorkomen. Elk abonnement heeft zachte en vaste limieten voor Azure-services. - Maak afzonderlijke abonnementen voor toepassingen die anticiperen op grote groeipatronen die voldoen aan abonnementslimieten. - Deel geen abonnementen met toepassingsteams van verschillende bedrijfseenheden of afdelingen om problemen met lawaaierige buren te voorkomen.
Azure-services en functie-uitlijning	U kunt services implementeren die eenvoudige Azure-serviceprimitieven bieden, zoals virtuele machines, virtuele netwerken en eenvoudige PaaS-services, binnen één resourcegroep. Maar de complexiteit van moderne samengestelde aanbiedingen kan vereisen dat u deze complexere services buiten de grenzen van één resourcegroep implementeert. Gebruik andere ge democratiseerde abonnementsmethoden die eerder in dit artikel worden beschreven voor deze implementatiescenario's.
Alleen platformteams kunnen resourcegroepen maken	Wanneer u een abonnement deelt tussen verschillende toepassingsteams in bedrijfseenheden of afdelingen, kunt u de mogelijkheid van elk team beperken om nieuwe resourcegroepen te maken in het gedeelde abonnement. Met deze beperking wordt de sprawl van de resourcegroep beperkt. Alleen het platformteam kan nieuwe resourcegroepen maken en beheren. Deze aanpak verhoogt de complexiteit van RBAC-toewijzingen en plaatst een verhoogde afhankelijkheid van platformteams voor het beheren van toepassingsimplementaties, waardoor de flexibiliteit en de kracht van toepassingsteams kan worden belemmerd.

U kunt de abonnementen die u in de productlijn voor het portfolio van gedeelde toepassingen plaatst onder Corp- of Online-beheergroepen. Deze methode is afgestemd op de standaard aanbevolen hiërarchie van Azure-landingszones. U kunt de abonnementen ook onder nieuwe beheergroepen plaatsen als de hiërarchie van de beheergroep van uw organisatie voldoet aan de richtlijnen in de architectuur van de Azure-landingszone om aan de vereisten te voldoen.

In het volgende diagram ziet u een voorbeeld van de portfolio van gedeelde toepassingen abonnementsautomaat productlijn.

In dit diagram ziet u een voorbeeld van de portfolio van gedeelde toepassingen abonnementsautomaat productlijn met een netwerkarchitectuurdiagram met een routeerbare hub met het label 10.0.0.0/24 in het midden. Deze hub maakt verbinding met verschillende kleinere elementen, zoals één virtuele machine of opslagaccount, voor veel toepassingen die door hetzelfde team worden beheerd. Dit omvat een routeerbare spoke met het label 10.1.1.0/24, allemaal in één abonnement dat is uitgesneden in resourcegroepen. In het diagram ziet u ook aanvullende landingszones met pictogrammen voor verschillende netwerkonderdelen, zoals databases, opslagservices en virtuele machines waarmee het portfolioabonnement voor toepassingen delen verbinding kan maken via peering van virtuele netwerken via de hub.

Gebruik de productlijn voor het portfolio van gedeelde toepassingen als:

• Uw toepassingsteam moet verschillende kleine resources of onderdelen leveren die hun toepassingen delen, maar de onderdelen passen niet rechtstreeks in een van de toegewezen landingszones voor toepassingen.

• U hebt resources of onderdelen die u moet delen tussen toepassingen in dezelfde afdeling, maar de onderdelen passen niet rechtstreeks in een van de toegewezen landingszones van toepassingen.

• Technologieplatformteams willen grote, gedeelde services hosten die worden beheerd, zoals AKS, Azure Virtual Desktop en Azure VMware Solution, zodat andere toepassingsteams hun toepassingen op de services kunnen gebruiken of hosten.

Sandbox

Gebruik de sandbox-productregel voor landingszone van toepassingen abonnementsautomaat om veilige, licht beheerde en zichtbare testgebieden te bieden voor het bouwen van PoCs of MVP's in Azure.

Zie Sandbox-omgevingen voor landingszones en Toepassingsontwikkelingsomgevingen beheren in Azure-landingszones voor meer informatie.

Sandboxes zijn vaak tijdgebonden of budgetbeperkingen, wat betekent dat ze een tijdslimiet of budgetlimiet hebben. In deze gevallen moet u de sandbox uitbreiden of verwijderen en buiten gebruik stellen.

Als uw organisatie geen sandbox-productregel biedt voor toepassingsteams of anderen om services in Azure te testen en te experimenteren, kunnen teams gebruikmaken van schaduw-IT-instellingen . Zo ja, dan kan uw organisatie moeite hebben om rapportage en zichtbaarheid te bieden en governance toe te passen op abonnementen die zakelijke gebruikers buiten de controle en het toezicht van uw platformteam maken.

Uw platformteam moet eenvoudig toegankelijk zijn, bij voorkeur selfservice en automatisch goedgekeurde toegang tot sandbox-abonnementen bieden voor gebruikers en teams van uw organisatie. Bied gebruikers en teams toegang tot een omgeving die uw platformteam kan bekijken en beheren om schaduw-IT-omgevingen te voorkomen die het platformteam niet kan openen of beheren, waardoor risico's ontstaan.

Sandboxes volgen vaak de netwerkconfiguratiebenadering van online productregelabonnementen, omdat u ze niet koppelt aan andere virtuele netwerken buiten de abonnementsgrens van de sandbox. Sandboxes hebben ook vaak extra besturingselementen om hybride connectiviteit met on-premises locaties of andere locaties te voorkomen. Gebruik deze besturingselementen zodat onbekende bronnen geen gegevens uit sandboxes naar niet-goedgekeurde locaties kunnen exfiltreren. U kunt een Azure-beleid gebruiken om deze besturingselementen af te dwingen.

Net als bij de productlijnen van het gedeelde toepassingsportfolio en techplatform kunt u ook de sandbox-productlijn delen tussen teams in dezelfde afdeling met dezelfde overwegingen. Maak geen enkel sandbox-abonnement en deel het tussen teams via resourcegroepen. Maak in plaats daarvan extra sandbox-abonnementen.

Gebruik de sandbox-productregel als u een veilig, veilig en beheerd Azure-abonnement moet bieden aan iedereen binnen uw organisatie die wil experimenteren, PoCs wil maken of MVP's in Azure wil maken. U moet deze gebruikers licht beheren en hen toegang verlenen tot alle services om schaduw-IT-praktijken te voorkomen.

Samenvatting en leerpunten

In dit artikel vindt u een overzicht van prescriptieve richtlijnen om u te helpen bij het navigeren in complexe abonnementsautomaat processen en het overstappen op implementatie.

Bepaal de vereisten van uw toekomstige toepassingsteams om de abonnementsautomaat productlijn te kiezen die het beste bij hen past. Identificeer vereisten voor de eerste set workloads die u bouwt of migreert om prioriteit te geven aan de abonnementsautomaat productlijnen die u wilt inschakelen en beschikbaar wilt maken via een selfservice-interface.

Elke productlijn heeft een implementatiekosten en onderhoudskosten. Evalueer de kosten voor de lange termijn ten opzichte van de voordelen en het gebruik op lange termijn.

Klanten schakelen doorgaans de volgende abonnementsautomaat productregels in eerste instantie in:

• Sandbox
• Corp verbonden
• Online

Aanvullende bronnen

Als u uw platform-engineeringbenadering verder wilt ondersteunen, bekijkt u de volgende resources wanneer u de abonnementsautomaat productlijnen en aanbiedingen van uw organisatie ontwerpt en implementeert:

• Video: Hoeveel abonnementen moet ik gebruiken in Azure?
• Platformlandingszones versus landingszones van toepassingen
• Beleidsregels die zijn opgenomen in referentie-implementaties van Azure-landingszones
• De architectuur van de Azure-landingszone aanpassen aan de vereisten
• Wat is het doel van verbindings-, corp- en onlinebeheergroepen?
• Toepassingsontwikkelingsomgevingen beheren in Azure-landingszones
• Principes voor platformengineering

Volgende stap

Voor de beste resultaten moet u zoveel mogelijk van het abonnementsautomaat proces automatiseren. Gebruik de aanvullende richtlijnen voor het implementeren van abonnementsautomaat automatisering.

Richtlijnen voor implementatie van abonnementen