Schaal voorbij de grenzen: waarom je Azure Compute Fleet nodig hebt voor enorme workloads

By Mirko Peters · 2026-08-13

Welkom terug bij onze doorlopende verkenning van geavanceerde cloudarchitecturen. In onze nieuwste podcastaflevering, Azure Compute Fleet – Simply Explained, hebben we het gehad over een enorme uitdaging waar moderne organisaties mee te maken krijgen als het gaat om cloudinfrastructuur. Als je ooit hebt geprobeerd om honderden of duizenden virtuele machines tegelijk te provisionen voor een zware b

Automatically translated with AI from the original post. Read the English original

Welkom terug bij onze doorlopende verkenning van geavanceerde cloudarchitecturen. In onze nieuwste podcastaflevering, Azure Compute Fleet – Simply Explained, hebben we het gehad over een enorme uitdaging waar moderne organisaties mee te maken krijgen als het gaat om cloudinfrastructuur. Als je ooit hebt geprobeerd om honderden of duizenden virtuele machines tegelijk te provisionen voor een zware batchjob, een high-performance computing-simulatie of een grootschalige dataverwerkingspipeline, dan ken je de frustratie van plotselinge capaciteitsgrenzen al. In deze blogpost gaan we dieper in op die concepten. We bekijken waarom traditionele methoden tekortschieten en hoe Azure Compute Fleet fundamenteel verandert hoe je enorme rekenkracht in de cloud verkrijgt en beheert.

Wat is Azure Compute Fleet?

Azure Compute Fleet is een gespecialiseerde, beheerde service die specifiek is ontworpen om grootschalige capaciteitsproblemen op te lossen. Wanneer je een workload in één keer wilt opschalen van nul naar duizenden workers, kunnen standaarddeploymentmethoden snel vastlopen. Eén virtuele machine aanmaken is eenvoudig, maar aan een regio vragen om duizend identieke virtuele machines van precies één SKU te leveren, is een heel andere uitdaging. Azure Compute Fleet verandert de fundamentele vraag die je aan de cloud stelt. In plaats van te vragen: "Hoe krijg ik duizend identieke VM's van exact deze grootte?", vraag je: "Hoe krijg ik de rekenkracht die mijn workload nodig heeft, met gebruikmaking van verschillende acceptabele opties?" Door je totale capaciteitsvereisten, acceptabele VM-groottes, regionale voorkeuren en je tolerantie voor on-demand versus goedkopere Spot-prijzen te beschrijven, kan Azure intelligent zoeken over meerdere beschikbaarheidspools om de resources te verkrijgen die je applicatie nodig heeft.

Waarom flexibiliteit belangrijk is

Om te begrijpen waarom Compute Fleet zo krachtig is, moeten we goed kijken naar hoe cloudcapaciteit werkt. Een VM-SKU vertegenwoordigt een specifieke combinatie van CPU, geheugen, opslagarchitectuur en processorfamilie. Als je automatiseringsscripts maar één specifieke SKU aanvragen, kan Azure alleen naar die exacte match zoeken. Als die specifieke familie in jouw doelregio veel vraag kent, blijft je deployment hangen in een wachtrij of mislukt ze volledig. Compute Fleet voegt flexibiliteit toe doordat je een breed scala aan acceptabele VM-groottes kunt opgeven. Zolang je workload zo is ontworpen dat hij succesvol draait op die verschillende hardwareconfiguraties, kan Azure je workers dynamisch verdelen. Op grote schaal vergroot deze flexibiliteit de kans enorm dat je precies de hoeveelheid totale rekenkracht krijgt die je nodig hebt, op precies het moment dat je die nodig hebt.

Tot 10.000 VM's in één fleet

Grootschalige infrastructuur handmatig beheren is een recept voor operationele uitputting. Zelf orchestratiescripts schrijven om deployment-retries, fallback-VM-groottes en monitoring over tientallen verschillende configuraties af te handelen, wordt snel een onbeheersbare nachtmerrie. Compute Fleet is ontworpen om die operationele last weg te nemen. Het ondersteunt tot 10.000 virtuele machines binnen één fleet-aanvraag. Je definieert je fleetparameters één keer, waarna Azure de beschikbare capaciteit controleert binnen alle toegestane opties, automatisch de optimale combinatie van resources bepaalt en de benodigde onderliggende groepen virtuele machines opstart. Deze native mogelijkheid zorgt ervoor dat engineeringteams zich kunnen concentreren op hun eigenlijke workloads, in plaats van talloze uren kwijt te zijn aan het oplossen van fouten in de toewijzing van infrastructuur.

Wat Compute Fleet niet doet

Hoewel Azure Compute Fleet een gamechanger is voor het verkrijgen van capaciteit, is het belangrijk om de grenzen ervan te begrijpen. Compute Fleet lost het capaciteitsprobleem op, maar bepaalt of vervangt je volledige applicatiearchitectuur niet. Je blijft volledig verantwoordelijk voor de virtuele-machine-images, netwerkconfiguraties, beveiligingsgroepen en applicatiesoftware die elke worker nodig heeft om te draaien. Compute Fleet weet van nature niet of je workers cinematische visuele effecten renderen, complexe financiële berekeningen uitvoeren, geautomatiseerde regressietests draaien of ruwe wetenschappelijke telemetriedata analyseren. Bovendien vervangt het geen kernonderdelen van de architectuur, zoals load balancers, duurzame berichtenwachtrijen, applicatielogica of disaster-recoverymechanismen. De enige, sterk gerichte taak is het verkrijgen en beheren van grote hoeveelheden rekencapaciteit wanneer er meerdere acceptabele configuraties mogelijk zijn.

VM-formaten kiezen die acceptabel zijn

Een effectieve fleetdeployment begint met een cruciale architectuurbeslissing: bepalen welke VM-formaten je applicatie daadwerkelijk kan gebruiken. Op fleetschaal moet je belangrijkste zorg niet zijn om een bepaald processormodel te bemachtigen uit persoonlijke voorkeur. Voer in plaats daarvan een grondige audit uit van je softwarevereisten. Van welk aantal CPU-cores, geheugengrenzen, prestaties van lokale opslag of type accelerators is je applicatie echt afhankelijk? Als meerdere VM-families aan die operationele eisen voldoen, geeft je die allemaal toe te staan Azure een veel breder zoekgebied. Je moet echter elk afzonderlijk formaat dat je opneemt zorgvuldig valideren. Voeg nooit een VM-familie toe aan je fleetconfiguratie alleen omdat die goedkoper lijkt, als je software specifieke instructiesets, gespecialiseerde drivers, unieke opslagconfiguraties of specifieke hardwarefuncties vereist.

Capaciteit versus prijs

Een andere belangrijke ontwerpoverweging is het in balans brengen van directe capaciteitsbehoefte en algemene kostenoptimalisatie. Verschillende workloads vragen om totaal verschillende deploymentstrategieën. Denk bijvoorbeeld aan een nachtelijke financiële risicoberekening met een strak uitvoeringsvenster die klaar moet zijn voordat de wereldmarkten de volgende ochtend openen. In dat specifieke scenario is het direct garanderen van capaciteit veel belangrijker dan de absoluut laagste prijs per core. Andere workloads daarentegen bieden enorme planningsflexibiliteit. Achtergrondtests, langlopende simulaties, het verwerken van achterstallige data en tijdelijke ontwikkelomgevingen kunnen vaak kleine vertragingen bij het verkrijgen van volledige capaciteit verdragen in ruil voor drastisch lagere infrastructuurkosten. Compute Fleet geeft organisaties de architecturale vrijheid om hun deployments af te stemmen op deze verschillende operationele prioriteiten.

VM-selectie op basis van kenmerken

Om de configuratie nog krachtiger te maken, biedt Azure een benadering voor VM-selectie op basis van kenmerken, die in ons recente podcastmateriaal werd uitgelicht als een krachtige previewfunctie. In plaats van dat je tientallen afzonderlijke exacte VM-SKU's handmatig moet opsommen, laat deze mogelijkheid je algemene eigenschappen definiëren. Je kunt parameters opgeven zoals minimaal en maximaal aantal vCPU's, geheugenbereiken, eisen voor lokale NVMe-opslag of gespecialiseerde GPU-accelerators. Azure zoekt vervolgens dynamisch VM-formaten die precies aan deze kenmerkdefinities voldoen en gebruikt die. Dit biedt een enorme toekomstbestendigheid, omdat Microsoft steeds nieuwere en efficiëntere VM-generaties introduceert in de cloud. Je applicaties moeten wel nog steeds goed worden gevalideerd tegen elk nieuw gevonden hardwareprofiel.

On-demand VM's

Een robuuste fleet vraagt om begrip van de verschillende rollen van de verschillende inkoopmodellen. On-demand virtuele machines vormen de stabiele, onwrikbare basis van je fleet. Wanneer je een on-demand VM aanvraagt, betaal je het standaard, voorspelbare tarief, en Azure garandeert dat het resource niet wordt teruggevorderd alleen omdat de vraag van een andere klant piekt. Daardoor is on-demand capaciteit ideaal voor het absolute minimum aan rekencapaciteit dat je workload altijd nodig heeft om operationeel te blijven. Kritieke infrastructuurcomponenten zoals jobcoördinatoren, luisteraars op berichtenwachtrijen en primaire basisworkers moeten bijna altijd on-demand capaciteit gebruiken om ononderbroken toezicht te waarborgen.

Spot-VM's

Aan de andere kant van het aankoopspectrum vinden we Spot-virtuele machines. Spot-VM's stellen je in staat om ongebruikte Azure-rekencapaciteit te benutten tegen flinke kortingen, waarbij je vaak tot negentig procent bespaart ten opzichte van de standaard pay-as-you-go-prijs. De keerzijde van deze enorme besparingen is het risico op onderbreking. Azure behoudt zich het recht voor om Spot-capaciteit met weinig waarschuwing terug te nemen wanneer de regionale vraag die fysieke resources weer nodig heeft. Dit maakt Spot-VM's uitzonderlijk aantrekkelijk voor fouttolerante workloads, waarbij workers midden in een taak kunnen verdwijnen zonder catastrofale fouten te veroorzaken, mits je architectuur is ingericht om onderbroken bewerkingen veilig opnieuw uit te voeren.

Spot- en on-demandcapaciteit combineren

Je hoeft niet te kiezen tussen een puur on-demand-strategie en een uitsluitend op Spot gebaseerde aanpak. In de praktijk combineren de meest veerkrachtige architecturen beide aankoopmodellen in één samenhangende fleet. Door on-demand-VM's in te zetten voor je persistente control plane en je basiswerkers, garandeer je een voorspelbare minimale doorvoer. Tegelijkertijd kun je je fleet vullen met Spot-VM's om grote rekenpieken op te vangen tegen een fractie van de gebruikelijke kosten. Als Azure tijdens een capaciteitskrapte een deel van je Spot-workers terugneemt, blijven je kern-workers op on-demand ononderbroken verwerken. Zo bereik je een slimme economische balans tussen financiële besparingen en operationele stabiliteit.

Ontwerp voor onderbrekingen

Azure Compute Fleet beheert de onderliggende capaciteitstoewijzing netjes en verzorgt tijdige meldingen bij Spot-onderbrekingen, maar het kan niet op magische wijze applicatiedata beschermen die uitsluitend in het geheugen van een individuele worker is opgeslagen. Om de kracht van een fleet echt te benutten, moet je workload vanaf het begin zo worden opgezet dat ze het beëindigen van workers aankan. Denk bijvoorbeeld aan een gedistribueerde videorenderingpipeline. Als een project is opgedeeld in afzonderlijke taken voor het renderen van frames, en Azure een Spot-VM terugneemt terwijl frame 412 wordt verwerkt, moet die specifieke taak automatisch terugkeren naar je centrale berichtenwachtrij, zodat een andere beschikbare worker hem kan oppakken. Dit exacte architectuurpatroon past even goed bij wetenschappelijke simulaties, geautomatiseerde softwarebuilds, continuous integration-tests en grootschalige data-analyses.

Houd state buiten de worker

Om het in een dynamische fleet-omgeving te redden, moet je applicatie zich aan één gouden regel houden: houd je state volledig buiten de worker. Vertrouw niet op tijdelijke lokale schijfopslag voor kritieke, persistente data. Gebruik in plaats daarvan duurzame opslagoplossingen zoals Azure Blob Storage, beheerde relationele databases of gedistribueerde NoSQL-stores om de bron van waarheid te bewaren. Gebruik duurzame wachtrijen om taken over de fleet te verdelen en zorg dat je workers regelmatig checkpoints wegschrijven bij langlopende bewerkingen. Ontwerp je taken idempotent, wat betekent dat ze meerdere keren kunnen draaien zonder dubbele records of beschadigde output te veroorzaken. Wanneer een Spot-VM onverwacht verdwijnt, verlies je alleen het kleine deel van het werk dat op dat moment bezig was, in plaats van uren aan onherstelbare verwerkingstijd.

Compute Fleet versus Virtual Machine Scale Sets

Een veelgestelde vraag van engineers die deze technologie verkennen, is hoe Compute Fleet zich verhoudt tot Azure Virtual Machine Scale Sets (VMSS). Beide diensten beheren groepen virtuele machines, maar ze zijn gebouwd om fundamenteel verschillende problemen op te lossen. Virtual Machine Scale Sets beginnen meestal bij een specifieke applicatielaag. Je implementeert een webapp, een microservices-API of een bedrijfskritieke line-of-business-applicatie achter een load balancer, en VMSS schaalt het aantal identieke instanties omhoog of omlaag op basis van binnenkomend netwerkverkeer of CPU-drempelwaarden. Compute Fleet gaat juist uit van een heel ander uitgangspunt: hoe kan ik snel een grote pool van flexibele rekencapaciteit verkrijgen om een berg gedistribueerd werk te verwerken?

Wanneer kies je voor Virtual Machine Scale Sets

Virtual Machine Scale Sets blijven de absolute topkeuze voor langlopende, continue applicatielagen waarin instanties dezelfde rol vervullen en dynamisch moeten reageren op gebruikersverkeer. Ideale toepassingen zijn webapplicaties voor klanten, publieke API's, e-commerce-winkels en backendservers achter een Azure LoadBalancer of Application Gateway. In zulke omgevingen zijn het continu gezond houden van de applicatie, het naadloos routeren van live clientverkeer en het beheren van rolling upgrades van het besturingssysteem over identieke instanties je belangrijkste ontwerpdrijfveren.

Wanneer Compute Fleet gebruiken

Omgekeerd komt Compute Fleet het best tot zijn recht als je belangrijkste uitdaging het verkrijgen van enorme hoeveelheden rekenkracht is voor asynchrone, batchgerichte of onafhankelijke taken. Typische scenario's zijn high-performance computing-clusters, batchverwerking in de financiële sector, moleculaire modelsimulaties, grootschalige data-ingestiepijplijnen, geautomatiseerde testsuites, renderfarms voor media en tijdelijke werkpools. In deze architecturen pakt een worker een afzonderlijke werkeenheid op, verwerkt die, schrijft de uiteindelijke output naar persistente opslag en gaat direct door met de volgende taak. Als een worker wegvalt, wijst het systeem die werkeenheid simpelweg toe aan een andere beschikbare node.

Je kunt beide gebruiken

Het mooiste aan moderne cloudarchitectuur is dat je niet hoeft te kiezen voor één tool. Azure Compute Fleet en Virtual Machine Scale Sets sluiten elkaar niet uit; ze kunnen binnen hetzelfde bedrijfsecosysteem harmonieus samenwerken. Zo kan een geavanceerde bedrijfsapplicatie een Virtual Machine Scale Set gebruiken voor de webfrontend en API-laag met hoge beschikbaarheid, zodat gebruikers een vlekkeloze ervaring hebben. Tegelijkertijd kan diezelfde applicatie op de achtergrond een Azure Compute Fleet opstarten om zware nachtelijke datawarehousing, batchrapportage of complexe simulaties af te handelen. Door voor elke laag de juiste tool te kiezen, bouw je een architectuur die zowel uitstekend reageert op gebruikers als kosteneffectief is op schaal.

Wil je nog dieper ingaan op deze architecturen en praktische implementatietips horen? Luister dan zeker naar onze volledige begeleidende podcastaflevering: Azure Compute Fleet – Simply Explained. Vergeet niet onze show te steunen en blijf op de hoogte voor meer deep dives in cloud engineering!

Word supporter van deze podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.