Latest / M365.FM – Microsoft 365, Copilot & AI podcast in het Nederlands / Wat is een Azure Landing Zone? De 8 ontwerpgebieden uitgelegd: governance in plaats van cloudchaos (AI-nasynchronisatie)

Transcript

Wat is een Azure Landing Zone? De 8 ontwerpgebieden uitgelegd: governance in plaats van cloudchaos (AI-nasynchronisatie) · M365.FM – Microsoft 365, Copilot & AI podcast in het Nederlands

0:00
Speaker 2: Welkom bij weer een nieuwe aflevering van Microsoft Knowledge Nuggets
0:02
Speaker 2: hier op M365FM. Ik ben je gastheer Mirko Peters. In
0:05
Speaker 2: deze serie pakken we één Microsoft-technologie en leggen we deze
0:08
Speaker 2: in begrijpelijke taal uit. Het onderwerp van vandaag is er
0:10
Speaker 2: een waar bijna iedereen van heeft gehoord, maar de meeste
0:12
Speaker 2: mensen niet echt kunnen uitleggen. Azure Landing Zones. Dit is
0:14
Speaker 2: het beeld. Stel je voor dat je een Azure tenant
0:17
Speaker 2: erft waar elk team zijn eigen gang ging. Geen NAA-mevingsconventie,
0:20
Speaker 2: geen beleid, geen netwerkplan, overal subscriptions. Sommige voor productie, sommige
0:24
Speaker 2: voor testen, en je kunt het verschil niet zien. Niemand
0:26
Speaker 2: weet wie wat bezit. De rekening is een mysterie en
0:28
Speaker 2: als er iets kapot gaat, kost het uren om het
0:30
Speaker 2: probleem te vinden. Dat is het probleem van cloud-garels en
0:32
Speaker 2: het komt verrassend vaak voor. Vaker dan je zou denken.
0:35
Speaker 2: Azure landingzones zijn wat deze puinhoop voorkomt voordat het begint.
0:39
Speaker 2: Aan het einde van deze aflevering begrijp je wat een
0:41
Speaker 2: landingzone echt is, waarom de acht ontwerpgebieden er toe doen
0:44
Speaker 2: en hoe je de meest gemaakte fouten vermijdt. Pak je
0:46
Speaker 2: koffie en laten we erin duiken. Wat is eigenlijk een
0:49
Speaker 2: Azure Landing Zone? De meeste mensen denken dat een Azure
0:51
Speaker 2: Landing Zone een product is waarop je klikt om te implementeren,
0:54
Speaker 2: maar dat is het niet. Er is geen knop in
0:55
Speaker 2: de portal waarop staat, maak landing zone. Zo werkt het niet.
0:58
Speaker 2: Een landing zone is een vooraf geconfigureerde omgeving waar Fangrails
1:01
Speaker 2: al aanwezig zijn. Netwerken, identiteit, monitoring, beleid, alles is al
1:05
Speaker 2: verbonden voordat er workloads arriveren. Zie het als het kopen
1:08
Speaker 2: van een huis dat al elektriciteit, leidingwerk en een beveiligingssysteem heeft.
1:11
Speaker 2: Je trekt er gewoon in en begint te werken zonder
1:13
Speaker 2: zelf de bedrading aan te hoeven leggen. Het belangrijkste idee
1:16
Speaker 2: is dat de subscription de eenheid van isolatie is, niet
1:18
Speaker 2: de resource group. Een subscription is je grens voor de
1:21
Speaker 2: blessed radius. Je geeft een team een subscription omdat subscriptions
1:24
Speaker 2: hun eigen quota-limieten, beleidstoewijzingen en facturering dragen. De landingzone omhult
1:28
Speaker 2: die subscription met alles wat centraal is besloten. Welke regio's
1:31
Speaker 2: zijn toegestaan, met welk netwerk ze verbinding maken, welke tags
1:35
Speaker 2: verplicht zijn en wat ze verboden zijn te doen. Dus
1:37
Speaker 2: wat dwingt de regels eigenlijk af? Azure Policy, geen documentatie,
1:40
Speaker 2: geen goede bedoelingen. Het wordt toegewezen op managementgroepniveau en doet
1:43
Speaker 2: drie dingen. Deny blokkeert zaken zoals niet toegestane regio's of
1:46
Speaker 2: publieke IP-adressen. Audit markeert niet conforme resources zonder ze te blokkeren.
1:50
Speaker 2: DeployEF not exists herstelt automatisch door zaken zoals diagnostische instellingen
1:54
Speaker 2: voor Log Analytics of Microsoft Defender plannen te implementeren. Dit
1:57
Speaker 2: is het verschil tussen governance die een wiki pagina is
1:59
Speaker 2: en governance die code is. Teams bewegen snel binnen hun box,
2:03
Speaker 2: maar het platform team beheert de box, niet de inhoud.
2:05
Speaker 2: De grote verschuiving is dat teams hun eigen subscriptions hebben
2:08
Speaker 2: terwijl het centrale team de regels bepaalt. Identiteit en governance,
2:11
Speaker 2: de voordeur en het regelboek. Het zit zo, een landingzone
2:14
Speaker 2: is niet zomaar iets, het is opgebouwd uit acht ontwerpgebieden.
2:18
Speaker 2: Laten we de eerste drie onder de loep nemen. Als
2:20
Speaker 2: eerste zijn er Azure Facturering en de EntraTenant. Dit gaat
2:23
Speaker 2: over het vanaf het begin correct instellen van je tenant
2:25
Speaker 2: en abonnement. Klinkt simpel, maar je zult verbaasd zijn hoeveel
2:28
Speaker 2: organisaties dit fout doen. Je moet nadenken over je factuurstructuur,
2:32
Speaker 2: je inschrijving en hoe alles verbonden is met je EntraTenant
2:34
Speaker 2: voordat je iets implementeert. Je primaire beveiligingsgrens is identiteits- en toegangsbeheer.
2:39
Speaker 2: Zie Entra ID als de receptie in een kantoorgebouw. Het
2:42
Speaker 2: bepaalt wie er binnenkomt en wat ze mogen doen. Je
2:44
Speaker 2: wilt Privileged Identity Management of PIM gebruiken en RBAC-rollen met
2:48
Speaker 2: de minste rechten afdwingen. Geef niet iedereen eigenaar toegang, dat
2:52
Speaker 2: is vragen om problemen. Gebruik in plaats daarvan PIM om
2:54
Speaker 2: tijdelijke just-in-time toegang te verlenen wanneer iemand die echt nodig
2:57
Speaker 2: heeft en stel periodieke toegangsbeoordelingen in om overbodige rechten op
3:00
Speaker 2: te schonen. Het derde ontwerpgebied is Resource Organisatie. Beheergroepen, abonnementen
3:05
Speaker 2: en resourcegroepen. Beheergroepen staan boven abonnementen en beleid en holtoewijzingen
3:09
Speaker 2: worden via de boomstructuur naar beneden overgeërfd. De referentiehierarchie van
3:13
Speaker 2: het Cloud Adoption Framework begint bij de tenant route, gevolgd
3:16
Speaker 2: door een tussengroep voor je organisatie. Daaronder heb je platform, landingzones,
3:20
Speaker 2: buitengebruikgesteld en sandbox. Platform bevat je gedeelde abonnementen, identiteitsbeheer en connectiviteit.
3:26
Speaker 2: Landingzones zijn opgesplitst in corp voor workloads die on-premises connectiviteit
3:30
Speaker 2: nodig hebben en online voor internetgerichte apps. Waarom is deze
3:33
Speaker 2: structuur belangrijk? Je wijst beleid één keer hoog in de
3:36
Speaker 2: boom toe en alles daaronder voldoet automatisch. Een praktijkvoorbeeld, een
3:39
Speaker 2: weigeringsbeleid aan de top blokkeert niet toegestane regio's voor elk
3:43
Speaker 2: abonnement daaronder. Je hoeft het niet vijftig keer te configureren.
3:46
Speaker 2: Stel het één keer in en het wordt overgeërfd, dat
3:48
Speaker 2: is de echte kracht van de beheergroep-hierarchie. Netwerken en beveiliging,
3:51
Speaker 2: de muren en de sloten. Identiteit en governance bepalen de regels,
3:55
Speaker 2: maar niets daarvan werkt als het netwerk een chaos is.
3:57
Speaker 2: Netwerktopologie en connectiviteit is ontwerpgebied 4, hoe je virtuele netwerken
4:01
Speaker 2: zijn gestructureerd. Er zijn twee hoofdpatronen, HAP en SPOKE, waarbij
4:05
Speaker 2: je één centraal virtueel netwerk als HAP hebt met meerdere
4:07
Speaker 2: SPOKE-netwerken die daarmee verbinden, of Azure Virtual One, Microsofts beheerde
4:12
Speaker 2: versie van dat idee op grotere schaal. De hub bevat
4:14
Speaker 2: al je gedeelde services. Azure Firewall voor verkeersinspectie, Express, Route
4:18
Speaker 2: of VPN, Gateways voor on-premises connectiviteit, DNS-omzetting, dingen die elke
4:22
Speaker 2: workload nodig heeft. De spokes zijn de plekken waar je
4:25
Speaker 2: workloads daadwerkelijk draaien. Ze koppelen met de hub, zodat verkeer
4:28
Speaker 2: door centrale services stroomt, Maar elke spook blijft geïsoleerd van
4:31
Speaker 2: de andere. Hier is een veelgemaakte fout. Teams creëren een
4:34
Speaker 2: enorm pering netwerk in plaats van een hap te gebruiken,
4:36
Speaker 2: waarbij elk virtueel netwerk direct met elk ander netwerk wordt verbonden.
4:39
Speaker 2: Dat werkt een tijdje, maar het wordt al snel een puinhoop.
4:42
Speaker 2: Je eindigt met een web van verbindingen dat niemand meer
4:44
Speaker 2: kan volgen. Een hap vereenvoudigt alles. Eén plek om te beheren,
4:47
Speaker 2: één plek om te beveiligen. Plan je IP-adres bereiken vooraf.
4:51
Speaker 2: Dit is belangrijker dan je denkt. Zodra spokes verbonden zijn
4:54
Speaker 2: met een HAP, zijn overlappende adresruimtes lastig te herstellen. Je
4:57
Speaker 2: kunt ze niet zomaar wijzigen. Je moet de pering verbreken,
5:00
Speaker 2: het bereik bijwerken en opnieuw verbinden. Als je productieworkloads hebt draaien,
5:03
Speaker 2: betekent dit downtime. Dus kies je CIDR bereiken vroegtijdig en
5:06
Speaker 2: zorg dat ze niet overlappen. Ontwerpvlak 5 betreft beveiligingsaanbevelingen, waaronder encryptie, identiteitsbescherming,
5:12
Speaker 2: dreigingsdetectie en vulnerability management. Schakel Microsoft Defender voor Cloud in
5:16
Speaker 2: voor alle abonnementen als basislijn. Het geeft je aanbevelingen voor
5:19
Speaker 2: Pasture Management... waarschuwingen en hersteladvies voor alles in je omgeving.
5:23
Speaker 2: Gebruik Private Endpoints om services buiten het openbare internet te houden.
5:27
Speaker 2: In plaats van een storage account via een openbaar IP
5:29
Speaker 2: te benaderen, geef je het een privaat IP binnen je
5:31
Speaker 2: virtuele netwerk. Het verkeer verlaat nooit de Microsoft backbone. Het
5:35
Speaker 2: is veiliger en eenvoudiger te beheren. Plaats netwerkbeveiligingsgroepen op elk
5:38
Speaker 2: subnet en blokkeer standaard inkomende RDP vanaf het internet. Dat
5:41
Speaker 2: zou de standaard moeten zijn. Als iemand externe toegang nodig heeft,
5:44
Speaker 2: gebruik die Azure Bastion of een Jumpbox, geen directe RDP-regel.
5:48
Speaker 2: Een voorbeeld uit de praktijk, een weigeringsbeleid dat openbare IP-adressen
5:51
Speaker 2: op storage accounts blokkeert. Je wijst het beleid toe op
5:53
Speaker 2: het niveau van de beheergroep en zodra iemand een storage
5:55
Speaker 2: account met een openbaar eindpunt probeert te implementeren, mislukt de implementatie.
5:58
Speaker 2: Het foutbericht vertelt waarom mensen moeten in plaats daarvan een
6:01
Speaker 2: privaat eindpunt gebruiken. Geen uitzonderingen, dat is governance die echt werkt,
6:05
Speaker 2: niet zomaar een suggestie in een of ander document. Beheer,
6:07
Speaker 2: governance en automatisering, om alles draaiende te houden. Dus, je
6:10
Speaker 2: hebt je gebouw met muren en sloten, maar wat gebeurt
6:12
Speaker 2: er eigenlijk binnenin? Je hebt toezicht nodig op alles. Ontwerp
6:15
Speaker 2: vlak 6 is beheer. Dat omvat monitoring, backup, logging en
6:18
Speaker 2: de operationele kant van de zaak. Je wilt één centrale
6:21
Speaker 2: log-analytics werkruimte waar elk abonnement zijn logs naartoe stuurt. Eén
6:24
Speaker 2: plek om alles te bevragen, waarschuwingen in te stellen en
6:26
Speaker 2: problemen op te lossen. Dat is het doel. Hoe zorg
6:28
Speaker 2: je er nu voor dat elke resource zijn diagnostische logs
6:31
Speaker 2: daarnaartoe stuurt? Dat doe je niet handmatig. Je maakt een
6:33
Speaker 2: beleid dat zegt, elke resource moet zijn diagnostische laks naar
6:36
Speaker 2: deze log analytics werkruimte sturen. En je stelt dat beleid
6:38
Speaker 2: in om te draaien in de deploy if not exists modus.
6:41
Speaker 2: Het resultaat, elke nieuwe resource wordt automatisch geconfigureerd. Niemand hoeft
6:44
Speaker 2: eraan te denken. Het gebeurt gewoon. Ontwerpgebied 7 is governance,
6:47
Speaker 2: waarbij Azure Policy wordt gebruikt om naleving af te dwingen.
6:50
Speaker 2: Je bundelt gerelateerde regels in wat een beleidsinitiatief of beleidsset
6:53
Speaker 2: wordt genoemd. Eén initiatief voor beveiliging, een andere voor kostenbeheer.
6:57
Speaker 2: Elk bevat meerdere beleidsregels die samenwerken. Hier is een voorbeeld,
7:01
Speaker 2: een beleidsset die encryptie, tagging en toegestaande grootte voor virtuele
7:04
Speaker 2: machines afdwingt. Je past dit toe op het niveau van
7:07
Speaker 2: de beheergroep. Elk abonnement daaronder neemt die regels over. Wanneer
7:10
Speaker 2: een ontwikkelaar een VM probeert te implementeren, controleert het beleid
7:14
Speaker 2: of deze een goedgekeurde grootte heeft, de vereiste tags bevat
7:16
Speaker 2: en versleutelde schijven gebruikt. Als een controle mislukt, wordt de
7:19
Speaker 2: implementatie direct geblokkeerd of gemarkeerd. Laten we duidelijk zijn over
7:22
Speaker 2: het verschil tussen governance op een wikipagina en governance als
7:25
Speaker 2: daadwerkelijke code. Een wikipagina zegt tag alstublieft uw resources. Beleid
7:29
Speaker 2: zegt u kunt geen resource implementeren zonder de vereiste tags.
7:33
Speaker 2: De een is een suggestie, de ander wordt automatisch afgedwongen.
7:36
Speaker 2: Ontwerpgebied 8 is platform, automatisering en DevOps. Infrastructure als code
7:40
Speaker 2: en CI, CD pipelines. Behandel de landingzone zelf als code.
7:44
Speaker 2: Dat betekent Bicep, ARM templates of Terraform opgeslagen in bronbeheer.
7:47
Speaker 2: Elke wijziging gaat via een pull request. Elke implementatie verloopt
7:51
Speaker 2: via een pipeline. Niet rondklikken in de Azure portal. Dit
7:53
Speaker 2: is waar Subscription Vending om de hoek komt kijken. Een
7:56
Speaker 2: herhaalbare pipeline die op aanvraag nieuwe abonnementen maakt. Een team
7:59
Speaker 2: dient een verzoek in met parameters zoals kostenplaats, netwerkgrootte en omgevingstype.
8:03
Speaker 2: De pipeline maakt het abonnement, plaatst het onder de juiste beheergroep,
8:07
Speaker 2: wijst budgetten toe, configureert het spooknetwerk en koppelt het aan
8:10
Speaker 2: de hub. Alles geautomatiseerd. Waarom is dit belangrijk? omdat het
8:14
Speaker 2: nieuwe abonnement compliant is vanaf het moment dat het bestaat.
8:17
Speaker 2: Het beleid is al van kracht op de beheergroep en
8:19
Speaker 2: het abonnement erft alles automatisch over. Er is geen tijdsbestek
8:22
Speaker 2: waarin het niet wordt beheerd. Niemand hoeft eraan te denken
8:24
Speaker 2: om de regels toe te passen. Ze zijn er al.
8:26
Speaker 2: Dit stelt een platformteam in staat om honderden abonnementen te
8:29
Speaker 2: ondersteunen zonder een knelpunt te worden. De automatisering doet het
8:32
Speaker 2: zware werk en het team focust op het verbeteren van
8:34
Speaker 2: het platform in plaats van voor elk verzoek door de
8:36
Speaker 2: portal te klikken. De splitsing tussen platform en applicatie, de
8:40
Speaker 2: meest voorkomende verwarring. Dat zijn dus de acht ontwerpgebieden, maar
8:43
Speaker 2: hier gaan de meeste mensen de fout in. Er zijn
8:45
Speaker 2: twee soorten landing zones en ze door elkaar halen is
8:47
Speaker 2: de meest voorkomende fout die ik zie. Platform landing zones
8:50
Speaker 2: en applicatie landing zones. Ze dienen totaal verschillende doelen. Platform
8:54
Speaker 2: landing zones zijn de gedeelde basis die eigendom is van
8:56
Speaker 2: het platform team. Je hebt een identiteitsabonnement met je domain services,
9:00
Speaker 2: een beheerabonnement met log analytics en automation accounts en een
9:03
Speaker 2: connectiviteitsabonnement met het HAP virtuele netwerk, Azure Firewall en Express
9:07
Speaker 2: Route of VPN Gateways. Dit zijn de gedeelde services waar
9:10
Speaker 2: elke workload van afhankelijk is. Applicatielandingzones zijn de plekken waar
9:13
Speaker 2: workloads daadwerkelijk draaien. Dit zijn de abonnementen die applicatieteams krijgen.
9:17
Speaker 2: Er zijn er veel van. Ze zijn vervangbaar en ze
9:19
Speaker 2: volgen elke keer hetzelfde patroon. Een team krijgt een abonnement,
9:22
Speaker 2: het wordt in de juiste beheergroep geplaatst, het neemt het
9:25
Speaker 2: beleid over, koppelt aan het HAP-netwerk en ze beginnen met implementeren.
9:28
Speaker 2: Het verschil in eigenaarschap is belangrijk. platformzones zijn er weinig,
9:31
Speaker 2: misschien 3 tot 5 abonnementen in totaal. Ze gaan lang
9:33
Speaker 2: mee en worden centraal beheerd door het platformteam. Applicatiezones zijn
9:37
Speaker 2: er veel. Je kunt er tientallen of honderden hebben. Ze
9:39
Speaker 2: zijn tijdelijk. Een workload wordt ingezet, draait een tijdje en
9:42
Speaker 2: wordt daarna buiten gebruik gesteld. Het abonnement wordt opgeschoond en
9:44
Speaker 2: het patroon herhaalt zich. Dit is het klassieke antipatroon. Iemand
9:48
Speaker 2: plaatst een gedeelde firewall in een applicatieabonnement of ze implementeren
9:51
Speaker 2: de Express Route Gateway in een workloadabonnement in plaats van
9:53
Speaker 2: in het connectiviteitsabonnement. Nu zijn gedeelde services verspreid over de
9:57
Speaker 2: hele omgeving. Niemand weet waar alles staat. Het platform kan
10:00
Speaker 2: de firewall niet beheren... omdat deze in iemands anders abonnement staat...
10:03
Speaker 2: en het applicatieteam wil het niet onderhouden. Het is een puinhoop.
10:06
Speaker 2: Hou gedeelde services in de platformlaag. Het connectiviteitsabonnement bevat het
10:10
Speaker 2: HAP virtuele netwerk... Azure Firewall en de Express Route Gateway.
10:13
Speaker 2: Applicatie abonnementen koppelen hier aan. Ze zijn nergens eigenaar van.
10:17
Speaker 2: Ze gebruiken het alleen. Wat dit voor jou betekent is
10:19
Speaker 2: een duidelijke scheiding van verantwoordelijkheden. Het platformteam beheert de kaders,
10:23
Speaker 2: de funrails, de gedeelde services en het beleid. Applicatieteams bewegen
10:27
Speaker 2: zich snel daar binnen. Ze krijgen een abonnement dat al compliant,
10:29
Speaker 2: al verbonden en al gemonitord is. Ze hoeven niet na
10:31
Speaker 2: te denken over de basis. Ze bouwen er simpelweg bovenop.
10:34
Speaker 2: Hoe de stukjes met elkaar verbinden. Het aha moment. Je
10:37
Speaker 2: kent nu de individuele bouwstenen, maar dit is wat echt telt.
10:40
Speaker 2: Ze werken niet in isolatie. Ze werken samen als één
10:43
Speaker 2: verbonden systeem, en dat is waar alles op zijn plek valt.
10:46
Speaker 2: Denk er eens zo over na. Identiteit bepaalt wie er
10:48
Speaker 2: door de voordeur naar binnen mag. Governance vertelt ze vervolgens
10:51
Speaker 2: in welke kamers ze mogen zijn zodra ze binnen zijn.
10:53
Speaker 2: Netwerken bepaalt hoe ze zich tussen die kamers bewegen. Beveiliging
10:56
Speaker 2: houdt bij elke hoek toezicht op bedreigingen. Beheer zorgt ervoor
10:59
Speaker 2: dat het hele gebouw soepel blijft draaien. En automatisering maakt
11:02
Speaker 2: elke stap herhaalbaar, zodat niets wordt vergeten. Elk onderdeel hangt
11:05
Speaker 2: van de andere af en samen creëren ze iets dat
11:07
Speaker 2: veel groter is dan elk afzonderlijk deel. Laat me u
11:09
Speaker 2: een concreet voorbeeld geven van hoe deze interactie precies werkt.
11:12
Speaker 2: Stel je voor dat een nieuw team een workload moet implementeren.
11:15
Speaker 2: Ze dienen een aanvraag in via de Subscription Vending Pipeline,
11:18
Speaker 2: die automatisch een gloednieuwe subscription aanmaakt. Deze wordt onder de
11:21
Speaker 2: juiste beheergroep geplaatst, waardoor de subscription direct alle beleidsregels van
11:26
Speaker 2: die groep overneemt. Versleutelingsverrijste, toegestane regio's, verplichte tags, logboekconfiguraties, alles
11:32
Speaker 2: wat nodig is. De pipeline configureert ook het spooknetwerk en
11:36
Speaker 2: koppelt dit aan de hub. Diagnostische instellingen sturen logboeken direct
11:39
Speaker 2: naar de centrale Log Analytics werkruimte, terwijl Defender4Cloud de beveiliging activeert.
11:44
Speaker 2: De volledige subscription is binnen enkele minuten compliant, verbonden en gemonitord,
11:48
Speaker 2: zonder menselijke tussenkomst. Dat is het werkelijke verschil tussen cloud
11:52
Speaker 2: chaos en cloud controle. In de rommelige omgeving die ik
11:55
Speaker 2: aan het begin beschreef, hangt elke stap af van iemand
11:57
Speaker 2: die eraan denkt. En mensen vergeten dingen. Of ze doen
12:00
Speaker 2: het elke keer anders, of ze doen het helemaal niet.
12:02
Speaker 2: Maar met een goede landingzone gaat dit automatisch. Het systeem
12:06
Speaker 2: dwingt zichzelf af en het team kan snel werken zonder
12:08
Speaker 2: dingen te breken. Hier struikelen de meeste organisaties. Ze behandelen
12:11
Speaker 2: de landingzone als een eenmalig project... implementeren, afvinken en doorgaan.
12:15
Speaker 2: Maar een landingzone is een levend platform. Azure brengt constant
12:18
Speaker 2: nieuwe functies uit. Uw compliance-eisen veranderen in de loop van
12:21
Speaker 2: de tijd. Uw bedrijf groeit. De landingzone moet meegroeien, anders
12:24
Speaker 2: gaat deze tegen u werken. Het operationele model is eigenlijk
12:27
Speaker 2: belangrijker dan de technische schablonen. Wie is eigenaar van de landingzone?
12:29
Speaker 2: Hoe evolueert deze? Hoe worden uitzonderingen afgehandeld? Als uw enige
12:33
Speaker 2: antwoord is het platform team beheert het, dan is dat
12:34
Speaker 2: niet genoeg. U heeft echte processen nodig. U heeft een
12:37
Speaker 2: goede backlog nodig. U moet de landingzone als een product behandelen,
12:40
Speaker 2: niet als een project. Hier is een praktijkvoorbeeld. Een platformteam
12:43
Speaker 2: ondersteunt 200 subscriptions zonder een knelpunt te worden. Het geheim
12:46
Speaker 2: is subscription vending gecombineerd met beleidsovererving. Het team hoeft niet
12:49
Speaker 2: door de portal te klikken om elke subscription aan te maken.
12:52
Speaker 2: De pipeline regelt dat automatisch. Ze configureren niet handmatig de
12:55
Speaker 2: logboeken voor elke workload. Beleid dwingt dit consistent af. Ze
12:58
Speaker 2: controleren niet elke implementatie op compliance. Het compliance dashboard toont
13:01
Speaker 2: hen alleen de uitzonderingen. Ze concentreren zich op de afwijkingen
13:04
Speaker 2: in plaats van op routine klusjes. En dat is het
13:06
Speaker 2: verschil tussen een platform dat schaalt en een platform dat
13:09
Speaker 2: de business verstikt. Concrete actiepunten. Begin klein, groei slim. Dus,
13:13
Speaker 2: wat doe je maandagochtend echt? Hier is het eerlijke antwoord.
13:16
Speaker 2: Probeer niet op de eerste dag de volledige enterprise schaalhierarchie
13:19
Speaker 2: op te bouwen. Dat is een valstrik die u wilt vermijden.
13:22
Speaker 2: Je zult maanden besteden aan het ontwerpen voor scenario's die
13:24
Speaker 2: misschien nooit voorkomen en je zult nooit echt iets bruikbaars opleveren.
13:27
Speaker 2: Begin in plaats daarvan met een Minimum Viable Landing Zone,
13:29
Speaker 2: ofwel een MVLZ. De kerncomponenten zijn simpel. Een hiërarchie van beheergroepen,
13:34
Speaker 2: een paar kernbeleidsregels zoals regio-beperkingen, versleuteling en verplichte tags, basisnetwerken
13:39
Speaker 2: met één hap virtueel netwerk en één spook, en gecentraliseerde
13:42
Speaker 2: logboekregistratie naar een Log Analytics werkruimte. Dat is voldoende. Je
13:45
Speaker 2: hebt niet vanaf dag 1 Azure Virtual One nodig en
13:48
Speaker 2: je hebt geen complex beleidsinitiatief vol met 200 regels nodig.
13:51
Speaker 2: Je hebt alleen genoeg van rails nodig om veilig te
13:53
Speaker 2: zijn en niet meer dan dat. Verplaats daarna je eerste
13:55
Speaker 2: echte workload naar die MVLZ. Geen test VM, maar een
13:58
Speaker 2: daadwerkelijke workload waar je team om geeft. Kijk hoe het
14:01
Speaker 2: beleid zich gedraagt. zie wat er misgaat, leer van de
14:03
Speaker 2: knelpunten en itereer vanaf daar. Voeg beleid toe wanneer je
14:06
Speaker 2: het nodig hebt, breed het netwerk uit wanneer dat nodig
14:08
Speaker 2: is en laat de landingzone op natuurlijke wijze meegroeien met
14:11
Speaker 2: je organisatie. Laat me je drie concrete tips geven die
14:13
Speaker 2: je direct kunt toepassen. Tip 1. Implementeer de Azure Landing
14:17
Speaker 2: Zones Accelerator vanuit de portal in een testtenant. Het kost niets,
14:21
Speaker 2: het duurt ongeveer een uur en het leert je meer
14:23
Speaker 2: over hoe beheergroepen, beleid en overerving echt werken dan welk
14:27
Speaker 2: diagram of documentatie dan ook. Je kunt de hiërarchie zien,
14:30
Speaker 2: het beleid in real-time zien, toegepast worden en experimenteren zonder
14:34
Speaker 2: iets belangrijks te verbreken. Tip 2. Schakel beleidsregels eerst in
14:38
Speaker 2: de Audit-modus in, niet in de weigeringsmodus. In de Audit-modus
14:41
Speaker 2: zie je precies wat niet voldoet in je omgeving zonder
14:43
Speaker 2: iemand te blokkeren. Hou het Compliance Dashboard in de gaten
14:46
Speaker 2: en ik beloof je dat je verrast zult zijn door
14:47
Speaker 2: hoeveel resources stilletjes de regels overtreden waarvan je dacht dat
14:50
Speaker 2: ze duidelijk waren. Zodra je je landschap begrijpt, kun je
14:52
Speaker 2: de belangrijke beleidsregels omzetten naar de weigeringsmodus. Maar begin met Audit.
14:56
Speaker 2: zodat je je eigen teams niet afsluit voordat je weet
14:58
Speaker 2: waar je mee te maken hebt. Tip 3. Plan je
15:01
Speaker 2: IP-adres bereiken en de hiërarchie van beheergroepen voordat je iets implementeert.
15:05
Speaker 2: Ik weet dat dat saai klinkt, maar ze later wijzigen
15:07
Speaker 2: is echt pijnlijk. Overlappende IP-bereiken betekenen het afbreken van netwerkpering
15:11
Speaker 2: en het herstructureren van beheergroepen betekent abonnementen verplaatsen en beleidstoewijzingen
15:15
Speaker 2: opnieuw evalueren. Zorg dat deze twee zaken vooraf goed staan,
15:18
Speaker 2: dan bespaar je jezelf later weken aan extra werk. De
15:20
Speaker 2: veel voorkomende valkuilen zijn vrij duidelijk. Overmatig ontwerpen leidt tot analyseverlamming,
15:25
Speaker 2: waardoor je nooit iets implementeert. Onder ontwikkeling laat je achter
15:27
Speaker 2: zonder enige vangrails, wat simpelweg Cloud Chaos onder een andere
15:30
Speaker 2: naam is. En de landing zonder behandelen als een eenmalig
15:33
Speaker 2: project in plaats van een levend platform garandeert dat je
15:35
Speaker 2: achterop raakt. Vermijd die drievallen en je loopt al voor
15:37
Speaker 2: op de meeste organisaties. Onthoud, het doel is geen perfecte landingzone.
15:41
Speaker 2: Het doel is een beheerde basis waarmee teams snel kunnen
15:43
Speaker 2: werken zonder chaos te creëren. Begin klein, itereer en laat
15:46
Speaker 2: beleid het zware werk voor je doen. Dat zijn dus
15:49
Speaker 2: Azure Landingzones in begrijpelijke taal. Het is geen ingewikkeld bedrijfsconcept.
15:53
Speaker 2: Zie het als een beheerd abonnement met ingebouwde vangrails. De
15:56
Speaker 2: acht ontwerpgebieden zijn simpelweg de vragen die je moet beantwoorden
15:59
Speaker 2: voordat je begint met implementeren. Identiteit, netwerken, beveiliging, beheer, governance, automatisering.
16:05
Speaker 2: Beantwoord ze één keer, bouw ze in de basis en
16:07
Speaker 2: elke workload daarna profiteert ervan. Dit is het beste wat
16:10
Speaker 2: je nu kunt doen. Implementeer de accelerator in een testtenant
16:12
Speaker 2: en zie hoe policies worden overgenomen. Dat uur leert je
16:15
Speaker 2: meer dan welk diagram dan ook ooit zou kunnen. Abonneer
16:17
Speaker 2: je voor meer uitleg in begrijpelijke taal zoals deze en
16:19
Speaker 2: laat een reactie achter als het kwartje is gevallen. Ik
16:21
Speaker 2: lees ze allemaal.