Deploymentstrategieën: Blue-Green versus Rolling

Het kiezen van de juiste deploymentstrategieën is een van de meest kritieke beslissingen bij het uitrollen van software, omdat het bepaalt of je gebruikers überhaupt downtime ervaren. Of het nu gaat om een webshop, een gameserver of een Discord-bot, elke update betekent in feite het wijzigen van een draaiend systeem terwijl het blijft draaien. In dit artikel vergelijk ik twee veelvoorkomende benaderingen, blue-green en rolling deployment, aan de hand van echte scenario's, en maak ik duidelijk welke je in welke situatie kiest.

Waarom heb je een strategie nodig?

De eenvoudigste methode, "stop de server, vervang de code, start opnieuw", kan prima zijn voor een klein persoonlijk project. Maar zodra je verkeer hebt, betekent elke seconde downtime omzetverlies, een slechte gebruikerservaring en een daling in de zoekresultaten. Het gedeelde doel van moderne deploymentstrategieën is zero downtime bereiken. Daarnaast zijn er drie kernverwachtingen:

• Snelle rollback: binnen seconden kunnen terugkeren naar de vorige staat als de nieuwe versie gebreken vertoont.
• Veilige verificatie: de nieuwe versie door health checks halen voordat je hem aan echt verkeer blootstelt.
• Voorspelbaarheid: elke deployment uitvoeren met dezelfde, herhaalbare stappen.

Hoe werkt blue-green deployment?

Bij de blue-green-aanpak houd je twee spiegelomgevingen aan: blue is de versie die nu live staat, terwijl green een identieke omgeving is waarin je de volgende versie voorbereidt. Je deployt de nieuwe code naar green, draait de migraties en voert de health checks uit. Als alles er goed uitziet, schakelt de load balancer of reverse proxy het verkeer in één keer van blue naar green. Green is nu live; blue blijft onaangeroerd als back-up staan.

Stel je voor dat je verkeer routeert met een Nginx-upstream. De omschakeling ziet er ongeveer zo uit:

upstream app {
    # server 127.0.0.1:8001;  # blue (oud)
    server 127.0.0.1:8002;    # green (nieuw)
}

Zodra je de configuratie wijzigt en nginx -s reload uitvoert, gaan nieuwe verzoeken naar green. Als er iets stukgaat, geeft het terugzetten van de regels en opnieuw herladen je een directe rollback, want de oude omgeving staat nog overeind.

Hoe werkt rolling deployment?

Rolling deployment is ontworpen voor omgevingen waarin je meerdere kopieën (instances) van dezelfde applicatie draait. In plaats van alle kopieën tegelijk bij te werken, vernieuw je ze opeenvolgend in groepen. Heb je bijvoorbeeld vier kopieën: dan haal je er één uit het verkeer, deploy je de nieuwe versie, voeg je hem na geslaagde health checks weer toe aan de pool, en ga je door naar de volgende. Als het proces klaar is, draaien alle kopieën de nieuwe versie en is het systeem op geen enkel moment volledig offline.

Kubernetes biedt dit model standaard. Wanneer je een Deployment bijwerkt, is de standaardstrategie al rolling:

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

Hier bepaalt maxUnavailable hoeveel pods er tegelijk onbeschikbaar mogen zijn, terwijl maxSurge bepaalt hoeveel extra pods tijdelijk mogen worden aangemaakt. Met deze twee waarden stem je de balans tussen snelheid en capaciteitsveiligheid af.

De twee strategieën naast elkaar

Om de verschillen helder te zien, vergelijken we de kerndimensies:

• Resourcegebruik: blue-green vereist twee volledige omgevingen, oftewel tijdelijk dubbele infrastructuurkosten. Rolling gebruikt je bestaande capaciteit en vraagt alleen om een kleine buffer.
• Rollback-snelheid: bij blue-green is de terugkeer direct; het verkeer terugschakelen naar de oude omgeving volstaat. Bij rolling moet je een nieuwe rollout in omgekeerde richting starten, wat tijd kost.
• Venster met gemengde versies: tijdens een rolling update blijven de oude en nieuwe versie een tijdje gelijktijdig live. Niet-achterwaarts-compatibele API- of databasewijzigingen kunnen daardoor problemen veroorzaken.
• Eenvoud: rolling zit meestal ingebouwd in orkestratietools. Blue-green vraagt iets meer opzet qua routering en omgevingsbeheer.

De database: het echt lastige deel

Bij beide strategieën is het meest voorkomende struikelblok wijzigingen aan het databaseschema. Vergeet niet dat zowel de oude als de nieuwe code een tijdje naar dezelfde database schrijven. Daarom is het schrijven van achterwaarts compatibele migraties essentieel. De praktische regel is: voeg eerst de kolom toe, werk de code bij, verwijder dan de oude kolom; verwijder nooit een kolom en wijzig de code in één stap.

Wil je bijvoorbeeld een kolom hernoemen, volg dan een driefasenpad in plaats van één RENAME: voeg de nieuwe kolom toe, deploy code die beide kolommen vult, en verwijder de oude kolom pas bij een latere deployment. Deze aanpak voorkomt dat overlappende versies elkaar tijdens de release breken.

Welke kies je, en wanneer?

Er is geen enkel juist antwoord; het hangt af van de context. Blue-green is ideaal wanneer directe rollback cruciaal is, voor risicovolle releases, en wanneer je de extra infrastructuur tijdelijk kunt dragen. Rolling is natuurlijker voor teams die veel instances draaien, de kosten laag willen houden en hun wijzigingen toch al achterwaarts compatibel schrijven. Veel volwassen teams combineren beide: de canary-aanpak, die een klein percentage van het verkeer naar de nieuwe versie stuurt, is eigenlijk een voorzichtige variant van rolling, en laat zich mengen met de veiligheid van blue-green.

Veelgestelde vragen

Betekent blue-green deployment dubbele kosten?

Op het moment van de omschakeling wel, beide omgevingen draaien dan tegelijk. Maar dit duurt meestal alleen tijdens het deploymentvenster; zodra de omschakeling klaar is, kun je de oude omgeving verkleinen of uitzetten tot de volgende release. In de cloud houdt facturering per minuut deze extra kosten meestal laag.

Heeft een klein project deze strategieën wel nodig?

Voor een persoonlijk project met weinig verkeer kan de eenvoudige "stop-update-start"-methode volstaan. Maar zodra je gebruikers de downtime beginnen op te merken, is het de moeite waard om minstens over te stappen op een omkeerbare flow met health checks.

Vervangt canary deployment deze aanpakken?

Canary is geen alternatief maar een aanvulling. Je stelt de nieuwe versie bloot aan een klein deel van het verkeer, bewaakt de metrics en breidt geleidelijk uit als er geen problemen zijn. Het wordt meestal bovenop een rolling- of blue-green-fundament gebouwd.

Wil je de juiste deploymentflow voor je project opzetten? Of het nu gaat om een releasepijplijn zonder downtime of een veilige migratiestrategie, laten we het samen plannen. Neem contact met me op en laten we de oplossing bespreken die bij jouw behoeften past.