Kiezen voor containers: heb je nog (virtuele) servers nodig?

Kies je omwille van veiligheid of performance voor gereserveerde serverhardware? Dat kan. Het was ooit de standaard in het hosting-wereldje. Vandaag zijn de kostprijs en de beperkte flexibiliteit vaak een minpunt. Met virtualisatie zijn de zaken beter beheersbaar, uitbreidbaar en betaalbaar. En sinds enkele jaren gaat de technologie nog een stap verder: je schaalt in seconden en bijna onbeperkt, met containers.

Containers leveren de bouwstenen van het cloud-tijdperk. Ze veranderen het denkkader voor wie nu met virtuele servers werkt. In het cloud-tijdperk verdwijnen de fysieke infrastructuur én het besturingssysteem helemaal op de achtergrond. Je beheert niet langer servers, maar een cloud-platform. Of je laat het beheren door een vertrouwenspartner zoals Combell.

Bekijk managed container services bij Combell

 

De cloud-voordelen: robuust en hyperuitbreidbaar

Maken containers servers overbodigContainers en hun beheerplatformen zoals Kubernetes zijn in enkele jaren uitgegroeid van spitstechnologie bij internetgiganten zoals Google, tot een populaire ICT-bouwsteen voor bedrijven. Zowel op de eigen infrastructuur als in externe hosting, wint de technologie snel terrein. Terwijl gespecialiseerde kennis nog de voornaamste drempel is, zijn er tal van voordelen.

Door je toepassing in meerdere containers naast elkaar te laten draaien, kun je de middelen nodig voor je applicatie quasi onbeperkt uitbreiden. Natuurlijk moet je aan het onderliggende ‘platform’ de nodige hardware toevoegen naarmate de werkelijke last blijft stijgen. En je moet de tientallen, honderden of duizenden connecties ook netjes spreiden.

Dankzij de technologie kun je dit grotendeels volautomatisch regelen. Of je vertrouwt hiervoor op Combell. Bij een onverwachte piek kun je dus onmiddellijk bijschalen. En je kunt ongebruikte resources weer afbouwen, zodat alles ook betaalbaar blijft.

Een bijkomend voordeel wanneer je meerdere containers naast elkaar plaatst om exact hetzelfde te doen, is dat je een foutbestendige architectuur krijgt. Loopt er een container vast, dan nemen de andere de extra verkeerslast over. Binnen enkele seconden kun je extra containers laten opstarten, zodat er geen overbelasting ontstaat. Het resultaat is een hoge beschikbaarheid, zonder een forse meerprijs.

Al tijdens het bouwen van je toepassing of website denk je na over de ‘niet-functionele’ noden: responstijden, aantal simultane gebruikers, performance-optimalisatie, beveiliging… In het cloud-tijdperk bepaal je dit vooraf, tijdens de ontwikkelfase. Welke systeembronnen en configuratie-parameters heeft deze toepassing nodig? Heb je de optimale configuratie gevonden? Dan stop je ze mee in de containers, en het onderliggende platform zorgt voor de rest.

 

Compact en hyper-gedistribueerd

Containers zijn geen virtuele machines (VM). In de klassieke vorm van virtualisatie, bevat elke fysieke server een aantal ‘virtuele’ servers, tot de grenzen van de onderliggende hardware bereikt zijn. Op de fysieke server zit dan een hypervisor-laag, waarop meerdere VM’s draaien, met daarop telkens een volwaardig besturingssysteem en software-toepassing(en). Containers hebben veel minder ‘overhead’, zodat je in een klassieke VM-aanpak tot vijf keer meer rekenkracht nodig hebt voor dezelfde werklast (‘VM-taks’). In een klassieke VM-aanpak is het ook lastig om virtuele servers te beschermen tegen een naburige toepassing die erg veel rekenkracht, geheugen of opslag vreet.

Hoe schakel je dan om naar containers? Het is belangrijk om goed te beseffen wat dat voor gevolgen heeft, in het bijzonder voor de manier waarop je toepassingen ontwikkelt, of laat ontwikkelen. Het gaat echt om een andere manier van werken, zelfs van denken en van verantwoordelijkheid nemen. Containers passen perfect in een DevOps-aanpak, waarbij de klassieke tweedeling tussen software-ontwikkeling en infrastructuurbeheer verdwijnt.

Elke container bevat configuratie-details, libraries en alle andere nodige componenten om de toepassing onmiddellijk te laten opstarten. Er komt geen installatie meer aan te pas. Dit maakt capaciteitsuitbreiding net zo snel en makkelijk. Het opstarten van nieuwe, identieke containers is volledig automatiseerbaar. Het is de manier waarop internetgiganten zoals Google werken.

 

Eén grote toepassing of vele kleintjes?

Containers en microservicesVoor complexe toepassingen is de recente trend trouwens om elke applicatie verder uit te splitsen in kleinere functionele onderdelen of microservices. Dit heeft belangrijke operationele voordelen… Grondige wijzigingen in de code kunnen worden verpakt en uitgerold als een nieuwe container, terwijl de andere onderdelen ongewijzigd blijven. Je vermijdt zo een ingewikkeld kluwen van afhankelijkheden. Daarnaast kun je ook erg selectief bijschalen, door meer resources te voorzien exact daar waar er vertraging of overbelasting optreedt.

In werkelijkheid kies je zelden om één of enkele containers op te zetten en uit te rollen. Je gebruikt ze voor testing, acceptatie en productie. In een microservices-architectuur zet je in elk van die omgevingen meerdere, of meerdere tientallen containers op. En om performant en fouttolerant te werken, ontdubbel je elke container. En je schaalt verder bij waar nodig. Ook al is het niet moeilijk om vanaf een bestaande image snel nieuwe containers op te zetten, toch loont het de moeite om maximaal te automatiseren. Zeker als het gaat om tientallen, honderden of zelfs duizenden containers.

Wat typisch niet in de container zit, is elke vorm van gegevensopslag. Je cloud-toepassing ontvangt en verwerkt wel gegevens, maar slaat ze vervolgens op in een achterliggende databank, of geeft ze via webservices of een API-platform aan nog een ander systeem door. Je zet dus nooit meer je applicatie(s) en je databank op één systeem, al was dat om veiligheidsredenen ook vroeger al een slecht idee.

Precies de onveranderlijke (stateless) aard van de container zorgt ervoor dat je die op elk moment kunt stoppen, dupliceren of herstarten. Maar daar moet je toepassing natuurlijk wel mee overweg kunnen. Oudere toepassingen zijn typisch niet zomaar geschikt voor containers, tenzij na een grondige re-engineering. Kom daarover gerust eens praten met onze cloud-specialisten.

 

Hoe kun je dit beheren en automatiseren?

Wie de stap zet naar een microservices-architectuur krijgt plots tientallen, honderden of zelfs duizenden containers te beheren. Genoeg om de tel kwijt te raken? Gelukkig is de technologie hier opnieuw een bondgenoot. In plaats van als systeembeheerder als het ware één instrument te bespelen, speel je dankzij automatisering voortaan de rol van orkestmeester. Klinkt ingewikkeld? Combell wijst je de weg indien nodig.

Docker meest populaire container formaatDocker is zowat de meest populaire tool om images te bouwen en containers te laten draaien. Het werkt met standaard hardware en met de meest courante besturingssystemen, zoals Linux, Windows en MacOS. In de image - of blauwdruk van je applicatie - stop je eigenlijk wat je maar wil: je code, voor zowat elke taal of technologie, met alles wat erbij hoort. Vervolgens zet je ze naar believen om in containers, al of niet via ‘continuous integration’-platformen zoals GitLab of Jenkins. Elke nieuwe container neemt automatisch de allerlaatste wijzigingen en parameters mee. Dat zorgt voor kolossale tijdwinst en een minimale kans op menselijke fouten.

Een bijkomend voordeel is dat containers perfect draaien op je server-infrastructuur, hosting of infrastructuurcloud, maar net zo goed op je laptop. Software-ontwikkelaars kunnen dankzij containers hun nieuwe toepassingen met minimale moeite zelf uitrollen, testen en verbeteren. Dit brengt de risico’s van de finale go-live sterk naar beneden.

KubernetesKubernetes orkestratie-platform voor containers is het populairste orkestratie-platform voor containers. Nadat je je toepassing in images stopt met bijvoorbeeld Docker, zorgt Kubernetes ervoor dat alles samenwerkt en blijft werken. Dankzij orkestratie kun je moeiteloos bijschalen, zelfs onmiddellijk en volautomatisch op basis van toenemend verkeer of langere responstijden. Het bezoekersverkeer wordt netjes verdeeld over de actieve containers én de achterliggende opslagsystemen, in alle veiligheid. Een nieuwe versie uitrollen van een actieve container gebeurt zonder onderbreking indien minstens 2 containers draaien.

Om maximaal te genieten van de voordelen van container-orkestratie kun je best grondig nadenken over alle mogelijkheden. Aan krachtige nieuwe tools ontbreekt het zeker niet, en de gevolgen voor je software-architectuur zijn ingrijpend. Het traject is absoluut de moeite waard en Combell helpt je een heel eind op weg.

Met managed Kubernetes spaar je een belangrijk deel van de leercurve uit en kom je meteen tot indrukwekkende resultaten. Voor cruciale design-keuzes heb je met Combell op elk moment een ervaren partner binnen handbereik. Onze specialisten laten je nog meer focussen op de applicaties en op de noden van je business. Ze kennen de valkuilen en durven de juisten vragen stellen.

Ook voor de gegevensopslag biedt Combell een oplossing op ons enterprise storage systeem. Dankzij de integratie met Kubernetes lijkt het voor de applicatie alsof het over lokale opslag gaat. De veiligheid van de gegevens wordt bewaard door dit alles op een apart systeem bij te houden. Zo combineren we betrouwbaarheid met performantie.

Lees verder over de volgende stap naar serverless computing: Function-as-a-Service (FaaS): de verdwijntruuk voor je infrastructuur

Combell laat je niet aan je lot over. Samen zetten we de stap naar software-ontwikkeling voor het cloud-tijdperk.

Ontdek managed Kubernetes bij Combell