Vandaag de dag zijn er genoeg trends waarvan je je afvraagt of ze iets toevoegen of dat het slechts buzzwoord zijn. Laten we eens verder inzoomen op betekenis van het woord ‘container’. Dan heb ik het niet over vuilcontainers of de containers in de Waddenzee, maar de containers in de wereld van it. Wat is het precies en hoe werkt het?
De Dikke van Dalen omschrijft ‘container’ als ‘iets dat iets kan bevatten’ of als ‘metalen laadbak van standaardafmetingen’. Uiteraard wil ik het over de eerste hebben. Een aantal blogs geleden had ik het over abstractielagen van een infrastructuur. Containers zijn precies zo’n abstractie-laag in een infrastructuur. In een container zitten eigenlijk alle afhankelijkheden van de software; de code, de ondersteunende tools, en de runtime. Hierdoor kunnen verschillen op het niveau van infrastructuur niet meer voor problemen zorgen, doordat de container alle applicatieplatformen, alle software en alle afhankelijkheden ‘containeriseert’.
Wat zit er in de container?
Door met containers te werken, vergroot je de flexibiliteit van je organisatie. Je kan in no-time namelijk (op)schalen of juist verschuiven. Een container omvat niet alleen de applicatie zelf, maar ook alle randvoorwaarden die nodig zijn om de applicatie te laten draaien. Zie het als een orkest, het container orchestration framework. Elk orkest heeft een dirigent die de muzikanten vertelt hoe ze moeten spelen, waarna ze direct kunnen anticiperen op de wensen van de dirigent. Dit geldt ook voor containers. De hele container is direct naar een andere locatie te vervoeren, waar de applicatie of het applicatie-onderdeel beter kan draaien, of waar meer capaciteit beschikbaar is. Hierdoor is het mogelijk om flexibel en snel uit te breiden door het opschalen van onderdelen van een applicatie, waarbij die onderdelen met elkaar ‘praten’ door middel van api’s. Containers zijn bedoeld voor nieuwe applicaties, het ‘containerizen’ van legacy-applicaties is vaak vooral handig in een migratiescenario, als ‘tussenstap’.
Schoonheid zit vanbinnen
Infrastructuur en architecturen zijn tegenwoordig meer dan fysieke hardware of een server die in een datacenter staat, het kan vandaag de dag ook over locaties in de cloud gaan. Hoe werkt dat met containers? Doordat containers onafhankelijk zijn, maakt het een stuk minder uit op welk platform ze draaien. Neem als voorbeeld een upgrade- of migratie-scenario waarbij een platform moet worden vernieuwd of meer capaciteit toegevoegd moet worden: als dit gebeurt binnen een containerized omgeving, dan is server- of cloudcapaciteit toe te voegen aan het containerplatform, en zorgt de orchestratie-laag ervoor dat de applicatie wordt ‘herverdeeld’ of verplaatst.
De infrastructuur die je als organisatie momenteel gebruikt, gaat in de toekomst hoogstwaarschijnlijk veranderen. Hierdoor is het goed om als it-afdeling nauw samen te werken en te weten waar je aan begint met containerisatie. Vooral de samenwerking tussen developers en de operationele afdelingen zijn van groot belang. Al helemaal omdat het vernieuwen van applicaties die voor de container geschikt zijn, noodzakelijk is. Als je containers gaat opspinnen in grote getallen, wil je dit proces automatiseren (daar ga ik voor het gemak even van uit). Hierdoor word je bijna gedwongen je infrastructuur te gaan omschrijven. Infrastructuur-as-a-code is binnen een containerized omgeving standaard en noodzakelijk – een container wordt immers gedefinieerd door zijn code. Naast het automatiseren van de omgeving zelf, verandert de architectuur van je applicaties, waardoor het vaak nodig is om nieuwe en andere technieken te gebruiken om je applicaties op te bouwen. De scheidslijn tussen ontwikkelaars en ‘beheer’ verschuift daardoor.
Kloppende hart
Zoals al eerder benoemd, is de software en de technologie achter de container van groot belang. Doordat het platform anders is, moet er ook op andere manieren worden nagedacht over de structuur van de omgeving, architecturen, en de manieren waarop infrastructuur schaalt. Klopt die niet, dan is het gebruik van containers niet verstandig. Alles houdt namelijk met elkaar verband. Hierbij is het ook van belang om te weten dat het niet per se veiliger is. Containers hebben namelijk uit zichzelf niets met het beveiligen of vanuit een beveiligingsperspectief opsplitsen van functionaliteiten te maken.
Uiteraard zijn hier tegenwoordig genoeg oplossingen voor. Het gaat bovendien ook niet over beveiliging maar over het schaalbaar en ‘dynamisch’ maken van applicaties.
Veelgehoorde termen
Buzzwoord of toekomst, dat was de vraag. Het begrip ‘containerisatie’ circuleert al sinds 2013 in de it-wereld. De grote vervolgvraag is natuurlijk: wat kun je er als organisatie mee? Graag leg ik je in mijn volgende blog uit wat containerisatie voor een onderneming kan betekenen en geef ik antwoord op de vraag waar te beginnen.
Het ‘inblikken’ van een workload in een container heeft voordelen voor de portabilteit maar nadelen voor het beheer, de verschuivende scheidslijn hierin aangaande de beveiliging is dan ook één van de punten waar ik de volgende keer graag een antwoord op zou willen hebben. Containers worden Trojaanse paarden als de schaalbaarheid boven veiligheid gaat, Huawei containers schijnen vol te zitten met soldaten van het Chinese volksleger.
Roepen dat de (digitale?) infrastructuur die we momenteel gebruiken in de toekomst waarschijnlijk veranderd lijkt me onzin. Eén van mijn eerste opinies die ik op 19 november 2010 hier schreef ging over de veranderde wagonnetjes wat mogelijk tot een aanpassing van stations leidt maar de spoorweg zelf ongewijzigd laat.
Containers communiceren alleen via apis met de buitenwereld.
Dat heeft beheer- en veiligheidsvoordelen.
Tenzij je liever gewoon op je server allerlei software instaleert en je virusscanner vertrouwt.
Alles wat je binnenhaalt zonder op de veiligheid te letten is een potentieel trojaans paard.
Het paard van Troje werd zonder API specificatie en controle binnengesleept.
Hadden ze die nou maar in een container gestopt, waarvan ze de technologie kenden en vertrouwden…
Infrastructuur is misschien niet op hardware niveau veranderd sinds 2010.
Nog steeds servers en netwerken.
Een orkest met containers kun je echter als platform zien, maar net zo goed als infrastructuur.
Net zoals de vraag of een trein met wagons alleen gebruik maakt van de infra of er zelf deel van uitmaakt.
Ligt er maar aan of je het de NS of Arriva vraagt of de reizigers zelf.
Hypervisors met daarin VMs met daarin compute nodes waarin containers draaien…
De basis hardware mag dan niet zoveel veranderd zijn, het gebruik er van wel.
Robert, ik vraag me af voor wie je jouw artikel schrijft. Wie is je doelgroep en wat wil je dat die doelgroep bereikt?
Henri,
Even klikken op het profiel en je vraag wordt beantwoord, de titel ‘Technical evangelist’ bij Leaseweb zou een lichtje bij je moeten doen laten gaan branden. Of dit een blauw zwaailicht is of een rood verkeerslicht laat ik even in het midden.