(085) 066 7427 contact@agello.io

Welkom terug!

In mijn vorige blog “Een kennismaking met containers” (https://www.linkedin.com/pulse/een-kennismaking-met-containers-stefan-van-oirschot-) is de basis uiteen gezet van containers. In het kort het verschil tussen bare-metal, virtuele servers en containers en in meer detail over een aantal belangrijke eigenschappen en aandachtspunten van containers en hoe hiermee om te gaan. Deze blog gaat een niveau dieper. Ik schrijf een stukje over geschiedenis, wat containers voor je kunnen betekenen, hoe je van je huidige situatie naar een container situatie komt met microservices Verder met de containers…

Even kort samengevat
Containertechnologie is meer dan 10 jaar oud. Het is dus niet nieuw en het wiel hoeft dus niet nog uitgevonden te worden.

Containers werken met een “base image”. Je zou de vergelijking kunnen trekken met een “application package”. Het is echter niet zo dat je een container op platform A kunt bouwen en er vanuit kunt gaan dat het vlekkeloos draait op platform B. Containers zijn geen vervanging voor Virtual Machines. Denk hier aan het vergelijk tussen de 2-onder-1-kap woning versus het appartementencomplex uit mijn 1e blog over containers. Virtualisatie zorgt er voor dat de onderliggende fysieke hardware (o.a. CPU en memory) efficienter wordt ingezet en een hogere utilisatie mogelijk is. Een container draait binnen een operating systeem waarbij het operating system zorgdraagt voor het aansturen van de onderliggende hardware. Containers lossen een ander probleem op dan virtuele servers.

Containers delen onderliggende infastructure met andere containers. Isolatie (de “Hostel” versus “het park” vergelijking uit mijn eerdere blog) van containers is een zorgpunt, terecht maar belangrijker nog is de inhoud van containers. Deze worden aangeleverd door ontwikkelaars en het is gevaarlijk wanneer het operations team niet weet wat hier in zit . Het geautomatiseerd scannen van containers op het gebied van security (patches, updates, settings, etc.) is dan ook noodzakelijk. Het plaatsen van containers in een “marketplace” of “hub” is potentieel gevaarlijk. Je publiceert een versie en een paar dagen later komen er security updates beschikbaar. Indien je deze niet direct toepast stel je in principe andere mensen bloot aan onveilige software.

Dit is, in meer detail, op een luchtige manier, toegelicht in mijn eerdere blog “Een kennismaking met containers”.

Nu gaan we een niveau dieper en doe ik een aanname dat je eerste kennismaking met containers heeft plaatsgevonden.

Containers is een “Operations” begrip, Microservices iets voor “Developers”. Er is uiteraard een sterke samenhang. Samen hanteren we de DevOps ideologie. In onderstaande alinea kijken we allereerst naar containers en aanverwante zaken vanuit operations optiek.

Wat kunnen containers voor je doen?
Containerisatie kan een efficiënte manier zijn om DevOps te doen. Het is een praktische manier om met de DevOps-methodiek aan de slag te gaan binnen een organisatie. DevOps is binnen veel organisaties noodzakelijk vanwege de voordelen en de wendbaarheid om software sneller en beter vrij te geven en meer waarde te kunnen leveren.

Een ander voordeel van containerisatie is dat het een praktische manier is om Cloud te adopteren. Niet zozeer vanuit een technologisch oogpunt maar omdat containerisatie het relatief eenvoudig maakt om Cloud en zaken als “As-a-Service” en “Elastic infrastructure” te omarmen.

Verder is er nog het onderwerp microservices. Ontwikkelen in microservices helpt bij het inbrengen van schaalbaarheid en beschikbaarheid in de applicatie door de applicatie in kleinere componenten op te delen. Containerisatie ondersteunt hierbij door de individuele microservices elk in een container onder te brengen.

Gaan we verder dan biedt het opknippen van applicaties in microservices en het onderbrengen hiervan in containers risico-verlaging. Wijzigingen kunnen worden doorgevoerd aan één deel van de applicatie waarbij andere onderdelen niet geraakt worden. Omdat componenten kleiner zijn is er minder tijd benodigd om wijzigingen door te testen en kunnen wijzigingen eerder vrijgegeven worden.

Containers starten snel; containers bestaan uit een klein base image, hebben een kleine footprint en vragen minimale performance omdat er geen overhead is. Om deze reden kan een container vrijwel even snel gestart worden als een proces of applicatie.

Containers van A naar B?
Sander Hoogendoorn, microservices expert schrijft in zijn, zeer interessante blog, “Microservices. The good, the bad and the ugly” (https://www.linkedin.com/pulse/microservices-good-bad-ugly-sander-hoogendoorn) over de geschiedenis van software ontwikkeling. Van de ontwikkeling van monolitische applicaties via component based en service oriented architecture naar microservices.

 

Het gebruik van containers geeft de Operations afdeling de mogelijkheid om tegemoet te komen aan de vraag van de business/de (interne) klant om sneller nieuwe omgevingen op te kunnen leveren en de juiste performance en beschikbaarheid te kunnen bieden, direct wanneer het nodig is.

De klant, waar het een eindgebruiker betreft, thuis dan wel in de enterprise, vraagt een steeds betere gebruikerservaring (UX). Om dit te bereiken redeneren we van buiten naar binnen. We zorgen dat onze processen herhaalbaar, kopieerbaar en overdraagbaar zijn en steken onze tijd in het verbeteren van deze gebruikerservaring. Een zeer korte feedback-loop tussen klant en leverancier gecombineerd met een altijd beschikbare, performante oplossing en een zeer korte time-to-market voor nieuwe features helpt hierbij.

Waar de ontwikkelafdeling (development) gebruik maakt van microservices om tegemoet de komen aan de eisen van de klant ondersteunt de operations afdeling deze eisen door de inzet van een containerplatform. Een containerplatform is dan een platform met ondersteuning voor containers, orchestratie, management en integratiemogelijkheden samengepakt in een coherent geheel.

 

Containers in de praktijk

Een overgang van A naar B werkt top-down. Het is niet de bedoeling hier te schrijven over zaken als agile, scrum, backlog, sprints. Er zijn genoeg blogs, artikelen die deze onderwerpen uiteenzetten. Het omarmen van het middel microservices en containers kan plaatsvinden door een deelproject dan wel nieuw project uit te voeren met de “nieuwe manier van werken”. Het werken met microservices wordt steeds verder ingevoerd. Oude applicaties worden omgebouwd (zie ook de blog van Sander Hoogendoorn) dan wel uitgefaseerd en de nieuwe manier van werken wordt steeds meer omarmd met het doel een continu proces om te innoveren en de gebruikerservaring te verbeteren.