Met drie experts op het gebied van infrastructuur bespreken we tijdens een lunch bij True wat de voor- en nadelen zijn van containers. We bespreken wanneer je ze inzet, hoe een realistische omgeving er uitziet en wanneer je Kubernetes gebruikt voor orkestratie.

Je moet er één keer goed over nadenken en daarna kun je er vertrouwen in hebben.
Kaj Arne Ruiter, Research & Development manager bij Snakeware, laat direct duidelijk weten hoe hij er over denkt. “Ik ben een groot voorstander van de transitie naar microservices en containers”, zo steekt hij van wal. Microservices leveren minder druk op voor ontwikkelaars, vindt hij. Het fijne van containers is volgens hem dat als je dat goed neerzet, je infrastructuur staat als een huis. “Je moet er één keer goed over nadenken. Daarna moet je ervan afblijven en er vertrouwen in hebben.”
Tot slot wordt met een infrastructuur met containers, in tegenstelling tot een monoliet, het proces heel goed blootgelegd. “Je kunt direct zien waar het fout gaat, waar de bottlenecks zitten en waar zaken verbeterd moeten worden of opgeschaald.”
Microservices om het CMS heen
Maar zo werkt het jammer genoeg niet bij de meeste klanten waar Floris Derksen, CTO van OneShoe, over de vloer komt. Vaak heb je daar nog een klassieke applicatie, zoals bijvoorbeeld Drupal, vertelt hij. Die wordt niet vervangen door microservices, maar eromheen werken die wel erg goed. “Vroeger deed je alles via het CMS, maar nu wordt steeds meer functionaliteit losgetrokken en in microservices gezet. Je gaat de applicatie dus steeds verder ontmantelen, dat zien we bij meerdere opdrachtgevers voorbijkomen.”

Kaj Arne Ruiter: “Ik ben een groot voorstander van de transitie naar microservices en containers”
“Vroeger had het cms natuurlijk een dicterende rol”, voegt Kaj daaraan toe, “terwijl nu de front-end leidend is, want de ervaring van de gebruiker is belangrijk.” Volgens hem hoef je ook alleen maar informatie aan te bieden via het cms, en daar heb je mooie cloud cms’en voor, zoals Prismic en Dato. “Qua hosting heb je daar geen omkijken naar en de API is standaard.”
Daar is Floris het mee eens. “Sommige opdrachtgevers vragen wel eens of Drupal niet in Docker kan, maar dat raden we af. Dan kun je beter iets PaaS-achtigs kiezen. Dan hoef je zelf die hele applicatie niet op te bouwen.”
Authenticatie kan dan bijvoorbeeld weer wel heel goed als microservice, omdat je dat heel makkelijk kunt opschalen. “Als je heel veel bezoekers krijgt, trekken klassieke systemen dat namelijk niet meer. Klassieke applicaties onthouden een sessie, waardoor de database verbonden is met de applicatie. Dat werkt, maar schaalt niet goed”, zo legt Floris uit. “De nieuwe aanpak is dat bij elk request een token meegestuurd wordt, dat vertelt of en hoe je gemachtigd bent. Dat is wél schaalbaar, omdat er geen connectie is met de database.”
Schaalbaarheid of functionaliteit
Maar die nadruk op schaalbaarheid is iets wat Daniël de Groot, teamlead Kubernetes bij True, wil nuanceren. “Als bedrijven moeten kiezen tussen functionaliteit en schaalbaarheid, dan zal vrijwel iedereen kiezen voor functionaliteit”, stelt hij. Volgens hem hebben maar heel weinig partijen echte schaalbaarheid nodig. “Iedereen heeft het er wel over als groot voordeel van containers, maar het is volgens mij veel belangrijker dat je met containers veel minder technische beperkingen hebt in functionaliteit.”

Floris Derksen: “Je gaat de applicatie dus steeds verder ontmantelen, dat zien we bij meerdere opdrachtgevers voorbijkomen.”
Zijn twee gesprekpartners zoeken even naar voorbeelden van het grote voordeel van schaalbaarheid, maar uiteindelijk moeten ze het met Daniël eens zijn. Het systeem voor Lowlandstickets komt bijvoorbeeld voorbij, waar mensen eens in het jaar lang in de wacht moeten staan terwijl er de rest van het jaar niets gebeurt. “Maar die mensen gaan toch wel in die wachtrij staan omdat ze specifiek naar dat event willen”, argumenteert Daniël. “Het is geen product dat je overal kunt kopen bij de AH of Dirk. Dan kun je wel 100.000 euro en veel tijd gaan investeren in een infrastructuur die flink meeschaalt, maar dat levert je helemaal niets op.”
Maar ook functionaliteit heeft niet het alleenrecht, vindt Kaj. “Wat businesscases betreft zijn er twee soorten groei”, zegt hij, “kosten besparen en omzet verhogen. Omzet verhogen kan met nieuwe functionaliteit, maar kosten besparen doe je door efficiënter omgaan met je resources.” En ook daarin kunnen containers van pas komen, zo is men het aan tafel met elkaar eens.
De orkestratietool
Maar het is nog geen uitgemaakte zaak hoe je containers moet orkestreren. Kaj gebruikt op het moment Docker Swarm, terwijl True heeft gekozen voor Kubernetes. Gelukkig zit in het gebouw Daniël Koopmans, die ooit Docker Swarm gebruikte en uiteindelijk is overgestapt naar Kubernetes. Hij kan dus als geen ander uitleggen wat het verschil is en wanneer je beter het een of het ander kunt gebruiken.

Daniël de Groot: “Als bedrijven moeten kiezen tussen functionaliteit en schaalbaarheid, dan zal vrijwel iedereen kiezen voor functionaliteit.”
Zijn standpunt blijkt er al uit het Kubernetes-logo op zijn t-shirt prijkt, maar hij vertelt wel dat hij zich eerst helemaal in Docker Swarm heeft ingewerkt en dat hij op dat moment niet inzag waarom hij Kubernetes nodig zou hebben. Beide zijn het orkstratietools voor containers. “Alleen gaat de orkestratie bij Kubernetes veel verder”, stelt hij. “Swarm ondersteunt acht replica’s en daar houdt het mee op. Daarnaast kun je in Kubernetes duidelijk zien hoeveel requests het systeem krijgt van bezoekers er zijn en hoeveel CPU gebruikt wordt. Dat kan ik met Swarm ook maar dat kost veel meer moeite.” Verder is alles binnen Kubernetes modulair. Het is een legosysteem waar je makkelijk dingen in kunt pluggen. De meeste dingen die met Kubernetes kunnen, zijn ook mogelijk in Swarm, maar wederom moet je er meer moeite voor doen.
De leercurve van Kubernetes is wel veel steiler dan die van Docker Swarm, zo vertelt Daniël Koopmans. Maar als je een uitgebreide omgeving hebt of daar naar toe wilt groeien, dan raadt hij toch die orkestratietool aan. Blijft alles klein en beperkt, dan is Docker Swarm de betere optie. Waarbij je wel moet bedenken dat overstappen van de ene naar de andere tool veel werk vereist, dus het is beter om daar vooraf goed over na te denken.