In de afgelopen jaren zijn Docker en containers in het algemeen, steeds populairder geworden. Maar wat zijn containers? En waarom zijn ze de afgelopen jaren steeds meer omarmd?
Laten we eerst eens kijken wat er voor containers was. In het begin werden er bij IT organisaties voor verschillende applicaties verschillende servers geïnstalleerd.
Dat werkte op zich, maar de verdeling van resources (CPU, geheugen) was niet mogelijk. Zette je meerdere applicaties bij elkaar op een server om de resources te delen, dan gingen drukke applicaties met elkaar in competitie. Je had geen vat erop welke applicatie die strijd won.
Dus toen kwamen bedrijven als VMWare en later Oracle met VirtualBox met het concept van de virtuele machine. Nu kon je iedere applicatie in zijn eigen virtuele machine zetten en die bepaalde resources toekennen. Zo’n virtuele machine ziet er, als je er mee werkt, ook echt uit als een machine waarop je aan logt. Je installeert eerst een operating system, dan al je libraries en andere afhankelijkheden en vervolgens je applicatie. Tot zover gaat het goed. Maar om die hele infrastructuur te laten werken, inclusief het OS van elke afzonderlijke virtuele machine, zijn ook resources nodig.
Daarnaast bleek steeds meer dat het werken aan een applicatie op virtuele machines leidde tot langere release cycli. Omdat heel veel verschillende teams iets doen op dezelfde virtuele machine. Zo’n steeds grotere applicatie waar veel verschillende teams aan werken, wordt een monoliet genoemd. En waarom werkt de applicatie nu opeens niet meer? Was het afdeling A, B of C?
Als je op Internet zoekt wat de voordelen van Docker zijn, dan komt altijd dat vergelijkende grafiekje om de hoek kijken waarbij wordt getoond dat je op virtuele machines ieder een OS moet installeren, maar dat op Docker containers het OS geïnstalleerd wordt in de lagen eronder. Dat impliceert dat containers op die manier efficiënter omgaat met resources. En dat is ook zeker het geval. Maar nog een veel groter voordeel is dat applicatie bouwers zich alleen maar bezig hoeven te houden met hun applicatie en niet met het OS.
Organisaties bedachten zich al gauw dat het misschien niet meer nodig was om een hele grote applicatie ineens te bouwen. In plaats daarvan zag je dat verschillende teams in hun eigen containers aan hun eigen deel van de applicatie werken. Die verschillende “microservices” kunnen dan vervolgens met elkaar data uitwisselen via API’s of software, zoals Kafka. Het voordeel is dat niet iedereen meer op elkaar hoeft te wachten om die hele applicatie uit te rollen. Het team dat werkt aan de betalingen module levert misschien elke 2 weken een update, terwijl het team dat aan de productencatalogus werkt om de 4 weken een update levert. En de makers van de frontend, de app, leveren misschien wel elke drie weken een nieuwe versie.
Zo’n container maak je op basis van een image, een blauwdruk voor je container, zeg maar. En een van de meest onderschatte veranderde werkwijzen met containers is volgens mij dat ze immutable geacht worden te zijn. Dit is misschien niet zo zeer een feature, als een manier van werken die met containers makkelijker geworden is. Vooral omdat images een soort “infrastructure as code” geworden zijn. Je image is een lijstje van dingen die geïnstalleerd moeten worden. De image van programmeertaal A van Docker Hub halen, library B kopiëren, directory C maken, bestand D plaatsen, enzovoort. Dat lijstje kun je dus heel goed in een versiebeheersysteem plaatsen. Wat met virtuele machines al een stuk lastiger is.
En als je dat lijstje, je Dockerfile dus, netjes in een versiebeheersysteem bijhoudt en je komt niet meer aan je draaiende containers (immutability dus), dan kun je bij problemen veel makkelijker terugvallen op versies van je image die die problemen niet hadden. Je bent dus flexibeler met uitrollen, maar ook met terugdraaien van eventuele fouten. Koppel dit aan een Continuous Integration/Continuous Deployment systeem en die nieuwe versies worden ook nog eens extra gecontroleerd en alleen uitgerold als ze bepaalde tests doorstaan. Je hebt nu een pipeline die applicaties produceert.
En dat is volgens mij de echte deal met Docker: je infrastructuur is code geworden, waarop versiebeheer bijgehouden kan worden, waardoor je flexibel vooruit en terug kan.
In onze Certified Data Engineering Professional cursus gebruiken we Docker heel vaak voor het opzetten van onze cursus omgevingen.
DIKW Intelligence
Wattbaan 1
3439 ML Nieuwegein