Allemaal zouden we wel eens in de toekomst willen kijken. Zelf zou ik de ontwikkeling van containerisatie bij bedrijven graag eens door een glazen bol willen bewonderen. De hype is inmiddels gaan liggen en de innovaties schieten als paddenstoelen uit de grond. Wat kun je als organisatie eigenlijk met het concept? En waar begin je aan?
Niet elke organisatie is gebaat bij het gebruik van containers. Zo is het voor de bakker om de hoek minder interessant dan voor een groot kantoor dat veel gebruikmaakt van verschillende soorten software en systemen. De populatie van bedrijven die ‘fully containerized’ zijn, is nog niet erg groot, maar wel gigantisch aan het groeien. De groei van vooral schaalbare ‘cloud native’-applicaties is interessant. Deze beweging vergroot de noodzaak voor een nieuwe applicatie-architectuur. Hierbij is een nauwe samenwerking van developers en ict-afdelingen van groot belang. Het herontwerpen van een infrastructuur moet je immers niet te licht opvatten. Operationeel komen er flink wat uitdagingen naar voren. Maar waar begin je als organisatie als je gebruik wilt maken van containerisatie? Ga eens in gesprek met de it-afdeling om te achterhalen waar bij jullie de valkuilen in de infrastructuur zitten. Aan de hand hiervan kun je gerichter op zoek gaan naar hoe je de infrastructuur moet herinrichten.
Dirigeren
Een orkest heeft een dirigent, een container heeft een container orchestration framework. Het platform is anders, hierdoor moet er ook anders naar de architectuur, de manier waarop de infrastructuur schaalt en de structuur van de algehele omgeving gekeken worden. De tools van een orchestration framework hebben als doel een kader te bieden en het beheer van de containers te vereenvoudigen en deels te automatiseren. Met het framework zorg je dat als er opgeschaald of afgeschaald wordt, je alle extra of juist minder containers kan ‘aanspreken’ door middel van een dirigent. De dirigent managed de levenscyclus van de containers, aan de hand van de specificaties die in het defenitiebestand van de container vastgelegd zijn. Hoe groter en dynamischer de applicatie, des te belangrijker de dirigent.
Uiteraard is het ook voor softwareteams van belang gebruik te maken van het orchestration framework, hiermee zijn niet alleen taken te controleren maar ook te automatiseren. Denk bijvoorbeeld eens aan de redundantie en beschikbaarheid van containers, het op- of afschalen van het aantal containers of het verplaatsen van containers tussen verschillende locaties. Maar ook het verdelen van de middelen tussen en in containers kun je monitoren door middel van het orchestration framework.
Omdat het gebruik van een orchestration framework bij een container-setup al snel nodig is, is de keuze die je daar maakt belangrijk. Er zijn daar verschillende keuzes te maken, met voor elk framework weer verschillende voordelen en nadelen.
Frameworks
Het meest populaire framework is Kubernetes (‘k8s’), een framework dat is ontwikkeld door Google en intern ontwikkeld voor het managen van containerplatforms aldaar. Dat platform is vrijgegeven en kan door iedereen gebruikt worden. Kubernetes is – zoals veel (ex) Google-producten – uitgebreid en kan daardoor complex zijn. Wel is het zo’n beetje ‘de standaard’ en vaak praten mensen eerder over het gebruik van ‘k8s’, dan over containers zelf.
Docker Swarm is een iets jonger alternatief dat bij Docker zelf is ontwikkeld. Docker Swarm is eenvoudiger, bevat daardoor wat minder functionaliteiten, maar is door de integratie met de standaard Docker-toolset makkelijker op te pakken door teams die al Docker-ervaring hebben.
Docker Swarm en Kubernetes zijn slechts twee alternatieven voor container-orchestratie. Sommige organisaties bouwen hun eigen oplossingen en verschillende open-source en commerciële organisaties liften graag mee op de groei van containerisation en bieden alternatieven aan.
Maak je geen gebruik van een dirigent, weet een muzikant wellicht wel welke noten er gespeeld moeten worden, maar niet in welk tempo om het tot muziek te laten klinken in plaats van een kakafonie. Bij containers werkt dit net zo, is je automatisering niet op orde? Dan ontstaat er chaos zoals bij een symfonieorkest zonder dirigent.
Architectuur
De technologie achter de container blijft van groot belang. Het toevoegen van een abstractielaag is het toevoegen van complexiteit aan de infrastructuur. De architectuur moet kloppen voor jouw organisatie. Gaudí of Berlage, compleet andere bouwstijlen, maar toch klopt het binnen de context. Containers kunnen op bare metal draaien, of in de cloud, en op verschillende platformen/frameworks worden uitgerold. Die keuzes hangen af van het doel en de eisen van de applicatie(s). De ene container is de andere niet en of je kiest voor de implementatie van bestaande containers of dat je zelf de software van de containers wilt gaan herstructureren, zorg dat het klopt.
Wees je daarbij wel bewust van de veiligheid van je infrastructuur. Containers hebben geen beveiliging ingebouwd. De keuze voor een orchestratie-framework heeft hier nauwelijks invloed op. Er zijn initiatieven om container-platformen (en containers onderling) meer te beveiligen, maar feit blijft dat in een container-landschap niet alleen anders moet worden nagedacht over architectuur, maar zeker ook over het veilig stellen en houden van applicaties en data.
Toekomst
Inmiddels zijn we denk ik, de hype voorbij en is het tijd om ons op de toekomst te richten met het gebruik van containers. Wat voor de bakker op de hoek werkt en dus kloppend is, is dat voor een groot kantoor vaak niet zo. Voor veel bedrijven zal containerisatie een grote (interne)verandering zijn waarbij de architectuur prachtig kan worden, mits er een goede dirigent aan het hoofd staat. Helaas heb ik nog steeds geen glazen bol in mijn bezit; ik kijk met veel interesse naar de toekomst als het op containerisatie aankomt.
Als we het over hypes hebben vind ik serverless interessanter dan containers hoewel er wel een relatie tussen bestaat. Namelijk dat serverless diensten veelal gebouwd worden.. op basis van containers. Dit is logisch, want serverless is het veelal het uitvoeren van functie code die niet hardware specifiek is. En hierin ligt in feite ook de basis en het bereik van containers. Het zijn generieke “blokken” die naast elkaar op een Operating System draaien. Het grote verschil tussen een container en een virtual machine / virtuele server is dat een server in feite ruimte claimt (ram / processor) en een container ruimte deelt. Een server neemt altijd ruimte is ook als deze niet gebruikt wordt, containers kun je lekker op elkaar stapelen en gebruiken alleen resources als ze aan het werk gezet worden.
Containers hebben ook zwakke kanten. Ze zijn slecht met het opslaan van data en uitvoeren van bepaalde taken zoals het laten draaien van een database.
Wat je hieruit leert is dat je een (traditionele) omgeving / architectuur niet zinvol kan containeriseren! Containers zijn onderdeel van een oplossing niet DE oplossing.
Als je dus schrijft: “De populatie van bedrijven die ‘fully containerized’ zijn, is nog niet erg groot, maar wel gigantisch aan het groeien.” dan ben ik heel benieuwd hoe ja aan die informatie gekomen bent, of dat het meer “hear say” is. Ik vermoed het laatste.
Dan nog iets over die bakker om de hoek. Dat is nu precies een ideale *gebruiker* van SaaS die (deels) in containers draait. Zo kunnen al die bakkers mooi goedkoop een schaalbare oplossing afnemen.
Om het even expliciet te maken: Containers hebben mijn inziens voornamelijk twee toepassingen: Faciliteren van serverless computing en het multi-tenant maken van (saas) software oplossingen.
Dat laatste ziet er ongeveer zo uit: Er komt via selfservice een tenant bij. Na de validatie wordt er een script gedraaid. Deze provisioned een database (op een NIET container of container waarbij de database vrij licht is) en de opslag van data. Voor de GUI en business layer worden containers provisioned. Aanvullend wordt er een stuk serverless storage provisioned. Dan volgt er een script die de basis voor de tenant in regelt, en BAM je hebt er weer een klant bij waarvoor je geen OPS nodig hebt.
Komt er een nieuwe versie van de software? Dan worden nieuwe container deployed, geswapped met de huidige productie en die worden weer verwijderd. Containers zijn namelijk in de basis immutable, of zou zouden ze gebruikt moeten worden.
Kortom: Containers zijn een deeloplossing en geen vervanger van virtuele servers waarop dingen draaien. Ze zijn vooral handig als je veel bouwstenen van een oplossing schaalbaar naast elkaar wilt zetten….
Dat zijn mijn twee centen.
Het evangelie volgens Robert vs dat van Henri..
Of je nou een virtuele server heb of een container, in beide gevallen gaan ze dan pas compute claimen als je ze up spint, al dan niet automatisch.
High-end databases draaien verder ook efficiënter op bare-metal dan op vm (vertical machines).
Voor zover de applicatie het toelaat : Containers first, dan vm, dan op hardware.
Henri vindt serverless en alles wat cloud is interessant, maar on-prem de automatisering hosten die volledig de resources gebruikt, is nog steeds goedkoper. Als het al elders kan, juridisch.
Ook in cloud heb je iemand nodig die architectuur, security en tco/opex/capex begrijpt. Een developer is tegenwoordig devopser en met de SCM tools van tegenwoordig kost zelf hosten weinig extra moeite meer.
Hi Dino,
Misschien is mijn uitleg niet goed geweest, op basis van jouw reactie zal ik het verder toelichten.
Een container claimt nagenoeg geen compute als je ze “up spint”. Zodoende kun je makkelijker veel containers hebben op een cluster. Een VM is daarmee zwaarder en logger en minder generiek dan een container en de resources van het onderliggende metaal worden in potentie beter uitgenut. VM’s hebben wel weer als voordeel dat ze makkelijker te beveiligen zijn en dat je meerdere OS-sen kunt draaien.
Bare metal is in bijna alle gevallen een slecht idee en veelal een blok cement.
Ook je voorgestelde volgorde “Containers first, dan vm, dan op hardware.” onderschrijf ik niet. Containers zijn veel beperkter dan vm’s en vaker ongeschikt voor de taak. Het zijn vaak geen vervangers, ze hebben ieder hun eigen plaats.
Ik geloof gewoon niet in on-premises. Het maakt je verantwoordelijk voor heel veel zaken waar je minder controle over hebt.
Nu kent cloud computing zijn eigen uitdagingen, maar ik zeg; chose your battles wisely. En heel simpel gezegd; zoals ik al voorspelde is cloud computing het dominante model, zeker als je kijkt naar de nog steeds groeiende adoptiegraad van office 365.
Gezever over bare-metal, vm’s en cloud is een achterhoede gevecht. Totaal niet interessant.
Zelf hosten is alleen zinvol als je heel goed bent in disaster recovery, heel veel volume hebt en over veel competenties beschikt. Ieder moet doen wat het beste bij hem of haar past. On topic geldt dat ook voor containers. Je moet het in ieder geval niet doen omdat iedereen het erover heeft…
*bonkt met hoofd op tafel*
De plaatstelijke bakker heeft meestal genoeg aan een website waarop de wekelijkse aanbiedingen staan met mogelijk een eenvoudig bestelformulier. Even een rondje ‘Reversed DNS Checken’ middels ‘scripting for dummies’ leert dat de e-commerce van MKB Nederland niet veel meer omvat. Uiteraard kun je dat leveren in een container en Bitnami levert deze al jaren als ’turnkey’ oplossingen zodat je een grote portabiliteit in de hosting hebt. De technical evangelist van Leaseweb presenteert feitelijk oude wijn in nieuwe zakken:
https://cloud.vmware.com/community/2019/05/15/vmware-to-acquire-bitnami/
Henri, zoals ik in e-mail al stelde zijn 2 cowboys en één paard uiteindelijk de beste optie want de portabiliteit van een complete service stack, waar de minimalistische kernel van een server dus onderdeel van is, heeft veel kenmerken van een private cloud oplossing met een enorme keuzevrijheid in de plaatsing bij één van de vele ISV’s in Nederland. In het kader van het ‘serverless’ principe kun je deze gehele stack natuurlijk ook op een Raspberry Pi zetten die als onderdeel van het e-commerce ecosysteem van de bakker on-premise in de winkel geplaatst wordt.
Een rootserver heb je al voor € 6 per maand, een tweede om te spiegelen.
Iedere investering in tijd voor die lowend is weggegooid geld. Hosting voor die bakker kan inmiddels voor minder als € 30 per jaar.
Zoals de schrijver zelf stelt, containers is een extra laag van complexiteit, dat beheren kost dus extra geld.
Dus eerst je probleem definiëren en “eventueel” container overwegen als het werkelijk wat brengt in geld, veiligheid, stabiliteit etc. etc.
Overigens tussen de vele versies van Linux, PHP, Mysql komen dan nog versies van de container software, weer een update-zorg extra.
Henri,
Ik schrijf toch “voor zover de applicatie het toelaat”.
En inderdaad, de bakker om de hoek zal het een zorg wezen. Maar dit is computable.
“Veel volume”, “disaster recovery” en “competenties”..Vreemd ? Dit is computable. In wat voor omgeving werk jij dan ?
HPC met internationale partners. Zelf hosten, geheel in cloud of elastisch ?
High-end databases, prijs en privacy vraagstukken zijn een puntje van zorg.
Ook al deel jij dat niet.
Wat mij betreft is office 365 “totaal niet interessant”
@Jan, die vele versies van Linux distros en applicaties waar jij het over hebt, daar zijn containers juist een oplossing voor. Technisch dan, want het gaat ff niet om die bakkers.
Dino: Punt is dat “voor zover de applicatie het toelaat” niet het punt is. Je doet het niet omdat het kan, maar alleen als het iets extra’s oplevert en bij containers is het vaak niet het geval. Containers zijn in veel gevallen een slecht idee. Maar waar containers een goed idee zijn is het dan ook meteen een heel goed idee.
Veel zelfstandigen en kleine bedrijfjes hosten via hun provider een eigen website. Dat is een slecht idee en vaak als ze het verprutsen zijn ze niet in staat het zelf te herstellen. Daarnaast zijn websites -en vooral die van WordPress en Drupal- naast slecht te herstellen ook inherent onveilig en bijna niet veilig te maken zonder expertise. De kans is 0 dat een ondeskundig iemand achterhaald hoe zijn bestel formulier met betaalgegevens geskimmed wordt. En dan heb ik het nog niet eens over het proper instellen van http headers. Om een idee te geven: Computable krijgt ook het slechtste cijfer wat je kunt krijgen ( https://observatory.mozilla.org/analyze/www.computable.nl ) en daar zit nog een bedrijf achter wat een website al een belangrijk product heeft. Ik denk dat Computable zelfs nog nooit een pentest heeft uit laten voeren.
Dat je office 365 niet interessant vind is wederom niet het punt. Het is een dominant product in de markt wat massaal omarmt wordt en cloud computing pur sang is.
Met zelf hosten bedoel ik niet alleen je website, maar ook je business applicaties en nodig infrastructuur.
Maar goed, je hoeft het niet met mij eens te zijn, maar van wat ik roep geef ik een solide onderbouwing en beantwoord je vragen daarover graag.
Henri,
De e-commerce van veel zelfstandigen en kleine bedrijfjes betreft niet meer dan een digitale folder, logica van het bestelformulier is een e-mail waar weinig aan te skimmen valt. Als op de website van online betalen gebruik gemaakt wordt dan betreft het de oplossingen van derden. Verder bieden WordPress, Drupal en anderen automatische update mogelijkheden. En de mogelijkheden van herstel vanuit een back-up zijn niet slechter of beter dan wat je gewend bent want een Nederlandse ISP zoals Leaseweb biedt soortgelijke services als Amazon, Google of Microsoft.
Je kennis van de Nederlandse cloud markt is treurig maar ik neem aan dat je wel bekend bent met het feit dat een bestuurder die zijn BV middels de turboliqudatie heeft opgeheven omdat er geen baten meer waren nog wel verplicht is om tenminste 7 jaar de administratieve bescheiden van de rechtspersoon te bewaren. En 7 jaar geleden hadden we een discussiepanel over het controleren van de cloudprovider. Controleren van de cloudproviders wordt ondoenlijk als deze zich verschuilt achter een kerstboom aan BV’s. Het verhaal van de twee cowboys en één paard gaat dan ook om de risico’s van een administratie in de cloud.
“Verder bieden WordPress, Drupal en anderen automatische update mogelijkheden.” – Dat is maar een half verhaal. Als je weet hoe vaak kritische kwetsbaarheden gevonden wordt in Drupal… daarnaast laten toeleveranciers van thema’s en plug-ins zich met regelmaat hacken zodat je ook die malware geautomatiseerd geïnstalleerd krijgt. Gebruikers zijn geen goede admins. Ze krijgen de sleutel tot iets wat ze niet begrijpen, niet beheersen en niet kunnen beoordelen. Punt.
“Je kennis van de Nederlandse cloud markt is treurig”
Klopt. Welke partijen raad je aan voor serverless computing met goede granuleerde IAM op mijn resources, biedt diverse database formaten aan als een service en kan ik makkelijk over diverse regio’s schalen en geautomatiseerd herstellen na een incident? Een goede console en CLI zijn natuurlijk ook goed geregeld.
Henri,
Je doet het, een oplossing kiezen, omdat die het beste aansluit aan de eisen.
Niet alleen omdat het kan dus.
Office 365 vind ik niet interessant, precies om de redenen die jij noemt. Moet vooral in cloud blijven.
Met zelf hosten bedoel ik hetzelfde als jij, de hele stack. what else ..
Je zegt dat je solide onderbouwing geeft en vragen beantwoordt.
Toch hoor ik over “veel volume”, “disaster recovery”, “competenties”, privacy, databases vol met gevoelige informatie, alleen dat zelfstandigen en kleine bedrijfjes eigen websitjes hosten 😛
Jan is goed bezig met zijn poor mans DR oplossingen middels rsync ofzo en vast met cron checks die van alles mailen.
Jij bent leuk met MKB aan de gang. Prima AWS toepassingen.
Maar bedrijven waar bijv ons Pavke en Dekkinga werken, daar spelen andere belangen.
En vaak hebben ze een leger aan devopsers om de boel te automatiseren.
Bij (bedrijfs en hun eigen) voorkeur op een container platform, want dat geeft hun de verantwoordelijkheid, invloed op schaalbaarheid en beschikbaarheid.
Ja, daar moet je dan verstand van hebben, je applicatie architectuur zo ontwerpen dat die geschikt is voor containers en zo de voordelen ervan meepakt. Competenties dus.
Wat jij roept over beperkingen van containers, ongeschikt zijn voor taken, dat zei men vroeger over linux en open source.
En jouw zwijgen over privacy, zegt mij genoeg. Af en toe iets dat het allemaal wel meevalt.
Liever geen sleutel bij jou, omdat je niet begrijpt, niet beheerst en blijkbaar niet kunt beoordelen 😉