Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Containerization is een (r)evolutie

 

Computable Expert

Robèr van den Brink
Business Unit Manager, CLOUDMERGE BV. Expert van Computable voor de topics Outsourcing, Cloud Computing en Security.

Haal het onderwerp containerization aan bij de gemiddelde ontwikkelaar en hij weet op z'n minst waar het over gaat. Maar meestal blijft het daar niet bij. Met een trackrecord van enkele miljoenen softwaredownloads per kwartaal is de kans zeer groot dat men al aan het experimenteren is of dat er al daadwerkelijk gebruik van wordt gemaakt.

Eén van de bekendste namen op het gebied van containerization is Docker. Docker is beslist niet de enige is die zich bezig houd met containers, maar omdat zij de aanzet hebben gegeven tot deze 'revolutie' kennen ze een goed verankerde 'top of mind' positie. Samen met de andere partijen die containerization tot hun core business hebben gemaakt zoals CoreOSFlockport en Ubuntu's Canonical, kunnen we er gevoeglijk van uitgaan dat dit nog maar het begin is. Docker staat op dit moment tot containerization als Luxaflex staat tot horizontale jaloezieën; en zo mag Docker dan ook gelezen worden in deze blog. Zie het voor nu even als een verzamelwoord.



Platformonafhankelijk

Docker is software waarmee je een 'lichtgewicht' Linux container aanmaakt. De wijze waarop dat gebeurt is vele malen efficiënter dan een hypervisor. Daarnaast wordt deze virtualisatietechniek gecombineerd met een mechanisme om software 'in, en weer uit te pakken'. Bovenal: het maakt niet meer uit op welke infrastructuur/technologie de container draait. En daarmee hebben we twee van de grootste voordelen benoemd: een container is compact en platformonafhankelijk hetgeen bijdraagt aan een hoge mate van portabiliteit (daar over zo meer).Waarom hebben we het over een container? Daarvoor maken we even een uitstapje naar de fysieke wereld.

Door wereldwijd afspraken te maken met logistieke partijen en toeleveranciers over een standaard, is er sprake van een fysieke container die zich met gemak laat vervoeren door een diversiteit aan schepen, treinen en vrachtwagens, ongeacht merk en/of regio. En dat is niet het enige voordeel, transporteurs kunnen daardoor veel efficiënter vervoeren. Er kunnen immers aanzienlijk meer containers op een schip in vergelijk tot een situatie waar er sprake zou zijn van diverse maatvoeringen. Standaardisatie is hier het sleutelwoord.

Terug naar Docker. Het maakt niet meer uit welke besturingssysteem (os)-distributie en welk platform er 'onder de applicatie ligt', noch is er sprake van een beperkende hypervisor. Zo kan een Docker-container zijn oorsprong vinden op de laptop van een ontwikkelaar waar Ubuntu op draait, kan voor testdoeleinden getransporteerd worden naar AWS, om vervolgens bij de opdrachtgever te 'landen' op zijn 'on premise', en op VMware gebaseerde host alwaar de betreffende container 'in no-time' wordt gerepliceerd, zodat performance geborgd is. De host is op zijn beurt in staat om veel meer containers te herbergen dan virtuele machines. Met andere woorden de voordelen zijn legio: schaalbaarheid, optimaal resourcegebruik, maar vooral portabiliteit.

Build it once, run it anywhere

De hoge portabiliteit van containers kent nog meer voordelen. Het ultieme scenario is dat we uiteindelijk met behulp van de juiste tooling in staat zullen zijn om containers vol automatisch te laten transporteren van de ene cloud naar de andere. Daarbij wordt op basis van van te voren gedefinieerde profielen onder andere gekeken naar het gewenste support level, beveiliging, governance en kosten. En tegelijkertijd is er sprake van geautomatiseerde 'fail-over', resource utilisatie en wordt de belasting 'on-the-fly' verdeeld. Onwerkelijk? Waarschijnlijk niet. De eerste tooling is al beschikbaar. Google Kubernetes en Joyent zijn daar goede voorbeelden van, maar ook Dockers' eigen - vers van de pers - Swarm speelt hier een belangrijke rol. Het feit dat nagenoeg iedere zich zelf respecterende cloud provider Docker omarmt zegt ook al genoeg.

Stuk voor stuk partijen die er voor zorgen dat de containers ook op hun platformen welkom zijn. En de eerste container based PaaS-providers dienen zich ook al aan. Een naam om in de gaten te houden op dat vlak is Wavemaker.

Einde 'lock-in' en kritische succesfactoren

Het verhuizen van een web omgeving van de ene provider naar de ander is niet zonder risico's en kost altijd tijd en dus geld. Waar je vandaag de dag je applicatie ook onderbrengt, er is altijd sprake van een zekere mate van 'lock-in'. Niet zo vreemd, want de ontwikkelingen rondom virtualisatie en de cloud zijn zo snel gegaan dat er nooit tijd is geweest om aan een standaard te werken. Los daarvan, als er al zo'n initiatief was gegebracht. Docker brengt daar nu in sneltreinvaart verandering in, maar er is een 'maar'.

Het succes van de container valt en staat met het respecteren van de standaard door alle cloud en technologie providers. In dat licht had Redhat recentelijk al een aantal kritische noten. Zodra er ook maar één partij is die zijn eigen koers gaat varen, wordt het succes van Docker al minder. En er zijn nog meer kritische succesfactoren. Denk bijvoorbeeld aan de software die benodigd is om al die containers in goede banen te leiden. Cloud Orchestration en de mate waarin containers in staat zijn om met alle clouds 'te praten' wordt van cruciaal belang. Tot slot: Docker staat, hoe kan het ook anders, nog in de kinderschoenen. De koppeling van een platform wat verdeeld is over verschillende clouds, de werking van legacy applicaties, zijn zo maar wat voorbeelden van zaken waar de huidige containertechnologie nog niet in kan voorzien. Ook ten aanzien van beveiliging is er nog een hele weg te gaan. Een recent onderzoek van Gartner was daar duidelijk over: '…disappoint when it comes to secure administration and management…'

De toekomst

Containers zullen voor een blijvende en structurele verandering zorgen in het cloud-landschap en de daarin aanwezige ecosystemen. Het draagt bij aan het verkorten van de 'time-to-market' van applicaties en het zal operations minder complex maken. Er zijn echter nog voldoende uitdagingen alvorens deze technologie volledig geadopteerd zal zijn. En dat is maar goed ook. Internet service providers, managed service providers en cloud providers hebben de tijd hard nodig om hun infra 'containervriendelijk' te maken, zorg te dragen voor adequate 'tooling', hun businessmodel aan te passen en kennis en kunde op te bouwen. In het licht van laatstgenoemde kan het maar zo zijn dat we binnenkort vacatures voorbij zien komen met de tekst: 'Dokwerkers (m/v) gezocht!'

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5227757). © Jaarbeurs IT Media.

7,7


Lees meer over


Partnerinformatie
 

Reacties

Waarom heb ik bij dit soort berichten nou altijd het gevoel dat a: niet het hele verhaal word verteld en b: waar zit 'm het addertje?

Kort en goed, kostenaspect. Kwanta Kosta!

Rober, goed artikel! Leest lekker weg, is informatief, verwijst naar andere sites. Daarnaast geef je ook aan waar momenteel de schoen wringt. Dus aan alle kanten een leuk afgewogen verhaal.

@NumoQuest, speciaal voor jou : http://bit.ly/1Dhcpn8

Ik had er nog nooit van gehoord, maar ziet er zeker uit als een ontwikkeling om in de gaten te houden.

Een vraag die bij me opkomt is wat dit betekent voor onderliggende infrastructuren. Een container t.o.v. een app heeft zijn voordelen, zoals geschetst, maar de hoeveelheid data die je rond moet gaan pompen zal wel aanzienlijk groeien lijkt me.

Inderdaad veelbelovende technologie.
Even een check bij de experts: als je programmatuur hebt ontwikkeld in b.v. C++ dan neem ik aan dat je het voor allerlei platforms toch moet compileren? Executables lenen zich niet echt voor dit soort containers. Geldt mogelijk niet voor Java, maar niet altijd 'build once, run everywhere'?

Ondanks alle jubelverhalen is de realiteit meestal wat weerbastiger. Het gebruik van containers / VM's etc. maakt de software stack weer wat langer en daarmee tevens de kans op ongewenste software afhankelijkheden tussen applicatie en onderliggende onderdelen van de stack.

Het valt mij op dat in dit soort infrastructuurverhalen (want daar reken ik het onderwerp vitualisatie/containers voor het gemak maar even toe), de applicatie meestal als een klein, monolitisch stukje software wordt beschouwd, terwijl dat meestal niet zo is.

Een beetje volwassen businessapplicatie in de meeste gevallen behoorlijk wat connected applications, en kan verspreid zijn over meerdere VM's, gebruik maken van externe componenten draaiende in een jre of op een ander OS. In sommige gevallen bestaat er zelfs een afhankelijkheid met de hypervisor laag (patch levels) en veelal is de applicatie gelokaliseerd in een dedicated subnet en beschermd door een of meer firewalls. Dus het on the fly verhuizen van kritische businessapplicaties tussen cloudproviders moeten we maar met een korreltje zout nemen, denk ik.



Rober,
Inspiratie door je regeerders? :-) Je hebt goed opgelet op de reactie van je regeerders op je je vorige artikel ;-)

http://www.computable.nl/artikel/opinie/cloud_computing/5214057/2333364/supermarkt-of-buurtsuper-welke-public-cloud.html

@PaVaKe: misschien maakt de reactie op dat artikel eea duidelijker wat deze inhoudt

Terug naar dit artikel, ja dat is een leuke ontwikkeling die nog verder doorontwikkeld dient te worden. De oplossing is nu voor ontwikkelaars dus denk niet dat je als eindklant met Docker je spullen (applicatielandschap) tussen verschillende leveranciers kan verplaatsen.

Deze ontwikkeling wordt steeds verder omarmd! Kijk naar Microsoft bijvoorbeeld:

http://www.computable.nl/artikel/technologie/besturingssystemen/5215551/1277048/microsoft-brengt-dockerimage-naar-azurecloud.html

@PaVaKe: ook leuke reactie en toelichting van Ron op dit artikel.

Zoals opgemerkt in andere artikel, ik denk dat naast Docker zullen verschillende leverancier dus ook cloud aanbieders zoals AWS, MS, Google, IBM eigen containertechnologie ontwikkelen met deels basis en deels eigen features.
Misschien is Docker nu hier verder dan andere vendoren maar dat is een kwestie van tijd!

Rober,

Leuk artikel waar voor dank.

Dit is nu eenmaal de toekomst, de volledige virtualisatie van je DC en dus ook je applicatielandschap en ontwikkelstraat.

Reza haalt wel een zeer valide punt aan dat het nog niet helemaal af is. Maar ja dat is alles wat nieuw is in IT land. Als het echt compatible wordt met alle (grote) smaken, pas dan is het in mijn optiek echt af. En dan zal het een uitkomst voor iedereen zijn.

De zogenaamde hardware vendor lock-in zie je al langzaam aan verdwijnen door de intrede van technologie ontwikkelingen zoals hyper converged en uiteindelijk ook het SDDC. En dit zal aan deze transitie alleen maar positief bijdragen. Hardware silo's zullen worden afgebroken en al het "ijzer" zal commodity worden wat aangestuurd zal worden door een "slimme software" laag. Alleen moeten we wel waken dat we de vendor lock-in niet alleen maar verplaatsen van hard- naar software.

Leuke artikelen om te lezen zijn:

http://www.informationweek.com/strategic-cio/it-strategy/containers-explained-9-essentials-you-need-to-know/a/d-id/1318961

http://www.infoworld.com/article/2880770/devops/get-ready-for-the-new-stack.html

http://www.networkworld.com/article/2881554/network-storage/the-world-of-containers-doesnt-end-with-docker.html

Rober en/of Henri
Wordt dit de oplossing voor transportabele appliances in de cloud?

Leuk artikel en de moeite waard om eens nauwkeuriger te kijken wat de voordelen t.o.v. VM's zijn, zo op het eerste gezicht is dit een stap voorwaarts naar uitwisselbaarheid, en dus een push voor "de cloud".
Ik ga maar eens zoeken, niet met google Henri maar met swisscows.

Ben benieuwd wat Ewout daar van vindt . . .

Ik heb zelf Docker nog niet hands-on mee gewerkt, maar dat zal niet lang meer duren.

use cases voor Docker zijn continuous delivery. Je deployed niet de code naar een server, maar eigenlijk als 1 pakketje OS + Software. Of heel snel een debug omgeving optrekken, sneller nog dan EC2 of Cloud Services van Microsoft. Schaalbaarheid, uitrollen en updaten van grote hoeveelheden servers, et cetera.

In feite cloud computing techniek op steriods. Next level virtualization.

Maar dat is mijn begrip, heb het nog niet hands-on toegepast.

Nog een toevoeging, Docker gaat niet over virtualisatie maar meer over isolatie op OS (Linux) niveau. Een combinatie van beiden. De linux kernel bevat technieken, cgroups en namespaces om en een geisoleerde omgeving op te zetten en daar naar behoeve geheugen, processorcapaciteit, gebruikers, eigen filesysteem en netwerk aan toe te kennen. Binnen een docker maak je gebruik van de specifieke bin's en lib's die nodig zijn om je benodigde applicaties te draaien. Docker is naar mijn idee een techniek/protocol hier bovenop, vgl Openstack voor vm's, waarmee je containers kan beheren en adresseren. Wat ik vooralsnog zie gaat het om Linux gebasseerde omgevingen.

Ben nog wel benieuwd hoe het bijvoorbeeld zit met het overcommitten van resources zoals gewoon bij virtuele machines. Maar misschien is er en computable expert op het gebied cloud en virtualisatie die hier meer inzicht over kan verschaffen. Ben benieuwd. Leuk onderwerp en artikel!

Prima stuk van Rober,

Maar of het het einde van "Lock-in" betekent, betwijfel ik...
Naar mijn bescheiden mening is vendor lock-in onontkoombaar, keuzes moeten nou eenmaal worden gemaakt en smaakverschillen, zullen er altijd blijven. (Of ik nou Unix, Linux of Microsoft liefhebber ben!)
Het gewenste business model zal hier een grote rol in spelen, lijkt me!

Lois geeft volgens mij prima aan waar het om draait, isolatie van een zelfstandige eenheid die alles in zich draagt om als applicatie door het leven te gaan. (vult u zelf in wat u onder applicatie verstaat!)

Isolatie dus om geen verstoringen (last van) de omgeving te hebben en of te veroorzaken waar de (app)container op wordt uitgevoerd... en om makkelijk te kunnen managen.

Alle grote partijen ondersteunen Docker , ook Microsoft Azure, waar ik al eens in een van mijn eerder reacties naar verwezen heb : http://www.computable.nl/artikel/technologie/besturingssystemen/5215551/1277048/microsoft-brengt-dockerimage-naar-azurecloud.html#5217133

Overcommitten van resources, hmmmm
Wat ik wel weet is dat je de vraag moet stellen over welk soort van Docker configuratie je het gaat hebben namelijk :

Ter illustratie VMware als voorbeeld.
a: Native: Linux OS wat direct wordt uitgevoerd op hardware (bijv. Ubuntu, CentOS)
b: vSphere VM: Komende release van vSphere met het zelfde host OS als native wordt uitgevoerd,
c:Native-Docker: Docker version 1.2 uitgevoerd op een native OS,
d: VM-Docker: Docker version 1.2 uitgevoerd in een gast VM op een vSphere host.

Alle varianten hebben hun eigen karakteristieken lees ik...


Pluralsight heeft overigens een aardige cursus gemaakt. Heb hem nog niet gezien, maar wel andere cursussen en als het mogelijk relevant is, dan is dit een goede investering:

http://www.pluralsight.com/courses/docker-deep-dive

Heren (geen vrouw te bekennen hier helaas),

Dank voor alle reacties. Aan het einde van de vorige eeuw zaten we met veel vragen over virtualisatie. En uiteindelijk is ook dat een commodity geworden. Bottomline wat mij betreft: er is nog een aardige weg te gaan voor deze nieuwe technologie en dus roept het veel vragen op, maar net als destijds met virtualisatie zal het zijn weg gaan vinden, zijn meerwaarde gaan bewijzen en zullen er tal van initiatieven gaan ontstaan. We volgen het op de voet!

Wat een verademing om in begrijpbare taal - en zonder commercieel belang- de zaak eens goed op een rijtje gezet te krijgen. Ga vooral zo door Rober! Je gaat het dan wel druk krijgen omdat bedrijven je graag willen inhuren om ze met dit soort trajecten te helpen.

Robèr,

Gewoon een duidelijk verhaal waar de wereld naar toe gaat. Ik kende het nog niet, zie zeker de voordelen. Probleem, zoals je zelf ook schets, zal de standaardisatie zijn.

Ik ben benieuwd naar de eerste echte implementaties ervan.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×