Azure-landingszones implementeren
In dit artikel worden de beschikbare opties besproken voor het implementeren van platform- en toepassingslandingszones. Platformlandingszones bieden gecentraliseerde services die worden gebruikt door workloads. Landingszones voor toepassingen zijn omgevingen die zijn geïmplementeerd voor de workloads zelf.
Belangrijk
Lees meer over de definities en implementaties van platform- versus applicatielandingszones in Wat is een Azure landing zone? in het Cloud Adoption Framework voor Azure.
In dit artikel worden de implementatieopties voor platform- en toepassingslandingszones beschreven.
Een platformlandingszonebenadering kiezen
De volgende opties voor platformimplementatie bieden een aanbevolen aanpak voor het implementeren en beheren van de conceptuele architectuur van de Azure-landingszone , zoals beschreven in het Cloud Adoption Framework. Afhankelijk van aanpassingen is de resulterende architectuur mogelijk niet hetzelfde voor alle implementatieopties die hier worden vermeld. De verschillen tussen de platformimplementatieopties zijn gebaseerd op hoe ze verschillende technologieën gebruiken, verschillende benaderingen hanteren en op verschillende manieren worden aangepast.
Standaardimplementatieopties
Standaardimplementatieopties hebben betrekking op typisch Enterprise Azure-gebruik.
| Implementatieoptie voor Azure-platformlandingszone | Beschrijving |
|---|---|
| Azure Portal-implementatie | Een azure-portalimplementatie die een volledige implementatie biedt van de conceptuelearchitectuur van de azure-landingszone |
| Bicep-implementatie | Een modulaire, op infrastructuur als code gebaseerde implementatie waarbij elke Bicep-module een kernmogelijkheid inkapselt van de conceptuele architectuur van de Azure-landingszone. Hoewel de modules afzonderlijk kunnen worden geïmplementeerd, stelt het ontwerp het gebruik van orchestratormodules voor om de complexiteit van het implementeren van verschillende topologieën met de modules in te kapselen. Bicep-implementatie ondersteunt openbare Azure-cloud, Regio's van Azure China 21Vianet en Azure US Government-clouds. |
| Terraform-implementatie | Deze implementatie op basis van infrastructuur als code biedt een Terraform Orchestrator-module en biedt u ook de mogelijkheid om elke platformmogelijkheid afzonderlijk of als geheel te implementeren. |
Varianten en specialisaties
Hoewel de standaardplatformimplementatieopties typische azure-gebruik voor ondernemingen aanpakken, zijn er enkele implementatieopties die zich richten op specifieke specialisaties.
| Implementatieoptie | Beschrijving |
|---|---|
| Soevereine landingszone | De onafhankelijke landingszone is een variant van de Azure-landingszones die zijn bedoeld voor organisaties die geavanceerde onafhankelijke besturingselementen nodig hebben. |
Partnerimplementaties
Partnerprogramma's zoals de Azure Migrate en moderniseer kunnen u helpen bij het ontwerpen en implementeren van uw platformlandingszone die specifiek is voor de behoeften van uw organisatie. Deze implementaties beginnen met de conceptuele architectuur van Azure-landingszone en helpen bij het ontwerpen van configuraties die specifiek zijn voor uw strategie voor cloudimplementatie, organisatietopologie en gewenste resultaten.
Ondernemingsbeleid als code (EPAC) voor beleidsbeheer
Enterprise Policy as code (EPAC) is een alternatieve methode voor het implementeren, beheren en gebruiken van Azure Policy in de Azure-omgeving van uw organisatie. U kunt EPAC gebruiken in plaats van de standaardplatformopties om het beleid te beheren in een Azure-landingszonesomgeving. Zie EPAC integreren met Azure-landingszones voor meer informatie over de integratiebenadering.
Bedrijfsbeleid in codevorm is het meest geschikt voor geavanceerdere en volwassen DevOps- en infrastructuur-als-code-klanten. Klanten van elke grootte kunnen echter EPAC gebruiken als ze dat willen nadat ze deze hebben beoordeeld. Zie eerst Wie moet EPAC gebruiken om ervoor te zorgen dat u bent uitgelijnd?.
Notitie
Vergelijk de levenscyclus en flexibiliteit van de twee benaderingen voordat u besluit welke benadering u op lange termijn gebruikt. Begin met het evalueren van het systeemeigen beleidsbeheer dat wordt geleverd in de standaard implementatie die wordt beschreven in de standaardplatformopties. Als deze implementatie niet lijkt alsof deze ideaal is voor uw governancebehoeften, voert u een MVP of een proof-of-concept uit met behulp van EPAC. Het is belangrijk dat u opties vergelijkt, valideert en bevestigt voordat u een benadering implementeert, omdat het een complex proces is om de methoden voor beleidsbeheer te wijzigen nadat deze zijn vastgesteld.
Azure-landingszones gebruiken
Nadat u de platformlandingszone hebt geïmplementeerd, moet u deze gebruiken en onderhouden. Zie de richtlijnen voor het up-to-date houden van uw Azure-landingszone voor meer informatie.
Azure-governance visualiseren
Azure-governance visualiseren is bedoeld om u te helpen een holistisch overzicht te krijgen van uw technische Azure-governance-implementatie door de puntjes te verbinden en geavanceerde rapporten te bieden.
Abonnementsverkoop
Nadat de landingszone en governancestrategie van het platform zijn geïmplementeerd, is de volgende stap het vaststellen van consistentie over hoe abonnementen worden gemaakt en operationeel worden gemaakt voor eigenaren van workloads. Democratisering van abonnementen is een ontwerpprincipe van Azure-landingszones die gebruikmaken van abonnementen als beheer- en schaaleenheden. Deze aanpak versnelt de migratie van toepassingen en de ontwikkeling van nieuwe toepassingen.
Het abonnementenproces standaardiseert hoe procesplatformteams worden gebruikt, zodat workloadteams abonnementen kunnen aanvragen en platformteams die abonnementen kunnen implementeren en beheren. Hiermee kunnen toepassingsteams op een consistente en gereguleerde manier toegang krijgen tot Azure, waardoor zeker wordt gesteld dat alle vereisten volledig worden verzameld.
Het is ook gebruikelijk dat organisaties meerdere verschillende stijlen van abonnementen hebben die in hun tenant kunnen worden verdeeld, vaak 'productlijnen' in de branche worden genoemd. Zie Stel gemeenschappelijke productlijnen voor abonnementsverkoop vast voor aanbevolen "productlijnen" voor uw organisatie.
Volg de implementatierichtlijnen voor abonnementsverkoop in om aan de slag te gaan. Bekijk vervolgens de volgende modules voor infrastructuur als code, die flexibiliteit bieden om aan uw implementatiebehoeften te voldoen.
| Implementatieoptie | Beschrijving |
|---|---|
| Bicep abonnementsautomaat | De Bicep-modules voor abonnementsbeheer zijn ontworpen om de implementatie van de afzonderlijke landingszones voor toepassingen te coördineren, gebaseerd op de configuratie per workload. Ze kunnen handmatig of als onderdeel van automatisering worden uitgevoerd. |
| Terraform-abonnementsautomaat | Deze modules maken gebruik van Terraform om de implementatie van de afzonderlijke landingszones voor toepassingen in te delen. |
Architecturen voor landingszones voor toepassingen
Landingszones voor toepassingen bestaan uit een of meer abonnementen die zijn geïmplementeerd als goedgekeurde bestemmingen voor resources die eigendom zijn van een toepassingsteam van een workload. Een workload kan profiteren van diensten die zijn geïmplementeerd in platformlandingszones, of het kan geïsoleerd worden van die gecentraliseerde middelen. De landingszones voor toepassingen moeten worden gebruikt voor centraal beheerde toepassingen, gedecentraliseerde workloads die eigendom zijn van toepassingsteams en centraal beheerde hostingplatforms zoals Azure Kubernetes Service (AKS) die toepassingen voor meerdere bedrijfseenheden kunnen hosten. Tenzij ze door abnormale beperkingen worden gedwongen, bevatten toepassingslandingszone-abonnementen alleen resources van één workload of logische toepassingsgrens, zoals hun levenscyclus of kriticiteitsclassificatie.
Workloadteams communiceren de vereisten van hun workload via een formeel proces dat is vastgesteld door het platformteam. Het platformteam implementeert over het algemeen een leeg abonnement dat is geregistreerd met alle vereiste governance. Een workloadarchitect ontwerpt vervolgens een oplossing die binnen de beperkingen van die landingszone voor toepassingen werkt en profiteert van gedeelde platformfuncties (zoals firewalls en cross-premisis-routering), waar praktisch.
Het is mogelijk dat een architect een referentiearchitectuur kan aanpassen die niet specifiek is ontworpen met een toepassingslandingszone in gedachten. Microsoft Learn bevat echter ook richtlijnen voor toepassings- en gegevensplatforms voor workloadteams die specifiek betrekking hebben op contexten van landingszones voor toepassingen. Platformteams moeten op de hoogte worden gesteld van de richtlijnen die beschikbaar zijn voor workloadteams, zodat het platformteam kan anticiperen op de typen en kenmerken van de werkbelasting die mogelijk aanwezig zijn in de organisatie.
| Architectuur van toepassingslandingszone | Beschrijving |
|---|---|
| Azure App Service-omgeving | Bewezen aanbevelingen en overwegingen voor zowel multitenant- als App Service-omgevingsscenario's met een referentie-implementatie. |
| |
Bewezen aanbevelingen en overwegingen voor het implementeren van een intern API Management-exemplaar als onderdeel van een referentie-implementatie. Het scenario maakt gebruik van Azure Application Gateway om veilig toegangsbeheer te bieden en gebruikt Azure Functions als back-end. |
| Azure Arc voor hybride en multicloudscenario's | Servers met Azure Arc, Kubernetes en sql Managed Instance met Azure Arc. |
| Azure Container Apps | Deze richtlijnen voor Azure Container Apps geven een overzicht van het strategische ontwerppad en definiëren de technische doelstatus voor het implementeren van Azure Container Apps. Een toegewezen workload-team is eigenaar van en beheert dit platform. |
| Azure Data Factory | Leer hoe u een traditioneel medaillon lakehouse kunt hosten in een toepassingslandingszone. |
| Azure OpenAI chat-werkbelasting | Beschrijft hoe u een typische Azure OpenAI-chattoepassing integreert binnen Azure-landingszones om gecentraliseerde gedeelde resources te gebruiken terwijl u zich houdt aan governance en kostenefficiëntie, met richtlijnen voor workloadteams over implementatie en beheer. |
| Azure Kubernetes Service (AKS) | Richtlijnen en gerelateerde infrastructuur als codesjablonen die het strategische ontwerppad en de technische status van een AKS-implementatie vertegenwoordigen die worden uitgevoerd binnen een landingszone van een toepassing. |
| Azure Red Hat OpenShift | Een opensource-verzameling Terraform-sjablonen die een optimale Azure Red Hat OpenShift-implementatie vertegenwoordigen die Azure- en Red Hat-resources bevat. |
| Azure Synapse Analytics | Een architectuurbenadering voor het voorbereiden van landingszones voor toepassingen voor een typische bedrijfsimplementatie van Azure Synapse Analytics. |
| Azure Virtual Desktop | Arm-, Bicep- en Terraform-sjablonen waarnaar moet worden verwezen bij het ontwerpen van Azure Virtual Desktop-implementaties, waaronder het maken van hostgroepen, netwerken, opslag, bewaking en invoegtoepassingen. |
| Azure Virtuele Machines | Deze architectuur breidt de richtlijnen uit van de basislijnarchitectuur van de virtuele Azure-machine (VM) naar een landingszone voor toepassingen, met richtlijnen voor het instellen van abonnementen, patchcompatibiliteit en andere problemen met organisatiebeheer. |
| Azure VMware Solution | ARM-, Bicep- en Terraform-sjablonen die handig zijn bij het ontwerpen van VMware-implementaties, waaronder de privécloud van Azure VMware Solution, jump box, netwerken, bewaking en invoegtoepassingen. |
| Citrix op Azure | Ontwerprichtlijnen voor het Cloud Adoption Framework voor Citrix Cloud in een landingszone op ondernemingsniveau van Azure voor veel ontwerpgebieden. |
| Red Hat Enterprise Linux (RHEL) op Azure | De landingszone voor Red Hat Enterprise Linux (RHEL) in Azure is een opensource-verzameling architectuurrichtlijnen en referentie-implementatieaanbevelingen die worden gebruikt voor het ontwerpen van RHEL-workloads in Microsoft Azure. |
| Hoge prestatieberekeningen (HPC) workloads | Een end-to-end HPC-clusteroplossing in Azure die gebruikmaakt van hulpprogramma's zoals Terraform, Ansible en Packer. Het behandelt best practices voor Azure-landingszones, waaronder het implementeren van identiteit, jump box-toegang en automatische schaalaanpassing. |
| Missiekritieke workloads | Hiermee wordt aangegeven hoe een workload die als bedrijfskritiek is geclassificeerd, moet worden ontworpen om te worden uitgevoerd binnen een landingszone van een toepassing. |
| SAP-workloads | Biedt richtlijnen en aanbevelingen voor SAP-workloads in lijn met best practices voor Azure-landingszones. Biedt aanbevelingen voor het maken van infrastructuuronderdelen, zoals rekenkracht, netwerken, opslag, bewaking en opbouw van SAP-systemen. |
Workloads zijn vaak een verzameling van verschillende technologieën en classificaties. We raden u aan gerelateerd referentiemateriaal te bekijken voor alle technologieën in uw workload. Het is bijvoorbeeld belangrijk om inzicht te krijgen in de richtlijnen van de Azure OpenAI-chat en de Azure API Management om te begrijpen of uw generatieve AI-scenario zou profiteren van het toevoegen van een API-gateway.