Docker containers vs. VM's; wat zijn de verschillen?

Tegenwoordig overstemmen de berichten en verhalen omtrent Docker en Kubernetes de verhalen over Virtuele Machines (VM’s), hypervisors en andere meer “traditionele” technieken. De reden hiervan is ook eenvoudig; VM’s en hypervisors zijn in feite de voorvaderen van technieken zoals Docker en Kubernetes, maar wat is het verschil nu precies en waarom zou je willen overstappen van een infrastructuur bestaande uit VM’s naar Containers met behulp van Docker?

Geschiedenis

VM’s en hypervisors waren de disruptors in het tijdperk dat applicaties en infrastructuur niet gevirtualiseerd werden. Dit houdt in dat er indertijd geen techniek bestond welke een server in meerdere virtuele servers kon opknippen; het zogenaamde "bare metal" draaien. Met de komst van bijvoorbeeld VMware waren er ineens talloze voordelen om de “bare metal” servers op te knippen in kleinere VM's en hier zelfs in een later traject de meer technische termen zoals host failover en high available oplossingen vrij gemakkelijk voor handen waren om je infrastructuur zo betrouwbaar en weerbaar mogelijk op te kunnen bouwen, tegen een fractie van de kosten die je zou hebben gehad bij dezelfde "bare metal" opzet.

Vergelijking

Docker is een Container gebaseerde technologie, wat in feite inhoudt dat het verder reikt dan een VM, deze zou namelijk ook nog eens verpakt kunnen worden in kleinere verpakkingen. Deze verpakkingen (de containers) kunnen onafhankelijk van elkaar op één systeem (zoals een VM) draaien. Het is dus een laag extra bovenop de virtualisatielaag (VM), dit noemen we dan ook gemakshalve de containerlaag (Docker). Er zijn diverse analogieën over een vergelijk tussen Containers en VM’s, de volgende is misschien wel het meest beschrijvend: Een Container zou je kunnen zien als een appartement, met gedeelde faciliteiten, nutsvoorzieningen, en belangrijk: een VVE waarin het onderhoud van 90% van het gebouw en het appartement all-in wordt opgenomen en je hiervoor wordt ontzien. Een VM zou je daarentegen kunnen vergelijken met een vrijstaand huis, je moet hiervoor alle faciliteiten en nutsvoorzieningen zelf regelen, ook zou je moeten zorgdragen voor tijdig onderhoud van het huis en tuin en alle andere bijzaken. De daadwerkelijke analogie moet hierin nog komen: het enige wat je in feite verlangt is een plaats waar je kan eten, drinken, slapen en je kleren kunt hangen zonder dat je je zorgen hoeft te maken over het onderhoud van het huis, tuin, et cetera.

Gebruik

Een VM of Container wordt hoofdzakelijk gebruikt voor het draaien van een (bedrijfs-)applicatie. In het geval van een VM kunnen dit desgewenst meerdere applicaties of services zijn, dit vanwege de extra overhead ten opzichte van een Container zoals in vorig hoofdstuk is uitgedrukt in de vorm van een analogie. Vanwege de eigenschappen dat Containers meer delen met het host besturingssysteem dan VM’s en dus ook veel kleiner verpakt kunnen worden, biedt dit veel voordelen in infrastructuren waar applicaties eenvoudig los van elkaar gedraaid en gefinetuned kunnen worden. Dit is dan ook weer een hele goede aanjager om de DevOps methologie verder door te voeren, verantwoordelijkheden verschuiven hierin steeds meer in elkaar aangezien een Docker Container definitie uiteindelijk naast de applicatie codebase “leeft”. Onderhoud en ontwikkeling gaan dan ook gemakkelijk hand in hand.

Evolutie en “cattle not pet”

Allereerst is het wel zaak om te benadrukken dat VM’s een uitstekende vooruitstrevende technologie waren. Nog steeds kan het voorkomen dat VM’s voor bepaalde doeleinden beter geschikt zijn dan (Docker) Containers, bijvoorbeeld wanneer Active Directory domain controllers gedraaid moeten worden vanwege de specifieke configuratie, additionele complexiteit en de “cattle not pet” methologie op domain controllers helaas nog niet ideaal toepasbaar zijn. Echter, met de komst van Docker en Containers in zijn algemeenheid is de “cattle not pet” methologie zeer gemakkelijk toepasbaar geworden, wat inhoudt dat je een Container als dierlijk vee moet behandelen en niet zozeer als huisdier, en dus ook gemakkelijker uitwisselbaar is met een soortgelijke Container. Dit zou je graag zo snel mogelijk willen bewerkstelligen als er een Container onwel is geworden of een update / upgrade wenselijk is.Container technologie is dus een evolutie van VM-technologie, daar waar de VM-technologie voorheen weer een evolutie was van de bare metal installaties.

Voordelen Containers

Vanwege deze eigenschappen van Containers, waaronder dus de kleinere “slimmere” manier om de kernel en libraries van het host besturingssysteem te gebruiken, maar nog steeds met genoeg isolatie tussen de host en de Container (de zogenaamde "guest" in VM-terminologie), is het een zeer interessant alternatief om de oudere, loggere en moeilijker te vervangen VM’s te herpakken in meerdere (Docker) Containers om de (kritische) bedrijfsapplicaties op te draaien. Hiermee wordt het dus gemakkelijker om mogelijkerwijs te migreren naar bijvoorbeeld een microservice architectuur aangezien die stap dan veel kleiner is dan dat men direct vanuit VM’s met veelal monolitische applicaties moet migreren. Ook – zoals eerder aangegeven – is het aanjagen van de DevOps methodologie hierin een groot voordeel ten opzichte van de vorige generatie VM infra- en architectuur. Tot slot worden hiermee de infrastructuur en IT-management resources aanzienlijk minder vanwege een nog lagere overhead, kleinere images/snapshots en snellere opstarttijden van applicaties, verlaging en versimpeling van de (security) updates.

CONTACT

DevOps Rebels BV

Europalaan 100

3526 KS  UTRECHT

(t)   +31 (0) 85 208 2805

(m) info@devopsrebels.com

JURIDISCH

Privacy Verklaring 

Algemene Voorwaarden

(KvK) 67206565

SOCIAL

  • Ollos op LinkedIn
  • Twitter Social Icon

© 2020 DevOps Rebels B.V.