Allemaal zouden we wel eens in de toekomst willen kijken. Zelf zou ik de ontwikkeling van containerisatie bij bedrijven graag eens door een glazen bol willen bewonderen. De hype is inmiddels gaan liggen en de innovaties schieten als paddenstoelen uit de grond. Wat kun je als organisatie eigenlijk met het concept? En waar begin je aan?
Niet elke organisatie is gebaat bij het gebruik van containers. Zo is het voor de bakker om de hoek minder interessant dan voor een groot kantoor dat veel gebruikmaakt van verschillende soorten software en systemen. De populatie van bedrijven die ‘fully containerized’ zijn, is nog niet erg groot, maar wel gigantisch aan het groeien. De groei van vooral schaalbare ‘cloud native’-applicaties is interessant. Deze beweging vergroot de noodzaak voor een nieuwe applicatie-architectuur. Hierbij is een nauwe samenwerking van developers en ict-afdelingen van groot belang. Het herontwerpen van een infrastructuur moet je immers niet te licht opvatten. Operationeel komen er flink wat uitdagingen naar voren. Maar waar begin je als organisatie als je gebruik wilt maken van containerisatie? Ga eens in gesprek met de it-afdeling om te achterhalen waar bij jullie de valkuilen in de infrastructuur zitten. Aan de hand hiervan kun je gerichter op zoek gaan naar hoe je de infrastructuur moet herinrichten.
Dirigeren
Een orkest heeft een dirigent, een container heeft een container orchestration framework. Het platform is anders, hierdoor moet er ook anders naar de architectuur, de manier waarop de infrastructuur schaalt en de structuur van de algehele omgeving gekeken worden. De tools van een orchestration framework hebben als doel een kader te bieden en het beheer van de containers te vereenvoudigen en deels te automatiseren. Met het framework zorg je dat als er opgeschaald of afgeschaald wordt, je alle extra of juist minder containers kan ‘aanspreken’ door middel van een dirigent. De dirigent managed de levenscyclus van de containers, aan de hand van de specificaties die in het defenitiebestand van de container vastgelegd zijn. Hoe groter en dynamischer de applicatie, des te belangrijker de dirigent.
Uiteraard is het ook voor softwareteams van belang gebruik te maken van het orchestration framework, hiermee zijn niet alleen taken te controleren maar ook te automatiseren. Denk bijvoorbeeld eens aan de redundantie en beschikbaarheid van containers, het op- of afschalen van het aantal containers of het verplaatsen van containers tussen verschillende locaties. Maar ook het verdelen van de middelen tussen en in containers kun je monitoren door middel van het orchestration framework.
Omdat het gebruik van een orchestration framework bij een container-setup al snel nodig is, is de keuze die je daar maakt belangrijk. Er zijn daar verschillende keuzes te maken, met voor elk framework weer verschillende voordelen en nadelen.
Frameworks
Het meest populaire framework is Kubernetes (‘k8s’), een framework dat is ontwikkeld door Google en intern ontwikkeld voor het managen van containerplatforms aldaar. Dat platform is vrijgegeven en kan door iedereen gebruikt worden. Kubernetes is – zoals veel (ex) Google-producten – uitgebreid en kan daardoor complex zijn. Wel is het zo’n beetje ‘de standaard’ en vaak praten mensen eerder over het gebruik van ‘k8s’, dan over containers zelf.
Docker Swarm is een iets jonger alternatief dat bij Docker zelf is ontwikkeld. Docker Swarm is eenvoudiger, bevat daardoor wat minder functionaliteiten, maar is door de integratie met de standaard Docker-toolset makkelijker op te pakken door teams die al Docker-ervaring hebben.
Docker Swarm en Kubernetes zijn slechts twee alternatieven voor container-orchestratie. Sommige organisaties bouwen hun eigen oplossingen en verschillende open-source en commerciële organisaties liften graag mee op de groei van containerisation en bieden alternatieven aan.
Maak je geen gebruik van een dirigent, weet een muzikant wellicht wel welke noten er gespeeld moeten worden, maar niet in welk tempo om het tot muziek te laten klinken in plaats van een kakafonie. Bij containers werkt dit net zo, is je automatisering niet op orde? Dan ontstaat er chaos zoals bij een symfonieorkest zonder dirigent.
Architectuur
De technologie achter de container blijft van groot belang. Het toevoegen van een abstractielaag is het toevoegen van complexiteit aan de infrastructuur. De architectuur moet kloppen voor jouw organisatie. Gaudí of Berlage, compleet andere bouwstijlen, maar toch klopt het binnen de context. Containers kunnen op bare metal draaien, of in de cloud, en op verschillende platformen/frameworks worden uitgerold. Die keuzes hangen af van het doel en de eisen van de applicatie(s). De ene container is de andere niet en of je kiest voor de implementatie van bestaande containers of dat je zelf de software van de containers wilt gaan herstructureren, zorg dat het klopt.
Wees je daarbij wel bewust van de veiligheid van je infrastructuur. Containers hebben geen beveiliging ingebouwd. De keuze voor een orchestratie-framework heeft hier nauwelijks invloed op. Er zijn initiatieven om container-platformen (en containers onderling) meer te beveiligen, maar feit blijft dat in een container-landschap niet alleen anders moet worden nagedacht over architectuur, maar zeker ook over het veilig stellen en houden van applicaties en data.
Toekomst
Inmiddels zijn we denk ik, de hype voorbij en is het tijd om ons op de toekomst te richten met het gebruik van containers. Wat voor de bakker op de hoek werkt en dus kloppend is, is dat voor een groot kantoor vaak niet zo. Voor veel bedrijven zal containerisatie een grote (interne)verandering zijn waarbij de architectuur prachtig kan worden, mits er een goede dirigent aan het hoofd staat. Helaas heb ik nog steeds geen glazen bol in mijn bezit; ik kijk met veel interesse naar de toekomst als het op containerisatie aankomt.
