Wat is een Azure virtueel netwerk? De meeste mensen horen die term en denken dat het gewoon een instelling is die je inschakelt bij het implementeren van een virtuele machine, iets waar je een vinkje bij zet en daarna vergeet. Maar dit is de waarheid. Een Azure virtueel netwerk is niet zomaar een instelling. Het is het fundament van alles wat je in Azure bouwt. Elke virtuele machine, elke database, elke app service, elke functie die je implementeert, ze bevinden zich allemaal in zo'n netwerk. En als je niet begrijpt hoe ze werken, vlieg je blind. Aan het eind van deze aflevering begrijp je wat een V net werkelijk is, hoe het werkt en waarom elke resource die je implementeert ervan afhankelijk is. We behandelen wat een V net is, hoe IP adressen werken, subnetten, beveiliging, routering en hoe je V nets met elkaar verbindt. Pak je koffie en laten we beginnen. Wat is een V net? Het private cloud netwerk.

Laten we beginnen met de eenvoudigste definitie. Een Azure virtueel netwerk of kortweg V net is je eigen private netwerk binnen Azure. Zie het als een privékantoorgebouw. Alleen mensen die jij toelaat kunnen naar binnen. Jij bepaalt wie er door de deur komt, wie naar welke verdieping mag en wie er volledig buiten wordt gesloten. Voordat V nets bestonden was alles anders. Implementeerde je een virtuele machine in de cloud, dan was deze standaard eigenlijk blootgesteld aan het internet. Zonder privé netwerk eromheen. Iedereen die het IP adres wist, kon proberen verbinding te maken. Dat was een beveiligingsnachtmerrie. Wat is er veranderd? Azure gaf je de mogelijkheid om geïsoleerde private netwerkruimtes te creëren. Je definieert een grens. Je bepaalt wat erin komt. Niets buiten die grens kan naar binnen, tenzij je het expliciet toestaat. Eén ding om vooraf te weten, je V net leeft in een specifieke Azure regio.

Het is niet wereldwijd. Maak een V net aan in West-Europa en daar blijft het. Resources in een andere regio kunnen er niet zomaar in springen. Ze hebben hun eigen V net nodig of je moet ze later verbinden. Wanneer je een V net maakt, definieer je zelf de IP adresruimte. Azure kiest deze niet voor je. Jij bepaalt het bereik van IP adressen dat je resources zullen gebruiken. Dat is een grote verantwoordelijkheid en in het volgende deel bespreken we hoe je dit goed aanpakt. Dit is het belangrijkste punt. V nets zijn de basis. Elke virtuele machine, elke database, elke Azure functie die je implementeert, bevindt zich in zo'n netwerk. Zonder een V net hebben je resources geen privé netwerk context. Ze zweven gewoon in de cloud zonder grenzen, zonder isolatie, zonder beveiliging. Dus wat betekent dit voor jou? Als je iets bouwt in Azure, begin dan eerst met een V net. Niet nadat je je resources hebt ingezet, maar daarvoor.

Je V net is de grond waarop je bouwt. Je zou geen huis bouwen zonder eerst de grond te kopen, toch? Hetzelfde idee. IP adressering en CIDR, het kiezen van je adresruimte. Dus laten we beginnen. Wanneer je een V net aanmaakt, is de eerste grote beslissing het kiezen van een IP bereik. Dat doe je met CIDR notatie. CIDR staat voor Classless Interdomain Routing, maar het betekent eigenlijk alleen dat je zegt ik heb zoveel IP adressen nodig. Waarom is dit belangrijk? Omdat het bereikt dat je kiest bepaalt hoeveel resources je in je virtuele netwerk kunt plaatsen. Zo werkt het. CIDR gebruikt een schuine streep en een getal, zoals 16 of 24. Dat getal geeft de grootte van de adresruimte aan. Een 16 geeft je ongeveer 65.000 IP adressen. Dat is veel. Een 24 geeft je er ongeveer 250, wat perfect is voor een klein team of één applicatielaag. Dus, wanneer je je V net ontwerpt, moet je nadenken over hoeveel resources je hebt en hoe je ze wilt groeperen.

Nu kun je niet zomaar elk IP bereik kiezen. Asher volgt de RFC 1918 standaard, die privé IP bereiken reserveert voor interne netwerken. Je hebt drie opties. Het 10 XXX bereik is het grootst en biedt volop ruimte om te groeien. Het 172.16 XX bereik is wat kleiner, maar nog steeds nuttig. En het 192.168 XX bereik is het bereik dat je waarschijnlijk thuis op je router hebt. Dit is het punt. De adresruimte van je V net mag niet overlappen met een ander netwerk waarmee je verbinding wilt maken. Dit is een veelgemaakte fout. Veel mensen kiezen een bereik dat bekend voorkomt, om er later achter te komen dat het conflicteert met hun bedrijfsnetwerk. Dus, als je bedrijfsnetwerk 1.0.0.0.0 slash 1.6 gebruikt, gebruik dan niet datzelfde bereik in Asher. Als je ze later probeert te verbinden, zullen ze botsen en weet het verkeer niet waar het naartoe moet. Laat me je een concreet voorbeeld geven. Stel, je bouwt een hybride opstelling, waarbij Asher verbinding maakt met je on-premises datacenter en je datacenter gebruikt 1.0.0.0.0 slash 1.6.

Als je een V net aanmaakt met hetzelfde bereik, heb je twee netwerken die strijden om dezelfde IP's. Denk er maar eens over na. Twee netwerken die hetzelfde IP-bereik gebruiken, kunnen niet goed communiceren. Het is als twee huizen met hetzelfde adres. De post raakt in de war. Dat is een probleem dat je niet achteraf wilt oplossen. Dus plan vooruit en kies een uniek bereik. En hier is een planningstip. Kies een groter bereik dan je denkt nodig te hebben. Je denkt misschien dat een 24 nu genoeg is, maar naarmate je applicatie groeit, wou je dat je een 16 had. Dit kun je achteraf niet zomaar aanpassen. Zodra je V net is aangemaakt en je resources hebt ingezet, is het wijzigen van de adresruimte ingewikkeld. Het is mogelijk, maar dat wil je niet op een live systeem doen. Geef jezelf dus de ruimte om te groeien. Wat betekent dit voor jou? Zie de adresruimte van je V net als het kopen van land.

Zorg voor genoeg ruimte voor toekomstige groei. Als je denkt dat je een klein perceel nodig hebt, koop dan een middelgroot perceel. Je zult jezelf later dankbaar zijn. Dat is de belangrijkste, Lee. Plan je adresruimte met het oog op toekomstige groei. Subnetten, het verdelen van je netwerk. Oké, je hebt je V net en je hebt je adresruimte gekozen. Wat nu? Je gooit niet zomaar alles op één grote hoop. Daar komen subnetten kijken. Subnetten zijn een van de fundamentele bouwstenen van je V net. Hiermee kun je je resources ordenen en beveiligen. Een subnet is een kleiner deel van de adresruimte van je V net. Als je V net het gebouw is, zijn subnetten de individuele kamers. Je zou je surferruimte, je receptie en je kantine toch ook niet allemaal in dezelfde open ruimte plaatsen. Hetzelfde idee geldt hier. Het is een simpel concept, maar het maakt een enorm verschil in hoe je je netwerk beheert.

Verschillende resources gaan in verschillende subnetten. Je webservers in het ene subnet, je databases in een ander en je applicatielogica in een derde. Waarom? Twee redenen. Beveiliging en organisatie. Laten we eerst over beveiliging praten, want dat is meestal het belangrijkste. Beveiliging eerst. Als iemand inbreekt op je webserver, wil je niet dat ze direct toegang hebben tot je database. Gescheiden subnetten creëren een natuurlijke barrière. De aanvaller zou die grens moeten oversteken en jij kunt precies controleren wat er doorheen gaat. Je kunt ook netwerkbeveiligingsgroepen gebruiken om verkeer tussen subnetten te beheren. Dat is een onderwerp voor een andere video, maar het is goed om te weten dat subnetten de basis vormen voor die beveiliging. Organisatie als tweede. Wanneer alles een plek heeft, is het beheer eenvoudiger. Je weet welk subnet je front-end resources bevat en welke je back-end data bevat.

Je kunt beleid en regels op het hele subnet tegelijk toepassen, in plaats van elke resource afzonderlijk te configureren. Dat bespaart tijd en vermindert fouten. Hier is een detail dat mensen vaak verrast. Azure reserveert 5 IP-adressen in elk subnet voor eigen interne doeleinden, zoals routing en DNS. Dus als je een subnet met een 24 range aanmaakt voor 256 adressen, krijg je er in feite maar 251 bruikbare. Het is een veel voorkomende valkuil. Je plant voor 256, maar krijgt er slechts 251. Voeg daarom altijd wat extra ruimte toe bij het bepalen van je subnetten. Het goede nieuws is dat je na het aanmaken van het VNet nog subnetten kunt toevoegen. Je zit niet vast aan de subnetten die je tijdens de creatie hebt opgezet. Dus als je merkt dat je een apart subnet nodig hebt voor beheertools of monitoring systemen, voeg het later toe. Geen probleem, maar het is nog steeds beter om ze vooraf te plannen.

Subnetten later toevoegen is mogelijk, maar je moet misschien resources verplaatsen, wat storend kan zijn. Maar dit is de best practice. Gebruik vanaf het begin aparte subnetten voor de verschillende lagen van je applicatie. Denk na over je applicatiearchitectuur. Doorgaans heb je een front-end laag die gebruikersverzoeken afhandelt, een back-end laag voor bedrijfslogica en een datalaag voor informatieopslag. Elk van deze zou zijn eigen subnet moeten hebben. Wacht niet tot je in productie bent om te beseffen dat je de boel moet splitsen. Dat is een stuk lastiger wanneer resources al zijn geïmplementeerd. Wat betekent dit voor jou? Subnetten zijn de manier waarop je je netwerk georganiseerd en veilig houdt. Het zijn de kamers in je gebouw. Plan ze vroeg en geef elke laag van je applicatie zijn eigen ruimte. Zo hou je je netwerk overzichtelijk en veilig. Publieke versus private IP-adressen.

Wie kan wat zien? Laten we praten over IP-adressen, want niet alle IP-adressen zijn hetzelfde. Wanneer je een resource binnen een v-net implementeert, krijgt deze standaard een privaat IP-adres. Dat is het adres dat het gebruikt om te communiceren met andere resources binnen het v-net. Zie het als een intern doorkiesnummer. Alleen mensen in het gebouw kunnen het bereiken. Private IP's zijn alleen toegankelijk vanuit het v-net of vanuit verbonden netwerken. Als je thuis op je laptop zit, kun je een privaat IP in Azure niet bereiken. Het staat niet op het internet. Het bevindt zich in je eigen private netwerk. Dus, hoe maak je een resource bereikbaar vanaf het internet? Je geeft het een publiek IP-adres. Dat is het adres dat zichtbaar is voor de buitenwereld, als een gepubliceerd telefoonnummer in plaats van een intern toestelnummer. Dit is het belangrijkste punt. Publieke IP's zijn optioneel.

Je wijst ze expliciet toe, omdat Azure nooit een publiek IP aan je resources geeft, tenzij je erom vraagt. Dat is een bewuste keuze. De standaard moet privaat zijn en publiek moet een wel overwogen keuze zijn. En hier maken veel beginners een fout. Ze geven alles een publiek IP-adres. Hun webserver, hun database, hun back-end API. Ze krijgen er allemaal een. Dat is een beveiligingsrisico. Je database hoeft niet bereikbaar te zijn vanaf het internet, en je back-end API evenmin. Alleen front-end resources waarmee gebruikers daadwerkelijk interacteren, moeten publieke IP-adressen hebben. Publieke IP-adressen zijn er in twee soorten, statisch en dynamisch. Een statisch publiek IP-adres blijft gelijk, zelfs als je de resource stopt en opnieuw start. Een dynamisch publiek IP-adres kan veranderen. Als je een productieapplicatie draait, wil je waarschijnlijk statische IP's, zodat gebruikers je altijd kunnen vinden.

Als je iets test, is een dynamisch adres vaak prima. Je kunt ook een zogenaamde publieke IP-prefix gebruiken, waarmee je een blokadressen reserveert. In plaats van ze één voor één aan te maken, reserveer je een bereik en wijs je individuele adressen uit dat bereik toe. Handig als je weet dat je meerdere publieke IP's nodig hebt voor een project. Wat betekent dit voor jou? Private IP-adressen zijn de veilige standaard. Ze zijn als een intern doorkiesnummer. Publieke IP's zijn een bewuste keuze die je alleen maakt wanneer iets bereikbaar moet zijn vanaf buitenaf. En als je ze nodig hebt, denk dan na of je statisch of dynamisch wilt en of een prefix zinvol is. Netwerkbeveiligingsgroepen voor het beheren van verkeer. Dus, je hebt je vnet, je subnets en je IP-adressen op orde. Maar hoe controleer je daadwerkelijk welk verkeer naar binnen en buiten mag? Daar komen netwerkbeveiligingsgroepen, oftewel NSG's, in beeld.

Een NSG is de poortwachter die controleert welk verkeer je resources binnenkomt en verlaat. Zie het als een uitsmijter bij de deur van een club die ID's controleert, de gastenlijst bekijkt en mensen weigert die daar niet horen te zijn. Elk stukje verkeer dat je resource probeert te bereiken, moet eerst langs deze uitsmijter. NSG's werken met regels. Elke regel staat toe of weigert op basis van vier zaken, het bron-IP-adres, het doel-IP-adres, het poortnummer en het protocol. Zo kun je verkeer vanaf mijn kantoor-IP-adres op poort 443 toestaan, of al het internetverkeer op poort 22 weigeren. Dat soort controle. Hier is een krachtige functie. Je kunt een NSG koppelen aan een subnet of direct aan de netwerkinterface van één enkele VM. Als je het aan een subnet koppelt, is die NSG van toepassing op alles daarbinnen. Elke VM, elke database, elke resource. Het is een overkoepelend beleid. Als je het aan de netwerkinterface van een specifieke VM koppelt, geldt dit alleen voor die ene machine.

Je kunt zelfs beide doen. Een NSG op subnet-niveau voor algemene regels en een NSG op nik-niveau voor uitzonderingen. De standaardregels die Azure aanmaakt zijn heel redelijk. Ze staan al het verkeer binnen het v-net toe, zodat je resources met elkaar kunnen communiceren, en ze blokkeren al het verkeer van het internet, zodat niets van buitenaf je resources kan bereiken tenzij je dit expliciet toestaat. Dat is een goed beginpunt. Laat me je een veelvoorkomend voorbeeld geven. Stel dat je een Linux virtuele machine beheert en je moet er via SSH op inloggen. Je maakt een NSG-regel aan die inkomend verkeer op port 22 toestaat, maar je wilt niet dat SSH overal vandaan toegankelijk is. Dat is vragen om problemen, dus beperk je het tot je eigen IP-adres, zodat alleen jij via SSH kunt inloggen en al het andere wordt geblokkeerd. Hetzelfde geldt voor RDP op port 3389 voor Windows-machines. Wat betekent dit voor jou?

NSG's zijn je eerste verdedigingslinie en het mooiste is, ze zijn gratis. Er zijn geen extra kosten aan verbonden, dus er is geen excuus om ze niet in te stellen. Elk subnet en elke resource zou een gekoppelde NSG moeten hebben. Begin met alles weigeren en open alleen wat je nodig hebt. Routetabellen en routering, het sturen van verkeer. Laten we het nu hebben over routering, want als je eenmaal hebt besloten welk verkeer is toegestaan, moet je bepalen waar het daadwerkelijk naartoe gaat. Het zit zo, Azure maakt automatisch systeemroutes aan voor elk subnet. Je hoeft zelf niets te doen. Zie het als een standaard GPS die de basiswege kent. Verkeer binnen het V-net, verkeer naar gekoppelde V-nets, verkeer naar het internet. Het werkt allemaal standaard, maar soms brengt de standaard GPS je niet waar je heen wilt. Dat is het moment waarop je door de gebruiker gedefinieerde routes of UDR's nodig hebt.

Hiermee kun je de systeemroutes van Azure overschrijven en de controle over het pad van het verkeer overnemen. Hoe werkt het? Je maakt een routetabel aan. Je voegt je aangepaste routes toe. Vervolgens koppel je die routetabel aan een subnet. Vanaf dat moment voegt het verkeer dat het subnet verlaat jouw regels in plaats van de standaardinstellingen. Laat me je een concreet voorbeeld geven. Stel dat je wilt dat al het internetverkeer vanuit je V-net eerst via een firewall gaat. Misschien moet je het inspecteren, loggen of schadelijke sites blokkeren. De standaard systeemroutes stuurt internetverkeer direct naar buiten. Dat is niet wat je wilt, dus maak je een route aan die zegt dat al het verkeer naar 0.0.0.0, oftewel het hele internet, in plaats daarvan naar de firewall moet gaan. Dat is een door de gebruiker gedefinieerde route. Routetabellen gebruiken iets dat de next hop wordt genoemd.

Dat is de bestemming waar het verkeer naartoe wordt gestuurd. Je hebt een paar opties. Je kunt het naar een virtueel apparaat sturen, zoals een firewall. Je kunt het naar een virtuele netwerk gateway sturen, waarmee je verbinding maakt met on-premises netwerken. Je kunt het rechtstreeks naar het internet sturen of naar NAN, waardoor het verkeer in feite wordt verwijderd. Het belangrijkste om te begrijpen is dat routering de manier is waarop je het pad van verkeer door je netwerk beheert. Systeemroutes zijn een goede standaard, maar ze zijn niet altijd geschikt voor jouw situatie. Als verkeer via een inspectiepunt of naar een specifieke gateway moet of volledig moet worden geblokkeerd, heb je door de gebruiker gedefinieerde routes nodig. Wat betekent dit voor jou? Routering bepaalt waar verkeer naartoe gaat en je hebt de mogelijkheid om Azure-standaarden te overschrijven wanneer dat nodig is.

Begin met de systeemroutes, begrijp wat ze doen en voeg vervolgens aangepaste routes toe wanneer je architectuur daarom vraagt. V-net-pering, het verbinden van netwerken. Tot nu toe hebben we het gehad over één enkel V-net, één gebouw, één privé-netwerk. Maar wat gebeurt er als je meerdere V-nets hebt? Misschien heb je er een voor je productieomgeving en een andere voor tests, of draai je applicaties in verschillende Azure-regio's. Standaard zijn deze V-nets volledig geïsoleerd. Ze kunnen niet met elkaar communiceren. Het zijn als losstaande gebouwen zonder wegen ertussen. Dat is waar V-net-pering om de hoek komt kijken. Hiermee kun je twee V-nets privé verbinden, en dan bedoel ik ook echt privé. Verkeer tussen gekoppelde V-nets blijft op het Microsoft Backbone-netwerk. Het komt nooit op het openbare internet. Dat betekent lage latentie, hoge bandbreedte en geen blootstelling aan externe bedreigingen.

Hier is iets wat mensen vaak verrast. Pering werkt ook tussen regio's. Dat wordt globale pering genoemd. Je kunt een V-net in West-Europa koppelen aan een V-net in Zuidoost-Azië, en het verkeer daartussen blijft op het privé-netwerk van Microsoft. Geen VP en gateways, geen publieke IP's, gewoon een directe privé-verbinding. Maar er is één regel die je absoluut niet mag overtreden. Gekoppelde V-nets moeten niet overlappende adresruimtes hebben. Als beide V-nets het 1.0.0.0.0 slash 1.6 bereik proberen te gebruiken, kunnen ze niet worden gekoppeld. De IP-adressen zouden botsen en Azure zou niet weten bij welk netwerk een pakket hoort. Herinner je je die eerdere planningstip over het zorgvuldig kiezen van je adresruimte nog? Dit is waarom. Als je denkt dat je V-nets later misschien wilt koppelen, zorg er dan vanaf het begin voor dat hun bereiken niet overlappen. Dit is een detail waar mensen vaak over struikelen.

Pering is niet transitief. Wat betekent dat? Stel dat V-n-et-a gekoppeld is met V-n-et-b en V-n-et-b is gekoppeld met V-n-et-c. V-n-et-a bereikt V-n-et-c niet automatisch via bezig zijn niet verbonden. Elke pering is een directe link tussen precies twee V-n-ets. Als je wilt dat A met C communiceert, heb je een aparte pering tussen A en C nodig. Dus, hoe pak je dit op schaal aan? Je gebruikt een hub- en spookarchitectuur. Een centraal V-n-et, de hub, is gekoppeld met vele andere V-n-ets, de spokes. De hub kan gedeelde services bevatten, zoals een firewall, een VP en gateway of monitoring tools. De spokes bevatten je individuele workloads. Elke spook koppelt direct met de hub, maar spokes koppelen niet met elkaar. Als een spook een andere spook moet bereiken, gaat het verkeer via de hub. Dat houdt de boel georganiseerd en geeft je een centrale plek voor beveiligingsbeleid. Wat betekent dit voor jou?

Pering is hoe je netwerken bouwt die meerdere V-n-et-s en regio's omspannen. Het is de brug tussen je gebouwen. Plan je adresruimte zodat ze niet overlappen. Onthoud dat pering niet transitief is en overwege een hub- en spookontwerp zodra je groeit buiten één V-n-et. Hoe alles verbonden is, het grote plaatje. Laten we dus een stap terug doen en zien hoe deze onderdelen in elkaar passen. Dat is waar de echte kracht zit. Je begint met een V-n-et. Dat is jouw privéruimte in Azure. Zie het als jouw land. Binnen dat land maak je subnets aan. Dat zijn je kamers. Eén voor websurvers, één voor databases, één voor beheertools. Elk subnet krijgt een eigen adresblok uit de adresruimte van het V-n-et. Vervolgens voeg je beveiliging toe. Netwerkbeveiligingsgroepen worden aan je subnets gekoppeld. Ze bepalen welk verkeer in en uit mag. Je websubnet staat verkeer van het internet toe op poort 443. Je database subnet staat alleen verkeer toe vanaf het websubnet op poort 1433.

De uitsmijter bij elke deur weet precies wie er naar binnen mag. Daarna stel je routering in. Misschien wil je dat al het uitgaande internetverkeer via een firewall gaat voor inspectie. Je maakt een routetabel, voegt een aangepaste route toe en koppelt deze aan je subnets. Nu volgt het verkeer het pad dat jij hebt ontworpen in plaats van de standaard van Azure. En tot slot verbind je alles met elkaar. Je koppelt je V-net met andere V-nets, misschien een hap V-net met je firewall en gedeelde services. Nu omspant je applicatie meerdere netwerken, maar werkt het als één verbonden systeem. Hier is het aha-moment. Geen van deze onderdelen werkt in isolatie. Een V-net zonder subnets is slechts lege ruimte. Subnets zonder NSG staan wijd open. Routering zonder duidelijk ontwerp stuurt verkeer naar de verkeerde plek. Pering zonder planning zorgt voor adresconflicten. Het is een systeem. Elk onderdeel hangt af van de andere.

Laat me je een concreet voorbeeld geven. Stel je een webapplicatie voor. Je webservers staan in een publiek subnet met een NSG die HTTPS verkeer van het internet toestaat. Je applicatieservers staan in een privaat subnet dat alleen verkeer accepteert van het websubnet. Je database bevindt zich in een ander privé subnet dat alleen verkeer van het appsubnet accepteert. Een routetabel dwingt al het uitgaande verkeer door een firewall in het HAPV-net voor logboekregistratie en inspectie. En het geheel is gekoppeld aan je bedrijfsnetwerk, zodat je interne team het kan beheren. Dat is de echte waarde, niet een enkele functie. Het gaat om hoe ze allemaal samenwerken. Twintig jaar geleden kocht je losse servers, configureerde je fysieke routers en beheerde je firewalls per apparaat. Alles was handmatig, traag en duur. Azure biedt je dit alles als een service. Je definieert het met een paar klikken of een script en het werkt gewoon.

Wat betekent dit voor jou? Zodra je ziet hoe deze onderdelen in elkaar grijpen, wordt Azure netwerken voorspelbaar. Je bent niet aan het gokken. Je bent aan het ontwerpen. En als er iets kapot gaat, weet je precies waar je moet kijken omdat je het systeem begrijpt. Dus dit is wat ik wil dat je uit deze aflevering meeneemt. Ten eerste, de belangrijkste stap die je kunt zetten. Maak een v-net met een goed geplande adresruimte voordat je iets implementeert. Die ene beslissing beïnvloedt alles wat daarna komt. Ten tweede, gebruik subnets om je applicatielagen te scheiden. Websurvers, app-survers, databases, geef ze elk hun eigen ruimte. En ten derde, begin met NSG's. Ze zijn gratis. Ze zijn krachtig en verbeteren je beveiliging aanzienlijk vanaf dag 1. Je v-net is het fundament van alles wat je in Azure bouwt. Doe het goed en al het andere wordt makkelijker. Doe het fout en je zult al je tijd besteden aan het vechten tegen je netwerk.

Abonneer je op je favoriete podcastplatform en deel dit met iemand die aan zijn Azure reis begint. Laat een reactie achter als het kwartje is gevallen. Ik zie je in de volgende aflevering.