Deze architectuur biedt richtlijnen voor het ontwerpen van een bedrijfskritieke workload in Azure. Het maakt gebruik van cloudeigen mogelijkheden om de betrouwbaarheid en operationele effectiviteit te maximaliseren. De ontwerpmethodologie voor goed ontworpen bedrijfskritieke workloads wordt toegepast op een internetgerichte toepassing, waar de workload wordt geopend via een openbaar eindpunt en geen privénetwerkconnectiviteit met andere bedrijfsresources vereist.
Belangrijk
De richtlijnen worden ondersteund door een voorbeeld-implementatie op productieniveau, waarin de essentiële toepassingsontwikkeling in Azure wordt getoond. Deze implementatie kan worden gebruikt als basis voor verdere ontwikkeling van oplossingen in uw eerste stap naar productie.
Betrouwbaarheidslaag
Betrouwbaarheid is een relatief concept en voor een workload die op de juiste wijze betrouwbaar is, moet deze overeenkomen met de bedrijfsvereisten eromheen, waaronder Service Level Objectives (SLO) en Service Level Agreements (SLA), om het percentage tijd vast te leggen dat de toepassing beschikbaar moet zijn.
Deze architectuur is gericht op een SLO van 99,99%, die overeenkomt met een toegestane jaarlijkse downtime van 52 minuten en 35 seconden. Daarom zijn alle ontwerpbeslissingen bedoeld om deze doel-SLO te bereiken.
Fooi
Om een realistische SLO te definiëren, is het belangrijk om inzicht te hebben in de SLA van alle Azure-onderdelen in de architectuur. Deze afzonderlijke getallen moeten worden samengevoegd om een samengestelde SLA te bepalen die moet worden afgestemd op workloaddoelen.
Raadpleeg goed ontworpen bedrijfskritieke workloads: Ontwerpen voor zakelijke vereisten.
Belangrijke ontwerpstrategieën
Veel factoren kunnen van invloed zijn op de betrouwbaarheid van een toepassing, zoals de mogelijkheid om te herstellen van fouten, regionale beschikbaarheid, effectiviteit van de implementatie en beveiliging. Deze architectuur past een reeks overkoepelende ontwerpstrategieën toe die zijn bedoeld om deze factoren aan te pakken en ervoor te zorgen dat de doelbetrouwbaarheidslaag wordt bereikt.
Redundantie in lagen
Implementeren naar meerdere regio's in een actief-actief model. De toepassing wordt verdeeld over twee of meer Azure-regio's die actief gebruikersverkeer verwerken.
Gebruik Beschikbaarheidszones (AZ's) voor alle services om de beschikbaarheid binnen één Azure-regio te maximaliseren en onderdelen te distribueren over fysiek afzonderlijke datacenters binnen een regio.
Kies resources die wereldwijde distributie ondersteunen.
Raadpleeg goed ontworpen bedrijfskritieke workloads: wereldwijde distributie.
Implementatiestempels
Implementeer een regionale stempel als een schaaleenheid waarbij een logische set resources onafhankelijk kan worden ingericht om de wijzigingen in de vraag bij te houden. Elke stempel past ook meerdere geneste schaaleenheden toe, zoals de Front-end-API's en achtergrondprocessors die onafhankelijk van elkaar kunnen worden ingeschaald en uitgeschaald.
Raadpleeg goed ontworpen bedrijfskritieke workloads: Architectuur voor schaaleenheden.
Betrouwbare en herhaalbare implementaties
Pas het principe van Infrastructure as code (IaC) toe met behulp van technologieën, zoals Terraform, om versiebeheer en een gestandaardiseerde operationele benadering voor infrastructuuronderdelen te bieden.
Implementeer nul downtime blauw/groen implementatiepijplijnen. Build- en release-pijplijnen moeten volledig worden geautomatiseerd om stempels als één operationele eenheid te implementeren met behulp van blauw/groen-implementaties waarop continue validatie is toegepast.
Pas omgevingsconsistentie toe op alle omgevingen, met dezelfde implementatiepijplijncode in productie- en preproductieomgevingen. Dit elimineert risico's die zijn gekoppeld aan implementatie- en procesvariaties in omgevingen.
Zorg voor continue validatie door geautomatiseerde tests te integreren als onderdeel van DevOps-processen, waaronder gesynchroniseerde belasting- en chaostests, om de status van zowel de toepassingscode als de onderliggende infrastructuur volledig te valideren.
Raadpleeg goed ontworpen bedrijfskritieke workloads: Implementatie en testen.
Operationele inzichten
Federatieve werkruimten hebben voor waarneembaarheidsgegevens. Bewakingsgegevens voor globale resources en regionale resources worden onafhankelijk opgeslagen. Een gecentraliseerd waarneembaarheidsarchief wordt niet aanbevolen om een single point of failure te voorkomen. Query's voor meerdere werkruimten worden gebruikt om een uniforme gegevenssink en één glasvenster te bereiken voor bewerkingen.
Maak een gelaagd statusmodel waarmee de toepassingsstatus wordt toegewezen aan een verkeerslichtmodel voor het contextualiseren. Statusscores worden berekend voor elk afzonderlijk onderdeel en vervolgens geaggregeerd op gebruikersstroomniveau en gecombineerd met belangrijke niet-functionele vereisten, zoals prestaties, als coëfficiënten om de toepassingsstatus te kwantificeren.
Raadpleeg goed ontworpen bedrijfskritieke workloads: statusmodellering.
Architectuur
*Download een Visio-bestand van deze architectuur.
De onderdelen van deze architectuur kunnen op deze manier breed worden gecategoriseerd. Zie Verwante resources voor productdocumentatie over Azure-services.
Globale resources
De wereldwijde resources leven lang en delen de levensduur van het systeem. Ze hebben de mogelijkheid om wereldwijd beschikbaar te zijn binnen de context van een implementatiemodel voor meerdere regio's.
Hier volgen de overwegingen op hoog niveau over de onderdelen. Zie Globale resources voor gedetailleerde informatie over de beslissingen.
Globale load balancer
Een globale load balancer is essentieel voor het betrouwbaar routeren van verkeer naar de regionale implementaties met een zekere mate van garantie op basis van de beschikbaarheid van back-endservices in een regio. Dit onderdeel moet ook de mogelijkheid hebben om inkomend verkeer te inspecteren, bijvoorbeeld via web application firewall.
Azure Front Door wordt gebruikt als het globale toegangspunt voor al het binnenkomende HTTP(S)-verkeer van de client, waarbij WAF-mogelijkheden (Web Application Firewall) worden toegepast op inkomend laag 7-verkeer. Tcp Anycast wordt gebruikt om routering te optimaliseren met behulp van het Microsoft backbone-netwerk en maakt transparante failover mogelijk in het geval van verminderde regionale status. Routering is afhankelijk van aangepaste statustests die de samengestelde status van belangrijke regionale resources controleren. Azure Front Door biedt ook een ingebouwd CDN (Content Delivery Network) om statische assets voor het websiteonderdeel in de cache op te cachen.
Een andere optie is Traffic Manager, een op DNS gebaseerde Load Balancer op basis van DNS. Fout is echter niet transparant voor alle clients, omdat DNS-doorgifte moet plaatsvinden.
Raadpleeg goed ontworpen bedrijfskritieke workloads: wereldwijde verkeersroutering.
Database
Alle statussen met betrekking tot de workload worden opgeslagen in een externe database, Azure Cosmos DB voor NoSQL. Deze optie is gekozen omdat deze beschikt over de functieset die nodig is voor het afstemmen van prestaties en betrouwbaarheid, zowel aan client- als serverzijden. Het wordt ten zeerste aanbevolen dat voor het account schrijfbewerking met meerdere masters is ingeschakeld.
Notitie
Hoewel een configuratie voor schrijfbewerkingen in meerdere regio's de gouden standaard voor betrouwbaarheid vertegenwoordigt, is er een aanzienlijke afweging van de kosten, die naar behoren moeten worden overwogen.
Het account wordt gerepliceerd naar elke regionale stempel en heeft ook zonegebonden redundantie ingeschakeld. Automatische schaalaanpassing is ook ingeschakeld op containerniveau, zodat containers de ingerichte doorvoer automatisch schalen als dat nodig is.
Zie Data Platform voor bedrijfskritieke workloads voor meer informatie.
Raadpleeg goed ontworpen bedrijfskritieke workloads: wereldwijd gedistribueerd gegevensarchief met meerdere schrijfbewerkingen.
Containerregister
Azure Container Registry wordt gebruikt om alle containerinstallatiekopieën op te slaan. Het heeft mogelijkheden voor geo-replicatie waarmee de resources kunnen functioneren als één register, dat meerdere regio's met regionale registers met meerdere masters biedt.
Als beveiligingsmaatregel staat u alleen toegang tot vereiste entiteiten toe en verifieert u die toegang. In de implementatie is bijvoorbeeld beheerderstoegang uitgeschakeld. Het rekencluster kan dus alleen installatiekopieën ophalen met Microsoft Entra-roltoewijzingen.
Raadpleeg goed ontworpen bedrijfskritieke workloads: Containerregister.
Regionale resources
De regionale resources worden ingericht als onderdeel van een implementatiestempel in één Azure-regio. Deze resources delen niets met resources in een andere regio. Ze kunnen onafhankelijk worden verwijderd of gerepliceerd naar extra regio's. Ze delen echter globale resources tussen elkaar.
In deze architectuur implementeert een uniforme implementatiepijplijn een stempel met deze resources.
Hier volgen de overwegingen op hoog niveau over de onderdelen. Zie Regionale stempelresources voor gedetailleerde informatie over de beslissingen.
Front-end
Deze architectuur maakt gebruik van een toepassing met één pagina (SPA) die aanvragen verzendt naar back-endservices. Een voordeel is dat de rekenkracht die nodig is voor de website-ervaring wordt offload naar de client in plaats van uw servers. De beveiligd-WACHTWOORDVERIFICATIE wordt gehost als een statische website in een Azure Storage-account.
Een andere keuze is Azure Static Web Apps, waarmee aanvullende overwegingen worden geïntroduceerd, zoals hoe de certificaten worden weergegeven, connectiviteit met een globale load balancer en andere factoren.
Statische inhoud wordt meestal in de cache opgeslagen in een archief dicht bij de client, met behulp van een CDN (Content Delivery Network), zodat de gegevens snel kunnen worden geleverd zonder rechtstreeks met back-endservers te communiceren. Het is een rendabele manier om de betrouwbaarheid te verhogen en de netwerklatentie te verminderen. In deze architectuur worden de ingebouwde CDN-mogelijkheden van Azure Front Door gebruikt voor het opslaan van statische website-inhoud in het edge-netwerk.
Rekencluster
De back-end-berekening voert een toepassing uit die uit drie microservices bestaat en staatloos is. Containerisatie is dus een geschikte strategie voor het hosten van de toepassing. Azure Kubernetes Service (AKS) is gekozen omdat deze voldoet aan de meeste bedrijfsvereisten en Kubernetes veel wordt gebruikt in veel branches. AKS ondersteunt geavanceerde schaalbaarheids- en implementatietopologieën. De SLA-laag AKS Uptime wordt ten zeerste aanbevolen voor het hosten van bedrijfskritieke toepassingen, omdat deze beschikbaarheidsgaranties biedt voor het Kubernetes-besturingsvlak.
Azure biedt andere rekenservices, zoals Azure Functions en Azure-app Services. Deze opties offloaden extra beheerverantwoordelijkheden naar Azure ten koste van flexibiliteit en dichtheid.
Notitie
Vermijd het opslaan van de status op het rekencluster, rekening houdend met de tijdelijke aard van de stempels. Behoud zo veel mogelijk de status in een externe database om schaal- en herstelbewerkingen lichtgewicht te houden. In AKS veranderen pods bijvoorbeeld regelmatig. Door de status aan pods te koppelen, wordt de belasting van gegevensconsistentie toegevoegd.
Raadpleeg goed ontworpen bedrijfskritieke workloads: Container Orchestration en Kubernetes.
Regionale berichtbroker
Om de prestaties te optimaliseren en de reactiesnelheid tijdens piekbelasting te behouden, gebruikt het ontwerp asynchrone berichten om intensieve systeemstromen te verwerken. Omdat een aanvraag snel wordt bevestigd aan de front-end-API's, wordt de aanvraag ook in de wachtrij geplaatst in een berichtenbroker. Deze berichten worden vervolgens gebruikt door een back-endservice die bijvoorbeeld een schrijfbewerking naar een database verwerkt.
Het hele stempel is staatloos, behalve op bepaalde punten, zoals deze berichtbroker. Gegevens worden gedurende korte tijd in de wachtrij geplaatst in de broker. De berichtenbroker moet ten minste eenmaal levering garanderen. Dit betekent dat berichten in de wachtrij staan als de broker niet meer beschikbaar is nadat de service is hersteld. Het is echter de verantwoordelijkheid van de consument om te bepalen of deze berichten nog steeds moeten worden verwerkt. De wachtrij wordt verwijderd nadat het bericht is verwerkt en opgeslagen in een globale database.
In dit ontwerp wordt Azure Event Hubs gebruikt. Er is een extra Azure Storage-account ingericht voor controlepunten. Event Hubs is de aanbevolen keuze voor use cases waarvoor een hoge doorvoer is vereist, zoals gebeurtenisstreaming.
Voor gebruiksvoorbeelden waarvoor aanvullende berichtgaranties zijn vereist, wordt Azure Service Bus aanbevolen. Het maakt doorvoeringen in twee fasen mogelijk met een cursor aan de clientzijde, evenals functies zoals een ingebouwde wachtrij voor dode letters en ontdubbelingsmogelijkheden.
Zie Berichtenservices voor bedrijfskritieke workloads voor meer informatie.
Regionale geheime opslag
Elke stempel heeft een eigen Azure Key Vault waarin geheimen en configuratie worden opgeslagen. Er zijn algemene geheimen, zoals verbindingsreeks s voor de globale database, maar er is ook informatie die uniek is voor één stempel, zoals de Event Hubs verbindingsreeks. Ook voorkomen onafhankelijke resources een single point of failure.
Raadpleeg goed ontworpen bedrijfskritieke workloads: beveiliging van gegevensintegriteit.
Implementatiepijplijn
Build- en release-pijplijnen voor een bedrijfskritieke toepassing moeten volledig worden geautomatiseerd. Daarom hoeft er geen actie handmatig te worden uitgevoerd. Dit ontwerp demonstreert volledig geautomatiseerde pijplijnen die elke keer een gevalideerde stempel implementeren. Een andere alternatieve aanpak is het implementeren van rolling updates op een bestaande stempel.
Opslagplaats voor broncode
GitHub wordt gebruikt voor broncodebeheer en biedt een maximaal beschikbaar Git-platform voor samenwerking met toepassingscode en infrastructuurcode.
Pijplijnen voor continue integratie/continue levering (CI/CD)
Geautomatiseerde pijplijnen zijn vereist voor het bouwen, testen en implementeren van een missieworkload in preproductie - en productieomgevingen. Azure Pipelines wordt gekozen op basis van de uitgebreide set hulpprogramma's die gericht kunnen zijn op Azure en andere cloudplatforms .
Een andere keuze is GitHub Actions voor CI/CD-pijplijnen. Het toegevoegde voordeel is dat broncode en de pijplijn kunnen worden gecolocatied. Azure Pipelines is echter gekozen vanwege de uitgebreidere CD-mogelijkheden.
Raadpleeg goed ontworpen bedrijfskritieke workloads: DevOps-processen.
Agents bouwen
Door Microsoft gehoste buildagents worden door deze implementatie gebruikt om de complexiteit en beheeroverhead te verminderen. Zelf-hostende agents kunnen worden gebruikt voor scenario's waarvoor een beperkte beveiligingspostuur is vereist.
Notitie
Het gebruik van zelf-hostende agents wordt gedemonstreerd in de mission critical - Verbinding maken ed reference implementation.
Waarneembaarheidsbronnen
Operationele gegevens van toepassingen en infrastructuur moeten beschikbaar zijn om effectieve bewerkingen mogelijk te maken en de betrouwbaarheid te maximaliseren. Deze verwijzing biedt een basislijn voor het bereiken van holistische waarneembaarheid van een toepassing.
Geïntegreerde gegevenssink
- Azure Log Analytics wordt gebruikt als een geïntegreerde sink voor het opslaan van logboeken en metrische gegevens voor alle toepassings- en infrastructuuronderdelen.
- Azure-toepassing Insights wordt gebruikt als een APM-hulpprogramma (Application Performance Management) om alle bewakingsgegevens van toepassingen te verzamelen en deze rechtstreeks in Log Analytics op te slaan.
Bewakingsgegevens voor globale resources en regionale resources moeten onafhankelijk worden opgeslagen. Eén gecentraliseerd waarneembaarheidsarchief wordt niet aanbevolen om een single point of failure te voorkomen. Query's voor meerdere werkruimten worden gebruikt om één deelvenster glas te bereiken.
In deze architectuur moet het bewaken van resources binnen een regio onafhankelijk zijn van de stempel zelf, omdat als u een stempel verwijdert, u toch de waarneembaarheid wilt behouden. Elke regionale stempel heeft een eigen toegewezen Application Insights- en Log Analytics-werkruimte. De resources worden per regio ingericht, maar ze overleven de stempels.
Op dezelfde manier worden gegevens van gedeelde services zoals Azure Front Door, Azure Cosmos DB en Container Registry opgeslagen in een toegewezen exemplaar van Log Analytics Workspace.
Gegevensarchivering en -analyse
Operationele gegevens die niet vereist zijn voor actieve bewerkingen, worden geëxporteerd van Log Analytics naar Azure Storage-accounts voor zowel gegevensretentiedoeleinden als om een analytische bron voor AIOps te bieden, die kan worden toegepast om het toepassingsstatusmodel en de operationele procedures te optimaliseren.
Raadpleeg goed ontworpen bedrijfskritieke workloads: Voorspellende actie en AI-bewerkingen.
Aanvraag- en processorstromen
In deze afbeelding ziet u de aanvraag- en achtergrondprocessorstroom van de referentie-implementatie.
De beschrijving van deze stroom vindt u in de volgende secties.
Stroom voor websiteaanvragen
Een aanvraag voor de webgebruikersinterface wordt verzonden naar een globale load balancer. Voor deze architectuur is de globale load balancer Azure Front Door.
De WAF-regels worden geëvalueerd. WAF-regels zijn positief van invloed op de betrouwbaarheid van het systeem door te beschermen tegen verschillende aanvallen, zoals cross-site scripting (XSS) en SQL-injectie. Azure Front Door retourneert een fout bij de aanvrager als een WAF-regel wordt geschonden en de verwerking stopt. Als er geen WAF-regels zijn geschonden, wordt azure Front Door verder verwerkt.
Azure Front Door maakt gebruik van routeringsregels om te bepalen naar welke back-endpool een aanvraag moet worden doorgestuurd. Hoe aanvragen worden vergeleken met een routeringsregel. In deze referentie-implementatie kunnen azure Front Door-routeringsregels gebruikersinterface- en front-end-API-aanvragen routeren naar verschillende back-endbronnen. In dit geval komt het patroon '/*' overeen met de regel voor ui-routering. Met deze regel wordt de aanvraag gerouteerd naar een back-endpool die opslagaccounts bevat met statische websites die als host fungeren voor de toepassing met één pagina (BEVEILIGD-WACHTWOORDVERIFICATIE). Azure Front Door gebruikt de prioriteit en het gewicht die aan de back-ends in de pool zijn toegewezen om de back-end te selecteren om de aanvraag te routeren. Routeringsmethoden voor verkeer naar oorsprong. Azure Front Door maakt gebruik van statustests om ervoor te zorgen dat aanvragen niet worden doorgestuurd naar back-ends die niet in orde zijn. De beveiligd-WACHTWOORDVERIFICATIE wordt geleverd vanuit het geselecteerde opslagaccount met een statische website.
Notitie
De termen back-endpools en back-ends in Azure Front Door Classic worden oorsprongsgroepen en origins genoemd in Azure Front Door Standard of Premium-lagen.
De BEVEILIGD-WACHTWOORDVERIFICATIE maakt een API-aanroep naar de front-endhost van Azure Front Door. Het patroon van de API-aanvraag-URL is '/api/*'.
Front-end-API-aanvraagstroom
De WAF-regels worden geëvalueerd zoals in stap 2.
Azure Front Door komt overeen met de aanvraag voor de API-routeringsregel volgens het patroon /api/*. De REGEL voor API-routering stuurt de aanvraag naar een back-endpool die de openbare IP-adressen voor NGINX-ingangscontrollers bevat die weten hoe aanvragen naar de juiste service in Azure Kubernetes Service (AKS) moeten worden gerouteerd. Net als voorheen gebruikt Azure Front Door de prioriteit en het gewicht die aan de back-ends zijn toegewezen om de juiste NGINX-back-end voor inkomend verkeer te selecteren.
Voor GET-aanvragen voert de front-end-API leesbewerkingen uit op een database. Voor deze referentie-implementatie is de database een globaal Azure Cosmos DB-exemplaar. Azure Cosmos DB heeft verschillende functies die het een goede keuze maken voor een essentiële workload, waaronder de mogelijkheid om eenvoudig regio's met meerdere schrijfbewerkingen te configureren, waardoor automatische failover voor lees- en schrijfbewerkingen naar secundaire regio's mogelijk is. De API maakt gebruik van de client-SDK die is geconfigureerd met logica voor opnieuw proberen om te communiceren met Azure Cosmos DB. De SDK bepaalt de optimale volgorde van beschikbare Azure Cosmos DB-regio's om mee te communiceren op basis van de parameter ApplicationRegion.
Voor POST- of PUT-aanvragen voert de Front-end-API schrijfbewerkingen uit naar een berichtenbroker. In de referentie-implementatie is de berichtenbroker Azure Event Hubs. U kunt Service Bus ook kiezen. Een handler leest later berichten van de berichtenbroker en voert eventuele vereiste schrijfbewerkingen uit naar Azure Cosmos DB. De API gebruikt de client-SDK om schrijfbewerkingen uit te voeren. De client kan worden geconfigureerd voor nieuwe pogingen.
Achtergrondprocessorstroom
De achtergrondprocessors verwerken berichten van de berichtenbroker. De achtergrondprocessors gebruiken de client-SDK om leesbewerkingen uit te voeren. De client kan worden geconfigureerd voor nieuwe pogingen.
De achtergrondprocessors voeren de juiste schrijfbewerkingen uit op het globale Azure Cosmos DB-exemplaar. De achtergrondprocessors gebruiken de client-SDK die is geconfigureerd met opnieuw proberen verbinding te maken met Azure Cosmos DB. De lijst met voorkeursregio's van de client kan worden geconfigureerd met meerdere regio's. Als een schrijfbewerking mislukt, wordt de nieuwe poging uitgevoerd in de volgende voorkeursregio.
Ontwerpgebieden
We raden u aan deze ontwerpgebieden te verkennen voor aanbevelingen en best practice-richtlijnen bij het definiëren van uw bedrijfskritieke architectuur.
| Ontwerpgebied | Omschrijving |
|---|---|
| Toepassingsontwerp | Ontwerppatronen die schalen en foutafhandeling mogelijk maken. |
| Toepassingsplatform | Opties en oplossingen voor infrastructuur voor mogelijke foutgevallen. |
| Gegevensplatform | Keuzes in gegevensopslagtechnologieën, geïnformeerd door het evalueren van de vereiste volume-, snelheids-, variatie- en betrouwbaarheidskenmerken. |
| Netwerken en connectiviteit | Netwerkoverwegingen voor het routeren van binnenkomend verkeer naar stempels. |
| Statusmodellering | Waarneembaarheidsoverwegingen door middel van een gecorreleerde bewaking van klantimpact om de algehele toepassingsstatus te bepalen. |
| Implementatie en testen | Strategieën voor CI/CD-pijplijnen en automatiseringsoverwegingen, met geïntegreerde testscenario's, zoals gesynchroniseerde belastingtests en chaos-injecties (chaos). |
| Beveiliging | Risicobeperking van aanvalsvectoren via het Microsoft Zero Trust-model. |
| Operationele procedures | Processen met betrekking tot implementatie, sleutelbeheer, patching en updates. |
** Geeft ontwerpgebiedoverwegingen aan die specifiek zijn voor deze architectuur.
Verwante resources
Raadpleeg deze artikelen voor productdocumentatie over de Azure-services die in deze architectuur worden gebruikt.
- Azure Front Door
- Azure Cosmos DB
- Azure Container Registry
- Azure Log Analytics
- Azure Key Vault
- Azure Service Bus
- Azure Kubernetes Service
- Azure Application Insights
- Azure Event Hubs
- Azure Blob-opslag
Deze architectuur implementeren
Implementeer de referentie-implementatie om een volledig inzicht te krijgen in overwogen resources, inclusief hoe ze worden operationeel gemaakt in een bedrijfskritieke context. Het bevat een implementatiehandleiding die is bedoeld om een oplossingsgerichte benadering te illustreren voor bedrijfskritieke toepassingsontwikkeling in Azure.
Volgende stappen
Als u de basislijnarchitectuur wilt uitbreiden met netwerkbesturingselementen voor inkomend en uitgaand verkeer, raadpleegt u deze architectuur.