Latest / M365.FM – Microsoft 365, Copilot & AI podcast in het Nederlands / Microsoft Cloud Adoption Framework uitgelegd: strategie, planning en Azure-landingszones (AI-nasynchronisatie)

Transcript

Microsoft Cloud Adoption Framework uitgelegd: strategie, planning en Azure-landingszones (AI-nasynchronisatie) · M365.FM – Microsoft 365, Copilot & AI podcast in het Nederlands

0:00
Speaker 2: Klaar voor 10 dagen vol Microsoft 365, Copilot, AI, Azure
0:05
Speaker 2: en de mensen die de toekomst van werk vormgeven. In
0:08
Speaker 2: januari is M365 komt terug en we pakken het groter aan.
0:12
Speaker 2: Doe mee aan live sessies, praktijkdemonstraties en praktische kennis van
0:16
Speaker 2: MVP's en experts uit de hele wereld. Geen generieke sliedes,
0:20
Speaker 2: geen eindeloze modewoorden. We pakken de echte uitdagingen aan Copilot Studio,
0:25
Speaker 2: AI Agents, Fabric, Beveiliging, Governance en Automatisering. Of je nu
0:30
Speaker 2: een IT-professional, ontwikkelaar of bedrijfsleider bent, er zijn sessies speciaal
0:34
Speaker 2: voor jou. Gedurende tien volle dagen kun je verschillende technologieën
0:38
Speaker 2: verkennen en in contact komen met een wereldwijde community. Kijk
0:41
Speaker 2: live mee en neem praktische inzichten mee terug naar je organisatie.
0:44
Speaker 2: Januari 2027, tien dagen, één Microsoft Community. Registratie is nu geopend.
1:00
Speaker 2: Meld je nu aan op m365con.net en we zien je
1:03
Speaker 2: live in januari. De meeste teams beginnen hun Azure-traject door
1:07
Speaker 2: een abonnement te openen, een virtuele machine te creëren en
1:10
Speaker 2: gaandeweg services te kiezen. Een beter startpunt is misschien minder spannend,
1:14
Speaker 2: maar het bespaart je later een hoop ellende. Bepaal waarom
1:16
Speaker 2: je verhuist, wat je verhuist en welke regels mensen nodig
1:19
Speaker 2: hebben voordat ze beginnen. Denk bijvoorbeeld aan het openen van
1:21
Speaker 2: een kantoor. Je zou willekeurige kamers in verschillende gebouwen kunnen huren,
1:25
Speaker 2: sleutels uitdelen zonder lijst en hopen dat elke afdeling zelf
1:28
Speaker 2: zijn internet, archivering en beveiliging regelt. Mensen zouden nog wel
1:31
Speaker 2: even kunnen werken, maar het zou niet als één kantoor aanvoelen.
1:34
Speaker 2: Of je zou één veilig gebouw kunnen inrichten waar mensen
1:36
Speaker 2: weten waar ze heen moeten, wie er naar binnen mag,
1:38
Speaker 2: wat elke ruimte kost en wie problemen oplost. Dat is
1:40
Speaker 2: wat het Microsoft Cloud Adoption Framework, vaak CAF genoemd, je
1:43
Speaker 2: helpt te doen. Het is een handleiding van Microsoft voor
1:45
Speaker 2: het migreren van werk naar Azure en het vervolgens beheren
1:47
Speaker 2: van dat werk in de loop van de tijd. We
1:48
Speaker 2: gaan kijken naar de zes bouwstenen wat een Azure landingzone
1:51
Speaker 2: nu echt inhoudt en waarom governance niet tot het einde
1:53
Speaker 2: kan wachten. Veel teams slaan één onderdeel over, waardoor ze
1:57
Speaker 2: het vaak later moeten aanpakken. Waarom CAF het kantoorgebouwprobleem aanpakt?
2:02
Speaker 2: Voordat cloud services gemeengoed werden, bouwden veel bedrijven hun IT-stukje
2:05
Speaker 2: bij beetje op. E-mail draaide op de ene server, bestandsopslag
2:08
Speaker 2: op een andere, een applicatie had zijn eigen server, zijn
2:11
Speaker 2: eigen backupplan en soms zelfs een eigen persoon die wist
2:13
Speaker 2: hoe het werkte. Beveiligingsbeslissingen konden per systeem verschillen. Het ene
2:17
Speaker 2: team beheerde de netwerken, het andere de servers. De financiële
2:20
Speaker 2: afdeling ontving facturen, maar kon vaak niet zien welke afdeling
2:22
Speaker 2: de uitgaven had veroorzaakt. De infrastructuur groeide in de loop
2:24
Speaker 2: der jaren, meestal omdat elk nieuw probleem snel moest worden opgelost.
2:27
Speaker 2: Azure biedt meer opties, sneller. Dat betekent niet dat Azure
2:30
Speaker 2: automatisch kosten, beveiliging of trage levering oplost. Als u cloud
2:33
Speaker 2: resources creëert zonder gezamenlijke besluitvorming, kunt u dezelfde oude chaos
2:37
Speaker 2: opnieuw creëren, alleen met meer knoppen en een maandelijkse factuur
2:39
Speaker 2: die elke dag verandert. CAF is Microsofts routekaart om dat
2:41
Speaker 2: te voorkomen. Het is geen product dat u installeert. Het
2:44
Speaker 2: is geen Azure certificering. En het is geen installatie met
2:47
Speaker 2: één klik die een leeg Azure abonnement in een kant
2:49
Speaker 2: en klare cloudomgeving verandert. In plaats daarvan biedt het u
2:51
Speaker 2: een manier om over het werk na te denken. U
2:53
Speaker 2: bepaalt waarom de organisatie Azure nodig heeft. U plant wat
2:55
Speaker 2: er moet worden verplaatst. U bereidt een omgeving voor waar
2:57
Speaker 2: workloads kunnen worden ondergebracht. Vervolgens verplaatst, beveiligd, beheert en voert
3:00
Speaker 2: u ze uit. Terug naar ons kantoorgebouw. De eigenaar van
3:02
Speaker 2: het bedrijf bepaalt wat het gebouw moet ondersteunen. De receptie
3:05
Speaker 2: controleert wie er binnen mag. Elke afdeling werkt in een
3:07
Speaker 2: eigen ruimte. De huisregels van het gebouw regelen de toegang,
3:10
Speaker 2: de veiligheid en de uitgaven. Ondertussen zorgt het facilitaire team
3:13
Speaker 2: ervoor dat de lichten blijven branden, reageert het bij storingen
3:15
Speaker 2: en controleert het of het gebouw veilig blijft. Azure werkt
3:18
Speaker 2: op een vergelijkbare manier, hoewel de onderdelen andere namen hebben.
3:20
Speaker 2: Stel je een bedrijf voor dat meer ruimte wil voor
3:22
Speaker 2: nieuwe producten en medewerkers die op afstand werken. Het wil
3:24
Speaker 2: dat teams sneller ontwikkelen, maar begint ermee dat elk team
3:26
Speaker 2: Azure Resources naar eigen inzicht mag creëren. Het ene team
3:29
Speaker 2: gebruikt openbare toegang omdat dat snel is. Een ander team
3:32
Speaker 2: creëert dure services zonder budgetverantwoordelijken. Een derde team kan zijn
3:35
Speaker 2: applicatie niet verbinden omdat er geen netwerkplanning is. Al snel
3:38
Speaker 2: weet niemand meer wie wat bezit. Facturen komen binnen zonder
3:40
Speaker 2: duidelijke context. De toegang wordt te breed. Het oplossen van
3:43
Speaker 2: de problemen betekent het aanpassen van systemen waar mensen al
3:45
Speaker 2: van afhankelijk zijn. Dat is de prijs die je betaalt
3:47
Speaker 2: voor het behandelen van cloud adoptie als een winkelbezoek in
3:49
Speaker 2: plaats van een verhuizing. CAF helpt teams om die beslissingen
3:52
Speaker 2: te nemen voordat de verwarring de norm wordt. De eerste
3:54
Speaker 2: vraag komt nog voor blauwdrukken, abonnementen of virtuele machines. Waarom
3:59
Speaker 2: moet dit kantoor überhaupt bestaan? Strategie en planning. Bepaal waarom
4:03
Speaker 2: je gaat bouwen. Strategie begint met een simpele vraag, welk
4:06
Speaker 2: probleem moet Azure voor jouw organisatie oplossen? Niet, welke Azure
4:11
Speaker 2: service moeten we kopen? Een bedrijf moet misschien een datacenter
4:13
Speaker 2: verlaten omdat oude hardware aan vervanging toe is. Een ander
4:16
Speaker 2: bedrijf wil misschien sneller nieuwe functies uitbrengen. Een bedrijf met
4:19
Speaker 2: teams in verschillende landen wil zijn applicaties dichter bij de
4:21
Speaker 2: gebruikers hebben. Weer een ander bedrijf hecht er misschien de
4:23
Speaker 2: meeste waarde aan om na een storing te kunnen herstellen
4:25
Speaker 2: zonder te hoeven wachten tot beschadigde hardware is gerepareerd. Dat
4:27
Speaker 2: zijn verschillende redenen. Ze leiden tot verschillende beslissingen. Denk aan
4:31
Speaker 2: een verhuizing. Verhuis je omdat het huidige kantoor te klein is?
4:34
Speaker 2: Heb je een tweede locatie nodig? Komen medewerkers op afstand
4:36
Speaker 2: vaker naar kantoor? Of is het oude gebouw gewoon te
4:38
Speaker 2: veel onderhoud nodig? Je zou niet voor elke situatie hetzelfde
4:41
Speaker 2: gebouw kiezen. Azure werkt op dezelfde manier. Je strategie moet
4:44
Speaker 2: de gewenste uitkomst benoemen. Misschien wil je minder afhankelijk zijn
4:47
Speaker 2: van je eigen datacenter. Misschien moeten productteams vaker updates uitbrengen.
4:50
Speaker 2: Misschien hebben medewerkers op afstand veiligere toegang tot bedrijfssystemen nodig.
4:53
Speaker 2: Of misschien heeft de financiële afdeling duidelijke bestedingslimieten nodig voordat
4:56
Speaker 2: de cloudposten beginnen te stijgen. Gebruik waar mogelijk eenvoudige meetmethoden.
4:59
Speaker 2: Verplaats bijvoorbeeld deze 10 servers voordat de ondersteuning afloopt. Of
5:02
Speaker 2: verkort de tijd die nodig is om een nieuwe versie
5:04
Speaker 2: uit te brengen van weken naar dagen. Of geef elke
5:06
Speaker 2: afdeling een maandelijks cloudbudget met een verantwoordelijke. Dat geeft mensen
5:09
Speaker 2: iets concreets om naartoe te werken. Zonder dit blijven cloudprojecten stagneren.
5:13
Speaker 2: Het technische team bouwt resources. De business wacht op resultaten.
5:16
Speaker 2: De financiële afdeling ziet een rekening. De beveiligingsafdeling ontdekt risico's
5:19
Speaker 2: pas laat in het proces. Dan stelt iedereen dezelfde vraag.
5:21
Speaker 2: Waarom doen we dit? Zodra de reden duidelijk is, zet
5:24
Speaker 2: de planning die reden om in een takenlijst. Je moet
5:26
Speaker 2: weten welke applicaties je hebt, welke data ze gebruiken, wie
5:29
Speaker 2: de eigenaar is en wie begrijpt hoe ze werken. Je
5:31
Speaker 2: moet ook de timing, risico's, vaardigheden en afhankelijkheden kennen. Een
5:35
Speaker 2: afhankelijkheid is simpelweg iets wat een applicatie nodig heeft om
5:38
Speaker 2: te kunnen werken. Een oude salarisadministratie-applicatie heeft bijvoorbeeld mogelijk een database,
5:42
Speaker 2: een gedeelde bestandslocatie en een verbinding met een ander bedrijfssysteem nodig.
5:45
Speaker 2: Als je alleen de applicatie verplaatst en een van die
5:46
Speaker 2: koppelingen vergeet, lijkt de verplaatsing misschien voltooid, maar werkt de
5:49
Speaker 2: salarisadministratie niet meer. Dit is waar veel teams voor verrassingen
5:52
Speaker 2: komen te staan. Een applicatie die klein lijkt, kan verbonden
5:54
Speaker 2: zijn met vijf andere systemen. Een server kan een taak
5:56
Speaker 2: uitvoeren die niet gedocumenteerd is. De enige persoon die het begrijpt,
5:59
Speaker 2: is misschien al jaren geleden vertrokken. Planning helpt om deze
6:01
Speaker 2: problemen aan het licht te brengen, zodat je er nog
6:02
Speaker 2: tijd voor hebt. Vervolgens kies je voor elke applicatie een aanpak.
6:05
Speaker 2: Sommige applicaties kunnen direct worden verplaatst. Dit wordt vaak Rehosting
6:08
Speaker 2: of Lift & Shift genoemd. Je neemt de bestaande server
6:10
Speaker 2: en draait deze met minimale aanpassingen in Azure. Andere applicaties
6:14
Speaker 2: vereisen aanpassingen om beter met Azure te werken. Je kunt
6:16
Speaker 2: bijvoorbeeld een database verplaatsen naar een beheerde Azure Database Service,
6:19
Speaker 2: terwijl de rest van de applicatie hetzelfde blijft. Sommige applicaties
6:23
Speaker 2: vereisen een complete heropbouw. De code is mogelijk verouderd, moeilijk
6:26
Speaker 2: te onderhouden of te sterk verbonden met de oude omgeving.
6:28
Speaker 2: In andere gevallen is het verstandiger om de applicatie te
6:30
Speaker 2: vervangen door een online service of deze voorlopig buiten Azure
6:33
Speaker 2: te houden. Iets op zijn huidige locatie laten staan kan
6:35
Speaker 2: de juiste keuze zijn. Cloud-adoptie betekent niet dat je alles
6:38
Speaker 2: moet verplaatsen. Maar hier maken teams vaak een verkeerde eerste keuze.
6:41
Speaker 2: Ze beginnen met de oudste, minst begrepen applicatie, omdat die
6:44
Speaker 2: urgent aanvoelt. Die applicatie kan echter kwetsbaar zijn, slecht gedocumenteerd
6:47
Speaker 2: en verbonden met meer systemen dan iemand beseft. Het kan
6:49
Speaker 2: de eerste stap veranderen in een langdurige reddingsoperatie. Een betere
6:53
Speaker 2: eerste workload is belangrijk genoeg om je iets te leren,
6:55
Speaker 2: maar tegelijkertijd eenvoudig genoeg zodat mensen de eigenaar, de data
6:58
Speaker 2: en het succesprincipe begrijpen. Die eerste stap geeft het team
7:01
Speaker 2: de kans om te leren zonder het hele bedrijf in
7:02
Speaker 2: gevaar te brengen. Stel je een bedrijf voor waarvan de
7:04
Speaker 2: ondersteuning voor de server hardware over drie maanden afloopt. Het
7:07
Speaker 2: eerste doel is niet om elke oude applicatie opnieuw te ontwerpen.
7:09
Speaker 2: Daar is geen tijd voor. Het verplaatsen van een paar
7:11
Speaker 2: servers naar Azure met beperkte aanpassingen kan een verstandige stap zijn,
7:14
Speaker 2: omdat het het directe hardware risico wegneemt. Vervolgens kan het
7:17
Speaker 2: bedrijf een lange termijn plan opstellen om die applicaties later
7:19
Speaker 2: te verbeteren of te vervangen. Dat is geen genoegen nemen
7:21
Speaker 2: met minder. Dat is de juiste taak, kiezen voor de
7:23
Speaker 2: beschikbare tijd. Planning vereist ook de juiste mensen. Bedrijfsleiders leggen
7:27
Speaker 2: uit wat belangrijk is. Applicatie-eigenaren leggen uit hoe de software werkt.
7:30
Speaker 2: Beveiligingsteams definiëren veilige toegang. Netwerkteams plannen verbindingen. De financiële afdeling
7:35
Speaker 2: houdt de uitgaven bij. Het cloudteam bouwt en ondersteunt de
7:37
Speaker 2: Azure kant. Geen enkel team kan alle vragen alleen beantwoorden.
7:40
Speaker 2: Strategie vertelt je dus waarom het kantoor moet veranderen en
7:43
Speaker 2: planning vertelt je wie er verhuist, wat ze nodig hebben
7:45
Speaker 2: en wanneer dat kan gebeuren. De volgende CAF fase bereidt
7:48
Speaker 2: het gebouw voor op die behoefte voordat de eerste afdeling arriveert. Klaar?
7:51
Speaker 2: Bouw de landingzone voordat de huurders arriveren. Met het plan
7:54
Speaker 2: op zak kun je Azure zelf voorbereiden. CAF noemt deze
7:58
Speaker 2: fase gereed. Het centrale idee is de Azure landingzone. Die
8:01
Speaker 2: naam klinkt misschien technisch, maar de betekenis is eenvoudig. Een
8:04
Speaker 2: landingzone is een voorbereid deel van Azure waar applicaties en
8:07
Speaker 2: data veilig kunnen worden opgeslagen. Zie het als het voorbereiden
8:10
Speaker 2: van het kantoorgebouw voordat de eerste afdeling erin trekt. Je
8:12
Speaker 2: hebt de basisstructuur van het gebouw nodig. Je hebt elektriciteit, netwerkkabels, deuren, sloten,
8:16
Speaker 2: nooduitgangen en een plek nodig om documenten op te slaan.
8:18
Speaker 2: Je zou mensen toch ook niet een lege betonnen ruimte
8:20
Speaker 2: binnenlaten en ze vragen om zelf de bekabeling aan te leggen.
8:22
Speaker 2: Een landingzone biedt je workloads die voorbereiden basis. Dat betekent
8:25
Speaker 2: niet dat elke Azure-omgeving er hetzelfde uitziet. Een klein bedrijf
8:28
Speaker 2: heeft misschien een eenvoudige configuratie nodig met een paar duidelijke regels.
8:31
Speaker 2: Een groot bedrijf heeft mogelijk veel aparte ruimtes nodig voor teams,
8:33
Speaker 2: regio's en gevoelige systemen. Het punt is om de benodigde
8:36
Speaker 2: onderdelen te bouwen voordat de applicaties arriveren. Begin bij de receptie.
8:39
Speaker 2: In Microsoft Cloud Services werkt Microsoft EntraID als die receptie.
8:43
Speaker 2: Het beheert digitale identiteiten, wat betekent dat het weet wie
8:46
Speaker 2: probeert in te loggen en kan helpen bepalen tot welke
8:48
Speaker 2: applicaties ze toegang hebben. Iemand heeft mogelijk toegang nodig tot
8:50
Speaker 2: de ene applicatie, maar niet tot de andere. Een service
8:53
Speaker 2: heeft mogelijk toestemming nodig om gegevens uit een database te lezen,
8:55
Speaker 2: maar mag deze nooit verwijderen. EntraID helpt bij het beheren
8:58
Speaker 2: van deze beslissingen. De algemene regel is simpel, geef mensen
9:00
Speaker 2: alleen de toegang die ze nodig hebben om hun werk
9:02
Speaker 2: te doen. Dat vermindert fouten en maakt ongewenste toegang moeilijker.
9:06
Speaker 2: Vervolgens komt de structuur van het gebouw. Azure heeft een
9:08
Speaker 2: aantal lagen voor het organiseren van werk. Beheergroepen bevinden zich bovenaan.
9:12
Speaker 2: Je kunt ze zien als de bredere structuur van het gebouw,
9:14
Speaker 2: waar gedeelde regels van toepassing kunnen zijn op meerdere gebieden.
9:16
Speaker 2: Abonnementen bevinden zich daaronder. Een abonnement is vaak een aparte
9:19
Speaker 2: ruimte voor facturering, toegang en workloads. Een abonnement kan een
9:22
Speaker 2: productieapplicatie ondersteunen, een ander testomgeving. Een gedeeld abonnement kan services
9:26
Speaker 2: uitvoeren die door meerdere teams worden gebruikt. Binnen abonnementen helpen
9:29
Speaker 2: resourcegroepen je om gerelateerde Azure items te verzamelen. De websurfers,
9:33
Speaker 2: database en opslag van een applicatie kunnen zich in één
9:35
Speaker 2: resourcegroep bevinden omdat ze bij dezelfde workload horen. Naamgevingsregels en
9:38
Speaker 2: tags helpen mensen om dingen later terug te vinden. Een
9:41
Speaker 2: naam vertelt je wat iets is. Een tag is meer
9:43
Speaker 2: een label dat je eraan koppelt, zoals de afdelingseigenaar, de
9:46
Speaker 2: omgeving of een kostenpost. Als de financiële afdeling moet vragen
9:49
Speaker 2: welk team de kosten heeft veroorzaakt, maken labels die vraag
9:51
Speaker 2: veel gemakkelijker te beantwoorden. Maar maak van namen en labels
9:54
Speaker 2: geen gigantische puzzel. Mensen hebben regels nodig die ze kunnen
9:56
Speaker 2: volgen zonder een document van 20 pagina's te hoeven openen.
9:59
Speaker 2: Duidelijk en consistent. is beter dan slim. Het gebouw heeft
10:01
Speaker 2: ook wegen, deuren en muren nodig. In Azure is dit netwerken.
10:05
Speaker 2: Het bepaalt hoe systemen met elkaar, met internet en soms
10:07
Speaker 2: met systemen die nog steeds in je eigen gebouw of
10:10
Speaker 2: datacenter draaien. verbinding maken. Sommige applicaties hebben een privépad naar
10:14
Speaker 2: een bedrijfsdatabase nodig. Anderen moeten verkeer van klanten via internet accepteren.
10:18
Speaker 2: Sommige systemen zouden helemaal niet met elkaar moeten communiceren. Die
10:21
Speaker 2: scheiding is belangrijk. Je zou toch ook niet alle kantoordeuren
10:23
Speaker 2: open laten staan alleen omdat mensen in hetzelfde gebouw werken.
10:26
Speaker 2: Op dezelfde manier zorgt een goed netwerkontwerper voor dat een
10:28
Speaker 2: workload de benodigde verbindingen toestaat en de onnodige verbindingen blokkeert.
10:31
Speaker 2: Daarnaast zijn er services die door meerdere afdelingen worden gedeeld.
10:33
Speaker 2: Identiteitsbeheer is er één van. Netwerkverbindingen zijn een andere. Monitoring,
10:37
Speaker 2: backup en beveiligingstools kunnen ook in dit gedeelde platformgebied worden ondergebracht.
10:40
Speaker 2: In plaats van dat elk applicatieteam zijn eigen versie van
10:42
Speaker 2: deze basisfunctionaliteiten bouwt, kan de organisatie deze eenmalig aanbieden en
10:45
Speaker 2: workloads er gebruik van laten maken. Dit wordt vaak een
10:47
Speaker 2: platform landingzone genoemd. Een applicatie landingzone is anders. Dat is
10:51
Speaker 2: de individuele kantoorruimte waar één applicatie of team werkt. Deze
10:54
Speaker 2: volgt de algemene gebouwregels, maar biedt ruimte voor de specifieke
10:57
Speaker 2: behoeften van die workload. Een klantwebsite heeft bijvoorbeeld mogelijk andere
11:00
Speaker 2: services nodig dan een intern financieel systeem. Ze kunnen aparte
11:03
Speaker 2: applicatie landingzones hebben, terwijl ze toch dezelfde aanmeldregels, netwerkbenadering, monitoring
11:07
Speaker 2: en beveiligingsmaatregelen gebruiken. Dit geeft teams de ruimte om te
11:10
Speaker 2: werken zonder dat Azure een vrijplaats wordt. Azure Policy helpt hierbij.
11:13
Speaker 2: Beleid werkt als gebouwregels die onveilige keuzes voorkomen. U kunt
11:16
Speaker 2: bijvoorbeeld bepaalde labels vereisen, zodat kosten een eigenaar hebben. U
11:19
Speaker 2: kunt opslag blokkeren die openbaar toegankelijk is, terwijl de gegevens
11:22
Speaker 2: privé moeten blijven. Je kunt implementaties beperken tot goedgekeurde regio's.
11:26
Speaker 2: Het doel is niet om mensen te belemmeren in hun werk.
11:28
Speaker 2: Het doel is om veelgemaakte fouten te voorkomen voordat ze
11:30
Speaker 2: kostbaar of riskant worden. Maar hier lopen veel beginners vast.
11:33
Speaker 2: Ze zien een enorm Microsoft-diagraam vol vakjes en besluiten dat
11:36
Speaker 2: ze vanaf dag 1 elk vakje nodig hebben. Dat hoeft niet.
11:40
Speaker 2: Een klein team hoeft geen bedrijfstoren te bouwen alleen omdat
11:42
Speaker 2: de blauwdruk bestaat. Bouw de basis die je organisatie nu
11:45
Speaker 2: nodig heeft en breed deze uit wanneer een echte workload
11:47
Speaker 2: daar een reden voor geeft. En die eerste workload vertelt
11:50
Speaker 2: je iets wat een diagram nooit kan. Een landingzone kan
11:52
Speaker 2: er op papier compleet uitzien met beleid, netwerken, toegangsregels en monitoring.
11:56
Speaker 2: Allemaal netjes getekend. Dan komt er een applicatie die een
11:58
Speaker 2: verbinding nodig heeft die niemand had gepland, een machtiging die
12:00
Speaker 2: niemand had verwacht of een backupinstelling die niet past. Dat
12:03
Speaker 2: is geen bewijs dat de landingzone mislukt is. Het is
12:05
Speaker 2: hoe het gebouw beter wordt. Adopteer, verplaats workloads, leer ervan
12:09
Speaker 2: en verbeter. Nu kunnen mensen de ruimte gaan gebruiken. CAF
12:13
Speaker 2: noemt dit adopteren en het omvat twee gerelateerde taken. Het
12:16
Speaker 2: verplaatsen van bestaande workloads naar Azure en het aanpassen van
12:19
Speaker 2: workloads zodat ze daar beter werken. Een workload is simpelweg
12:21
Speaker 2: een stuk werk dat op technologie draait. Het kan een
12:24
Speaker 2: website zijn, een bedrijfsapplicatie, een database of een groep services
12:27
Speaker 2: die samenwerken. Stel je voor dat een afdeling op de
12:29
Speaker 2: verhuisdag aankomt. De ruimte is klaar, maar de verhuizing vereist
12:32
Speaker 2: nog de nodige aandacht. Medewerkers testen hun toegangskaarten. Ze controleren
12:35
Speaker 2: of hun telefoons werken. Ze zorgen ervoor dat ze toegang
12:37
Speaker 2: hebben tot de bestanden die ze nodig hebben. Ze zoeken
12:39
Speaker 2: de nooduitgangen op voordat er zich een echte noodsituatie voordoet.
12:41
Speaker 2: Het migreren van een applicatie naar Azure volgt hetzelfde basisprincipe.
12:44
Speaker 2: Je controleert of de applicatie werkt of deze toegang heeft
12:46
Speaker 2: tot de systemen waarvan deze afhankelijk is en of de
12:48
Speaker 2: juiste mensen de applicatie kunnen ondersteunen. Begin met een workload
12:51
Speaker 2: die een goede test vormt. Deze moet relevant zijn voor
12:53
Speaker 2: het bedrijf, maar mag geen mysterie zijn dat bij elkaar
12:54
Speaker 2: wordt gehouden door oude code en één ontbrekende handleiding. Migreer
12:57
Speaker 2: de applicatie, test deze, leer waar de configuratie verbetering behoeft
12:59
Speaker 2: en pas die lessen toe op de volgende workload. Zo
13:01
Speaker 2: voorkomt CAF dat dezelfde fout vijftig keer wordt herhaald. Er
13:04
Speaker 2: zijn verschillende manieren waarop een applicatie kan migreren. De snelste
13:07
Speaker 2: manier is rehosten. Dit wordt ook wel lift en shift genoemd.
13:10
Speaker 2: De applicatie blijft grotendeels hetzelfde, maar draait op een virtuele
13:13
Speaker 2: machine in Azure in plaats van op een server die
13:14
Speaker 2: u zelf beheert. Dit kan zinvol zijn wanneer u snel
13:16
Speaker 2: oude hardware wilt vervangen. De volgende stap is herplatformen. De
13:19
Speaker 2: applicatie doet nog steeds hetzelfde werk, maar u verplaatst een
13:22
Speaker 2: deel ervan naar een beheerde Azure Service. In plaats van
13:24
Speaker 2: uw eigen database server te draaien, kunt u bijvoorbeeld een
13:26
Speaker 2: Azure Database Service gebruiken die door Microsoft wordt beheerd en onderhouden.
13:29
Speaker 2: Dan is er nog refactoring of heropbouw. Refactoring betekent dat
13:32
Speaker 2: delen van de applicatie worden aangepast zodat deze beter gebruik
13:34
Speaker 2: kan maken van cloud services. Heropbouw betekent dat er een
13:36
Speaker 2: nieuwe versie wordt gemaakt omdat de oude versie niet langer
13:38
Speaker 2: voldoet aan de bedrijfsbehoeften. te duur is om te onderhouden
13:40
Speaker 2: of niet veilig kan worden gemigreerd zoals deze is. Niet
13:42
Speaker 2: elke workload hoeft naar Azure te worden gemigreerd. Een applicatie
13:45
Speaker 2: kan om een goede reden op de huidige locatie blijven.
13:47
Speaker 2: Of de organisatie kan de applicatie vervangen door een online
13:50
Speaker 2: software service in plaats van deze zelf te draaien. Het
13:53
Speaker 2: juiste antwoord hangt af van wat de workload doet, hoeveel
13:55
Speaker 2: aanpassingen er nodig zijn en welk risico het bedrijf kan accepteren.
13:58
Speaker 2: Test voordat iets een productieworkload wordt, meer dan alleen het aanmeldscherm.
14:01
Speaker 2: Doet de applicatie wat hij moet doen? Kan het communiceren
14:04
Speaker 2: met de database en andere verbonden systemen? Presteert het goed
14:07
Speaker 2: wanneer echte gebruikers het gebruiken? Kun je de gegevens herstellen
14:09
Speaker 2: als er iets misgaat? Hebben de juiste mensen toegang terwijl
14:12
Speaker 2: de rest buitengesloten blijft? En begrijp je wat de kosten
14:14
Speaker 2: zijn wanneer het normaal functioneert? Een succesvolle implementatie is niet
14:17
Speaker 2: zomaar een applicatie die eenmalig opent. Het is een applicatie
14:20
Speaker 2: die kan draaien, herstellen en ondersteund kan worden. Ook hiervoor
14:23
Speaker 2: zijn twee teams nodig die betrokken blijven. Het applicatieteam weet
14:26
Speaker 2: wat de applicatie nodig heeft en hoe gebruikers erop vertrouwen.
14:28
Speaker 2: Het platformteam weet hoe Azure is geconfigureerd en welke gedeelde
14:31
Speaker 2: regels van toepassing zijn. Geen van beide teams kan alle
14:33
Speaker 2: problemen alleen oplossen, maar veel organisaties trappen in een bekende valkuil.
14:37
Speaker 2: Het platformteam rondt de landingzone af, geeft het applicatieteam toegang
14:40
Speaker 2: en gaat verder met de volgende taak. Vervolgens stuit het
14:43
Speaker 2: applicatieteam op een probleem met beleid, netwerkregels of machtigingen en
14:46
Speaker 2: gaat op zoek naar manieren om het platform te omzeilen.
14:48
Speaker 2: Dat leidt tot frustratie aan beide kanten. Een betere aanpak
14:51
Speaker 2: is om de eerste stappen als gezamenlijk werk te beschouwen.
14:54
Speaker 2: Wanneer een applicatie een redelijke wijziging nodig heeft, beslissen de
14:56
Speaker 2: teams of die wijziging thuishoort in de applicatieconfiguratie of in
14:59
Speaker 2: de gedeelde Azure basis. Ze documenteren het antwoord en maken
15:01
Speaker 2: de volgende stap vervolgens eenvoudiger. Elke workload leert je iets.
15:04
Speaker 2: Misschien heeft het backup proces een duidelijkere verantwoordelijkheid nodig. Misschien
15:07
Speaker 2: heeft een applicatie een netwerkpad nodig dat andere workloads ook
15:10
Speaker 2: nodig hebben. Misschien blokkeert een beleid een veilige implementatie en
15:12
Speaker 2: moet het worden aangepast. Je wacht niet op een perfect
15:15
Speaker 2: ontwerp om deze dingen te leren. Je leert door voorzichtig
15:17
Speaker 2: te werk te gaan, de configuratie te verbeteren en die
15:19
Speaker 2: verbeteringen opnieuw te gebruiken. Zodra afdelingen echter in het gebouw werken,
15:23
Speaker 2: moet iemand toezicht houden op de regels, de veiligheid en
15:25
Speaker 2: het dagelijkse onderhoud. Beheren, beveiligen en beheren. Zorg ervoor dat
15:29
Speaker 2: het kantoor veilig en operationeel blijft. Beheren, beveiligen en beheren
15:32
Speaker 2: zijn geen taken die je uitstelt tot het migratieproject is afgerond.
15:34
Speaker 2: Ze lopen als een rode draad door het hele cloud traject,
15:36
Speaker 2: omdat beslissingen over toegang, uitgaven, veiligheid en ondersteuning vanaf het
15:39
Speaker 2: begin van invloed zijn op elke workload. Governance stelt de
15:42
Speaker 2: regels vast voor hoe Azure wordt gebruikt. Dat kan betrekking
15:44
Speaker 2: hebben op welke Azure Services teams mogen gebruiken, in welke
15:46
Speaker 2: regio's ze kunnen implementeren, hoe resources worden benoemd, welke labels
15:49
Speaker 2: ze nodig hebben, wie verantwoordelijk is voor elke workload en
15:51
Speaker 2: hoe uitgaven worden bijgehouden. Zie governance als de regels waaraan
15:54
Speaker 2: iedereen zich houdt tijdens het gebruik van het kantoor. Een
15:56
Speaker 2: afdeling moet mogelijk vastleggen wie de eigenaar is van een ruimte.
15:58
Speaker 2: Het kan zijn dat er goedkeuring nodig is voordat er
16:00
Speaker 2: dure apparatuur geïnstalleerd mag worden. Er kunnen regels gelden voor
16:03
Speaker 2: de opslag van gevoelige gegevens. Deze regels zorgen ervoor dat
16:05
Speaker 2: het kantoor overzichtelijk blijft, ook als er meer mensen komen werken.
16:08
Speaker 2: In Azure helpt governance ook bij compliance. Als uw organisatie
16:12
Speaker 2: zich aan regels moet houden voor klantgegevens, financiële gegevens of gezondheidsinformatie,
16:16
Speaker 2: moet u weten waar die gegevens zich bevinden, wie er
16:18
Speaker 2: toegang toe heeft en of de vereiste controles aanwezig zijn.
16:21
Speaker 2: Beveiliging richt zich op de bescherming van de mensen, systemen
16:24
Speaker 2: en gegevens binnen die omgeving. EnterID helpt bij het beheren
16:27
Speaker 2: van aanmeldingen en machtigingen. Voor waardelijke toegang kan de situatie
16:30
Speaker 2: rond een aanmelding controleren, bijvoorbeeld of de persoon een goedgekeurd
16:33
Speaker 2: apparaat gebruikt of een extra aanmeldingscontrole nodig heeft. Microsoft Defender
16:36
Speaker 2: Tools kunnen helpen bij het opsporen van bedreigingen en verdachte
16:39
Speaker 2: activiteiten op het platform. Het idee hierachter is het principe
16:41
Speaker 2: van minimale bevoegdheden. Mensen krijgen alleen de toegang die ze
16:44
Speaker 2: nodig hebben voor hun werk, niet zomaar brede toegang omdat
16:46
Speaker 2: dat makkelijker lijkt. Een applicatie krijgt alleen de machtigingen die
16:49
Speaker 2: nodig zijn. Dat klinkt in eerste instantie misschien trager, maar
16:52
Speaker 2: brede toegang creëert een veel groter probleem wanneer een account
16:55
Speaker 2: wordt gehackt, iemand een fout maakt of een externe medewerker
16:57
Speaker 2: niet langer voor het bedrijf werkt. Beheer is het dagelijkse
17:00
Speaker 2: werk dat Azure draaiende houdt. Iemand moet de monitoringwaarschuwingen in
17:03
Speaker 2: de gaten houden. Iemand moet backups controleren en aantonen dat
17:06
Speaker 2: gegevens kunnen worden hersteld. Iemand moet updates installeren, reageren op incidenten,
17:10
Speaker 2: kosten beoordelen en beslissen wat er gebeurt als een service
17:12
Speaker 2: om 2 uur s'nachts uitvalt. Deze taken vinden achter de
17:15
Speaker 2: schermen plaats, maar gebruikers merken het snel als niemand ze
17:17
Speaker 2: op zich neemt. Er is ook een model van gedeelde
17:19
Speaker 2: verantwoordelijkheid in cloud services. Microsoft beheert en beveiligt de onderliggende
17:23
Speaker 2: Azure cloud. Microsoft zorgt voor de fysieke datacenters en de
17:26
Speaker 2: kern cloud services. Uw organisatie blijft verantwoordelijk voor wat er
17:30
Speaker 2: in Azure wordt geplaatst, hoe services worden geconfigureerd, wie toegang heeft,
17:34
Speaker 2: hoe gegevens worden beschermd en hoe workloads worden beheerd. De
17:36
Speaker 2: overstap naar Azure neemt deze verantwoordelijkheden niet weg. Het verandert
17:39
Speaker 2: alleen de manier waarop u ermee omgaat, dus leg de
17:41
Speaker 2: verantwoordelijkheden duidelijk vast. Wie ontvangt een melding wanneer een database uitvalt?
17:44
Speaker 2: Wie kan een backup herstellen? Wie keurt de toegang voor
17:47
Speaker 2: een nieuwe medewerker goed? Wie reageert wanneer de vendor een
17:49
Speaker 2: bedreiging meldt? Wie controleert of een workload meer verbruikt dan verwacht?
17:52
Speaker 2: Als het antwoord iemand van IT is, is dat nog
17:54
Speaker 2: geen oplossing. Een veel voorkomende fout lijkt in eerste instantie onschuldig.
17:58
Speaker 2: Een team schakelt monitoring in, dashboards verschijnen en er komen
18:01
Speaker 2: meldingen binnen. Iedereen voelt zich veiliger omdat het waarschuwingssysteem bestaat.
18:05
Speaker 2: Dan gaat er s'nachts een melding af. Niemand ontvangt deze,
18:07
Speaker 2: of meerdere mensen ontvangen hem en gaan ervan uit dat
18:09
Speaker 2: iemand anders wel actie zal ondernemen. De melding wordt achtergrond lawaai.
18:12
Speaker 2: Een klein probleem groeit uit tot iets groters omdat het
18:13
Speaker 2: systeem het probleem wel meldde, maar niemand de verantwoordelijkheid nam
18:15
Speaker 2: voor de afhandeling. Monitoring zonder verantwoordelijkheid is slechts ruis. Regels
18:19
Speaker 2: moeten ook in balans zijn. Te weinig regels kunnen leiden
18:21
Speaker 2: tot blootstelling van privégegevens, ongecontroleerde uitgaven en on-track eerbare middelen.
18:25
Speaker 2: Te veel regels kunnen teams ertoe aanzetten om de officiële
18:27
Speaker 2: procedures te omzeilen omdat ze hun werk niet gedaan krijgen.
18:29
Speaker 2: Goed bestuur biedt mensen een duidelijke, veilige weg vooruit. Het
18:32
Speaker 2: maakt van elk verzoek geen langdurige discussie. CAF helpt u
18:36
Speaker 2: deze keuzes te herzien naarmate de organisatie verandert. Een nieuwe applicatie,
18:39
Speaker 2: een andere regio, een nieuwe compliance eist of een andere
18:42
Speaker 2: manier van werken kan updates van de regels en het
18:43
Speaker 2: ondersteuningsmodel vereisen. Het framework eindigt niet wanneer de laatste workload
18:47
Speaker 2: wordt verplaatst. Het blijft nuttig omdat het kantoor blijft veranderen en...