Door apps niet meer op de ouderwetse manier live te zetten op een server, maar ze in te pakken in containers en te deployen met Kubernetes, wordt het deployen van nieuwe releases een stuk betrouwbaarder. Maar het werken met containers en Kubernetes is veel meer dan een nieuwe technologie. Het verandert je bedrijfscultuur en opent nieuwe mogelijkheden voor het ontwikkelen, testen, uitrollen en schalen van software.
Bij Enrise maken we niet alleen websites en (web-)apps, maar we ontwerpen ook het hele landschap daarachter. Bij het ontwerpen en inrichten van het deploymentproces komt veel kijken. Mijn collega Rick van der Staaij en ik hebben daarom de afgelopen jaren heel veel vrijdagavonden geïnvesteerd in het verkennen van de mogelijkheden van Kubernetes en de voordelen die het biedt boven de ‘klassieke’ manier van cloud-software deployen.
(in bovenstaande video legt Stefan van Essen uit hoe je dankzij pipelines, containers en kubernetes weer grip op je deploymentproces kunt krijgen)
Containers en Kubernetes: de nieuwe manier
Een populaire manier om apps efficiënter, beter en sneller te deployen is om ze in te pakken in een ‘container’. Collega Sjoerd schreef eerder een blog over containers en Kubernetes. Mocht je hier nog niet helemaal in thuis zijn is het een aanrader eerst dit blog te lezen.
Containers bieden je de volledige controle over de omgeving waarin je app draait. Je verpakt alles wat je app nodig heeft mee in de container en je bent daardoor niet meer afhankelijk van de configuratie van je servers. Het bouwen van apps zonder containers voelt wat mij betreft een beetje als het maken van een brein, dat daarna door iemand anders in een robot wordt gezet. Alleen, we weten nooit helemaal precies hoe die robot er uit ziet. Met containers bouwen we het brein en de robot tegelijk en kunnen we dus alles optimaal op elkaar afstemmen.
“Met de nieuwe superkrachten die je krijgt met DevOps, krijg je ook grote verantwoordelijkheid. Dat vereist begeleiding en training die veel verder gaan dan alleen het binnenbrengen van een nieuwe technologie.”
Als container orchestrator zorgt Kubernetes dat de juiste versie van al onze containers aan de juiste gebruikers wordt aangeboden en dat containers, waar nodig en gewenst, worden op- en afgeschaald. Het pakket laat ons heel gemakkelijk aangeven welke versie van welke container we willen draaien. We kunnen ook aangeven wanneer en hoeveel zo’n container moet worden opgeschaald bij piekbelastingen. Veel apps zijn heel specifiek voor bepaalde seizoenen gebouwd – denk aan verkiezingen, vakantietijd, feestdagen, etc. – en worden de rest van het jaar weinig gebruikt. Door ze in die periodes af te schalen kun je de hostingkosten verminderen. Mits, en dat is een belangrijke voorwaarde, het goed is ingericht.
Lagere kosten, beter testen
Kubernetes goed inrichten is een expertise. Rick en ik zijn hier de afgelopen jaren heel diep ingedoken en zetten onze expertise en ervaring in voor de klanten van Enrise. Vaak horen we van klanten dat hun hosting met Kubernetes alleen maar duurder is geworden. Nou is het in theorie zo dat een app die continu gelijkmatig wordt belast op Kubernetes iets meer rekenkracht nodig heeft door de overhead van de container. In de praktijk wordt geen enkele app volcontinu gebruikt. Er zijn altijd tijden, bijvoorbeeld ‘s nachts, dat je een app kunt laten afschalen. Als je dus goed blijft tweaken en optimaliseren moet het altijd goedkoper kunnen.
Een andere mooie toepassing van Kubernetes is het deployen van meerdere versies van een app. Met een zogenaamde canary release laat je een deel van je gebruikers de nieuwe versie van je app zien. Zo kun je met een beperkt risico verschillende varianten testen en de beste uitrollen naar alle gebruikers. Dat kan ook automatisch, op basis van vooraf bepaalde regels.
Het klassieke deploymentproces
Kubernetes biedt een kans het deploymentproces te verbeteren. In een klassiek deploymentproces stuurt een developer zijn code door en de hostingprovider zet het online. Er zit dus een vrij harde ‘knip’ tussen development (‘dev’) en operations (‘ops’). Software wordt steeds complexer en developers willen sneller nieuwe features uitrollen. Daarmee groeit het onbegrip tussen die twee werelden en wordt die knip vaak een kloof.
Een hoster wil stabiliteit en dat gaat slecht samen met het dagelijks uit- of terugrollen van verschillende versies van (delen van) een app. Tegengestelde belangen die aan beide kanten van de muur tot frustratie leiden, waarbij beide partijen zich slecht begrepen voelen. Dit haalt de snelheid, maar ook de pret, uit het developmentproces. Rick en ik gaan vaak het land in en praten veel met developers bij klanten. We horen iedere keer dezelfde frustraties. Developers willen snel vooruit, maar er zijn te veel afhankelijkheden die het deploymentproces vertragen. Dat geeft frustratie. Onnodige frustratie als je het mij vraagt.
DevOps: development en deployment in hetzelfde team
Een oplossing is om dev en ops samen te brengen in één team: DevOps. Door development, deployment en onderhoud in een team samen te brengen, krijgt het team niet alleen de controle over de productie-omgeving, maar ook inzicht in de prestaties van de app. Zo kun je als development team niet alleen sneller nieuwe features uitrollen, maar heb je ook een beter idee van hoe goed ze in een productieomgeving werken. Het grote nadeel? Verantwoordelijkheid. Is je app uit de lucht? Dan word jij als developer uit je bed gebeld. Dat is een cultuurverandering. Met de nieuwe superkrachten die je krijgt met DevOps, krijg je ook grote verantwoordelijkheid. Dat vereist begeleiding en training die veel verder gaan dan alleen het binnenbrengen van een nieuwe technologie.
Helpen, trainen en onszelf overbodig maken
Het is ons werk en specialisme te helpen met deze transitie. Als team brengen we onze kennis in en zetten de eerste app voor je over naar Kubernetes. We presenteren vervolgens ons werk, delen onze kennis en laten uitgebreide documentatie achter. We implementeren tegelijk de continuous integration pipeline (op basis van GitLab) die we bij Enrise ontwikkeld hebben. Dat automatiseert het stylen van de code, het testen en het deployen naar een review-omgeving en zorgt ervoor dat het team heel snel een nieuwe versie van een container kan maken.
Zo hebben de interne teams een complete implementatie die ze kunnen kopiëren en aanpassen. Maar na die eerste aanzet gaan we ook weer weg want het hele idee is dat de teams zelf hun deployments kunnen doen. Kubernetes en DevOps gaan tenslotte over onafhankelijkheid! En dat is wat we brengen.
