Geschreven door Danielle van Boxtel, Marketing Consultant bij Axians.

Steeds meer bedrijven en organisaties investeren in containers. In mijn vorige blog legde ik aan de hand van een metafoor (het containerschip) uit dat containers een middel zijn om software applicaties snel en veilig te schalen en te verplaatsen. De applicatie wordt als het ware in een eigen afgesloten omgeving geplaatst die volledig los van zijn omgeving kan functioneren. En net zoals echte zeecontainers, kunnen software containers ook als een zelfstandige unit in zijn geheel verplaatst worden. Een heel groot voordeel.

Containers blijken dus heel populair te zijn. Maar wat betekent dat voor de klassieke ESB en virtual machines? Behoren die dan tot het verleden? Deze vragen kwamen al snel bij mij op toen ik mij ging verdiepen in containerplatformen. Tijd dus om met mijn collega Jacob Hoeflaken, technology leader bij Axians, in gesprek te gaan. Met Jacob heb ik alle voor- en nadelen op een rijtje gezet, zodat je – indien nodig – de juiste keuze kunt maken voor jouw organisatie!

Een klassieke ESB versus containers

Op het gebied van integratie wordt er steeds vaker gebruik gemaakt van containers en dan vooral in combinatie met wat ze noemen de micro-services architectuur. Bij een klassieke ESB draaien er meerdere koppelvlakken binnen één omgeving. De services maken allemaal gebruik van centrale diensten die door het ESB-platform geleverd worden, zoals logging, monitoring, queueing, etcetera. Dit maakt het beheren en monitoren van de koppelvlakken eenvoudig. Nadeel is echter dat als één van de koppelvlakken zich misdraagt dit invloed kan hebben op de werking van de andere koppelvlakken. Eén specifiek koppelvlak kan alle resources van de ESB pakken of zelfs onderuit halen, waardoor andere koppelvlakken niet performen of ook stoppen met werken.

Bij een micro-services architectuur wordt elk koppelvlak in een eigen lichtgewicht container geplaatst, een soort micro ESB. Elke koppelvlak (service) kan dus volledig los van andere koppelvlakken opereren. Als een koppelvlak in een micro-services architectuur zich misdraagt heeft dat alleen gevolgen voor het betreffende koppelvlak; de overige koppelvlakken die in hun eigen container draaien hebben daar in principe geen last van. Nadeel is dat zaken zoals centrale monitoring, configuratie en logging lastiger zijn om te implementeren. Daarom wordt vaak gebruik gemaakt van containerplatformen zoals Docker, Kubernetes en Openshift die dan functionaliteit bieden om dit ‘out of the box’ in te richten.

Het gebruik van containers en de micro-services architectuur maakt het ook makkelijker om op en af te schalen. Bij een klassieke ESB worden alle koppelvlakken op of afgeschaald terwijl bij een micro-services architectuur op basis van containers je de individuele koppelvlakken kunt op of afschalen.

Virtual machines versus containers

Op het eerste gezicht lijkt dit niet nieuw: virtual machines bieden immers dezelfde soort functionaliteit. Toch zijn er fundamentele verschillen tussen virtual machines en containers. Je zou een virtuele machine ook als een soort container kunnen zien, alleen is deze veel groter in omvang en daardoor moeilijker te verplaatsen. Bij een virtuele machine maakt het operating systeem namelijk ook onderdeel uit van de container zelf. Daarnaast wordt er bij virtuele machines gebruik gemaakt van een zogenaamde hypervisor-laag. Deze hypervisor-laag zorgt voor de aansturing van de benodigde resources, zoals geheugen en storage. Deze hypervisor is nodig omdat elke virtuele machine tegen virtuele hardware praat, maar uiteindelijk natuurlijk wel op de echte onderliggende hardware terecht moet komen. Dit zorgt dus ook voor extra overhead.

Bij containers zoals Docker is dit niet het geval. De containers bevatten een minimaal operating systeem en maken direct gebruik van de hardware van de host waardoor er minder overhead is. Een ander groot verschil is dat de zogenaamde ‘images’ bij bijvoorbeeld Docker incrementeel zijn. Een image beschrijft hoe een container opgeslagen wordt op storage. Als je twee virtuele machines maakt, dan bevatten de images voor deze virtuele machines ook allebei het operating systeem. Ze bevatten dus bijvoorbeeld allebei een complete Windows Server 2012 R2 installatie.

Bij Docker is dit niet het geval. Je hebt dan één operating systeem image en de andere twee images verwijzen naar deze operating systeem image en bevatten verder alleen de wijzigingen bovenop het operating systeem. De Docker images zijn daardoor ook veel kleiner en veel gemakkelijker te verplaatsen. Een Docker image vereist dan ook veel minder resources. Op dezelfde hardware kun je veel meer Docker containers draaien dan virtuele machines. Toch zijn containers geen vervanging van virtuele machines. Beiden hebben hun bestaansrecht en vaak worden ze ook samen gebruikt (het containerplatform draait dan bijvoorbeeld op één of meerdere virtuele machines).

Containers maken devops echt mogelijk

Containers en containerplatformen maken het zogenaamde DevOps echt mogelijk, met name door CI/CD. CI staat voor continuous integration en CD voor continuous delivery of continuous deployment. DevOps (Development & Operations) is een filosofie die zich richt op het verbeteren van de samenwerking tussen developers & operations.

Het grote verschil tussen een klassieke ESB en containers is dat bij containers de aanpassingen in een koppelvlak altijd direct en automatisch getest en gedeployd worden. Dit gebeurt door het automatisch in de lucht brengen van containers met de aangepaste software en deze nieuwe software vervolgens automatisch te testen. Als de software wordt geaccepteerd wordt de container vervolgens in zijn geheel gepromoveerd tot een productie-instantie.

Dit is dus heel anders dan bij de klassieke ESB. Hier worden de koppelvlakken door de gehele OTAP (ontwikkeling, test, acceptatie en productie) gehaald en dus telkens opnieuw geïnstalleerd. Hier ontstaat het risico dat zaken toch niet werken zoals verwacht, omdat de omgevingen toch van elkaar blijken te verschillen of er fouten worden gemaakt bij de (her)installatie. Bij CI/CD in een container platform wordt de complete container door de OTAP getrokken. Het koppelvlak hoeft dus niet telkens opnieuw te worden geïnstalleerd en je weet ook zeker dat het koppelvlak altijd in dezelfde omgeving draait.

Red Hat OpenShift

Wanneer het gaat om containerplatformen dan werken wij bij Axians samen met Red Hat. OpenShift is het containerplatform van Red Hat en is gebaseerd op Kubernetes open source projecten. OpenShift biedt extra ondersteuning voor het gecentraliseerd loggen en monitoren van containers en daarmee de koppelvlakken in die containers. OpenShift heeft ook een gebruikersvriendelijke webgebaseerde console die door beheerders en developers gebruikt kan worden voor het aanmaken, monitoren en beheren van containers.

Meer informatie?

Wil je meer weten over wat containers of Red Hat OpenShift voor jouw organisatie kan betekenen? Neem dan contact op met één van onze experts, zij vertellen je er graag meer over. Mailen kan ook: wilfred.douden@axians.com.