Simulatie, emulatie, virtualisatie en containers: de restaurant-metafoor

“Dus wat is het verschil tussen een container en een virtual machine?”

Ik krijg deze vraag vaak, meestal van iemand die slim genoeg is om in vergaderingen mee te knikken zonder toe te willen geven dat het vaag is. En het eerlijke antwoord is dat de meeste uitleg het erger maakt. Die gooit in de eerste zin al “hypervisor,” “kernel sharing,” en “hardware abstractie” op tafel, en nu heeft die persoon vier nieuwe termen om over in de war te zijn in plaats van één.

Achter de container-versus-VM-vraag zit een diepere: wat is nou echt het verschil tussen simulatie, emulatie, virtualisatie en containerisatie? Mensen gooien die vier voortdurend op één hoop. Het zijn vier verschillende antwoorden op hetzelfde probleem, namelijk iets draaien in een omgeving waarvoor het nooit is ontworpen.

Dat onderscheid kan me schelen omdat ik wil begrijpen wat ik draai. Als je niet kunt zeggen welke van deze vier een tool doet, kun je niet redeneren over de performance, de isolatie, of wat er stukgaat als het omvalt. Dus laat ik de hele set uitleggen op de manier die het bij mij eindelijk liet beklijven: met restaurants.

De restaurant-metafoor

Stel je voor dat je Japans wilt eten. Je hebt vier opties:

1. Simulatie: de kookshow

Je kijkt naar een Japanse kookshow. De chef demonstreert hoe je sushi maakt, legt de technieken uit, laat zien hoe ingrediënten worden gesneden en geassembleerd. Je kunt alles zien wat er zou gebeuren als je in een Japans restaurant zou eten.

Maar je eet niks. Er is geen echt eten. Wat je hebt is een model van de ervaring. Prima om te begrijpen, nutteloos tegen honger.

Dat is simulatie: je bouwt een model van iets om te bestuderen hoe het zich gedraagt, en je draait nooit het echte ding.

In technische termen modelleert een vluchtsimulator hoe een vliegtuig zich gedraagt. Geweldig om piloten te trainen, en er zit nergens in de keten een echt vliegtuig. Een circuitsimulator doet hetzelfde voor elektronische componenten: hij voorspelt hoe ze zich zouden gedragen, met nul echte elektronica op de werkbank. Het draait om de voorspelling, niet om het ding zelf.

2. Emulatie: het Japanse restaurant in Amsterdam

Je gaat naar een Japans restaurant in Amsterdam. De Nederlandse chef heeft authentieke Japanse technieken geleerd. Ze importeren Japanse ingrediënten. Ze hebben de Japanse keukenapparatuur nagebouwd. Ze serveren het eten op Japans aardewerk.

Alles is ontworpen om zich precies te gedragen als een Japans restaurant in Tokyo. Goed gedaan is het resultaat nauwelijks te onderscheiden van het echte: dezelfde smaak, dezelfde presentatie, dezelfde ervaring.

Maar je staat nog steeds in Amsterdam. Het geheel is één systeem dat trouw doet alsof het een ander systeem is, door elk detail van hoe het origineel werkt na te bootsen.

Dat is emulatie: je laat één systeem zich precies gedragen als een ander systeem door het gedrag in software te repliceren.

In technische termen draai je een Game Boy emulator op je laptop. De laptop heeft nergens binnenin Game Boy hardware, dus de emulator software staat in voor elk Game Boy component: de CPU, de grafische chip, de geluidschip. De games merken het niet. Ze geloven oprecht dat ze op een echte Game Boy draaien, en ze draaien echt, niet als model.

3. Virtualisatie: het hotelrestaurant

Je verblijft in een hotel met meerdere restaurants onder één dak: Japans, Italiaans, Frans, Indiaas. Elk draait op zichzelf. Aparte keukens, aparte chefs, aparte menu’s.

Wat ze delen is het gebouw zelf: de elektriciteit, het water, de ventilatie, het schoonmaakpersoneel. Het hotelmanagement deelt de resources uit en bepaalt hoeveel ruimte, stroom en personeel elk restaurant krijgt.

Elk hiervan is een echt, volledig werkend restaurant. Geen ervan doet alsof het iets anders is. Ze splitsen alleen de onderliggende infrastructuur efficiënt.

Dat is virtualisatie: je draait meerdere complete besturingssystemen op één set hardware, met een dunne laag eronder die de resources uitdeelt.

In technische termen draai je Windows en Linux tegelijk op één fysieke server. Elk krijgt zijn eigen volledige besturingssysteem, en ze delen de CPU, het geheugen en de opslag. De hypervisor speelt hier hotelmanagement en houdt ze uit elkaars vaarwater.

4. Containers: de food court-keuken

Je gaat naar een food court. Eén grote keuken achterin, en een stel verkopers die hem delen. Dezelfde ovens, dezelfde werkbladen, dezelfde koelkasten.

Elke verkoper houdt zijn eigen sectie: zijn eigen ingrediënten, zijn eigen recepten, zijn eigen pannen en potten. De sushi-verkoper kan niet in de mise en place van de pizza-verkoper graaien. Ze zitten van elkaar afgeschermd terwijl ze de keuken zelf delen.

Dat is goedkoper dan elke verkoper een hele aparte keuken bouwen. Het enige wat een verkoper echt nodig heeft is zijn eigen spullen, de ingrediënten en het gereedschap specifiek voor zijn eten.

Dat is containerisatie: applicaties draaien in geïsoleerde ruimtes bovenop één gedeelde besturingssysteem kernel, elk met hun eigen dependencies en libraries.

In technische termen, Docker containers op een Linux server. Elke container heeft zijn eigen bestandssysteem, zijn eigen geïnstalleerde packages, zijn eigen app. Ze delen allemaal één Linux kernel. De container runtime speelt food court-management en houdt iedereen in zijn baan.

Vergelijkingstabel

Wanneer wat gebruiken

Simulatie

Gebruik wanneer:

• Je gedrag wilt begrijpen of voorspellen zonder het echte ding te draaien
• Testen gevaarlijk, duur of onmogelijk is (kernreactoren, ruimtemissies, epidemieën)
• Je iets ontwerpt dat nog niet bestaat

Gebruik niet wanneer:

• Je echte resultaten nodig hebt, niet gemodelleerde resultaten
• Je echte software moet draaien

Voorbeelden:

• Weermodellering
• Vluchtsimulatoren
• Circuit design tools
• Financiële modellering
• Fysica simulaties

Emulatie

Gebruik wanneer:

• Je software moet draaien van een compleet ander platform
• De originele hardware verouderd, zeldzaam of niet beschikbaar is
• Exacte gedragsreplicatie belangrijker is dan snelheid

Gebruik niet wanneer:

• Performance ertoe doet (emulatie is traag)
• Je virtualisatie kunt gebruiken (veel sneller)

Voorbeelden:

• Oude console games draaien (SNES, PlayStation)
• ARM software op x86 draaien (Apple Rosetta 2)
• Legacy software behouden wanneer hardware overlijdt
• Mobiele app development (Android emulator)

Virtualisatie

Gebruik wanneer:

• Je meerdere verschillende besturingssystemen op één machine moet draaien
• Volledige isolatie tussen omgevingen vereist is
• Je een ander OS moet draaien dan je host (Windows op Linux, etc.)
• Elke omgeving verschillende kernel versies nodig heeft

Gebruik niet wanneer:

• Al je workloads hetzelfde OS gebruiken (containers zijn efficiënter)
• Maximale performance kritiek is
• Resources erg beperkt zijn

Voorbeelden:

• Windows en Linux op dezelfde server draaien
• Development omgevingen die matchen met productie
• Testen op verschillende OS versies
• Multi-tenant hosting met volledige isolatie

Containers

Gebruik wanneer:

• Alle workloads dezelfde OS kernel kunnen delen
• Je lichtgewicht, snelle isolatie nodig hebt
• Je veel vergelijkbare applicaties deployt
• Resource-efficiëntie belangrijk is
• Snelle opstarttijden ertoe doen

Gebruik niet wanneer:

• Je een ander OS moet draaien (kan geen Windows containers op Linux kernel draaien)
• Je absolute security isolatie nodig hebt (VMs zijn meer geïsoleerd)
• Je software kernel modificaties vereist

Voorbeelden:

• Microservices architecturen
• CI/CD pipelines
• Lokale development omgevingen
• Kubernetes workloads
• Web applicaties schalen

De gelaagde realiteit

In de praktijk worden deze technologieën vaak gecombineerd:

flowchart TD
    subgraph layers["Technologie Lagen"]
        App["Jouw Applicatie<br/>(Container)"]
        Runtime["Container Runtime<br/>(Docker/containerd)"]
        GuestOS["Guest OS - Linux<br/>(Virtual Machine)"]
        Hypervisor["Hypervisor<br/>(Virtualisatie)"]
        HostOS["Host OS"]
        Hardware["Fysieke Hardware"]
        App --> Runtime
        Runtime --> GuestOS
        GuestOS --> Hypervisor
        Hypervisor --> HostOS
        HostOS --> Hardware
    end

Je zou containers kunnen draaien in virtual machines in fysieke servers. Elke laag kost je wat overhead en levert je capaciteit en isolatie terug. Goed om te weten welke ruil je op welk niveau maakt.

Cloud providers stapelen het precies zo, constant. Jouw “server” is een VM op hun hardware, en je draait je containers in die VM. Die gelaagdheid is precies waarom ik dit onderscheid wil snappen: als de latency piekt, wil ik weten van welke verdieping van dat gebouw het kwam.

Veelvoorkomende verwarring

“Docker is een virtual machine”

Nee. Docker containers delen de kernel van de host, VMs nemen hun eigen mee. Dat ene verschil is waarom een Docker container in seconden start zonder kernel om te booten, terwijl een VM minuten nodig heeft om op te komen.

“Emulatie is gewoon trage virtualisatie”

Nee, ze lossen verschillende problemen op. Emulatie vertaalt één architectuur naar een andere (Game Boy → PC). Virtualisatie draait dezelfde architectuur efficiënter (x86 → x86).

Een PC virtualiseert Linux op Linux zeer efficiënt. Maar hij moet een Game Boy emuleren, want er is nergens Game Boy hardware om überhaupt te virtualiseren.

“Containers zijn veilige isolatie”

Gedeeltelijk. Containers geven je proces isolatie, maar ze delen een kernel. Een kernel kwetsbaarheid kan een container escape worden. VMs isoleren harder, juist omdat ze die kernel niet delen.

Voor high-security of untrusted workloads pak ik nog steeds VMs. Voor het meeste wat ik draai zijn containers prima, en die keuze maak ik bewust in plaats van standaard.

“Simulatie en emulatie zijn hetzelfde”

Nee. Simulatie modelleert gedrag bij benadering. Emulatie repliceert gedrag exact.

Een vluchtsimulator simuleert vliegtuigfysica om te voorspellen en te trainen. Een Game Boy emulator kopieert het exacte hardwaregedrag, en de games erop draaien echt.

Afronden

De volgende keer dat iemand je vraagt deze uit te leggen, grijp naar het eten:

• Simulatie: een kookshow. Je ziet wat er zou gebeuren, er draait niks echt.
• Emulatie: een Japans restaurant in het buitenland. Een volledige kopie van hoe iets anders werkt.
• Virtualisatie: hotelrestaurants. Echte, complete, geïsoleerde keukens die één gebouw delen.
• Containers: een food court. Geïsoleerde verkopers die één keuken delen.

Elk verdient z’n plek. Simulatie als je iets wilt modelleren zonder het te draaien. Emulatie als je vreemde software moet draaien op hardware die er nooit voor bedoeld was. Virtualisatie als je echt verschillende besturingssystemen naast elkaar nodig hebt. Containers als je veel vergelijkbare apps wilt draaien zonder per stuk voor een heel OS te betalen.

De reden dat ik dit uit elkaar houd is geen muggenzifterij. Weten welke je draait vertelt je wat je kunt verwachten als het stukgaat, en dat is waar het bij infrastructuur die je echt zelf bezit om draait. Nu kun je het aan iedereen uitleggen, zonder hypervisor-vocabulaire.