Blue-green deployment: zo werkt updaten zonder downtime
Met blue-green deployment zet je een nieuwe versie van je website, webshop of applicatie live zonder dat je bezoekers er iets van merken. Je laat twee identieke productieomgevingen naast elkaar draaien: blauw bedient je klanten en groen krijgt de nieuwe versie. Pas als groen getest en goedgekeurd is, stuur je het verkeer om. Gaat er toch iets mis, dan zet je het verkeer in één handeling terug. Dat klinkt eenvoudig, en het principe is dat ook. De winst zit in de uitvoering: twee omgevingen die echt gelijk zijn, een database die beide versies aankan en monitoring die problemen meteen ziet. Voor een kleine organisatie is dat vooral een kwestie van goed ingerichte en goed beheerde hosting. In dit artikel lees je hoe het werkt, waar het misgaat en hoe het zich verhoudt tot canary en rolling deployments.
Kort samengevat
- Blue-green deployment gebruikt twee identieke omgevingen: blauw is live, groen krijgt de nieuwe versie en wordt eerst getest.
- Het omzetten van verkeer gebeurt in één keer, en terugdraaien (rollback) is net zo snel: je stuurt het verkeer terug naar blauw.
- De database is het lastigste deel: beide versies moeten tijdelijk met dezelfde gegevens kunnen werken.
- Canary deployment zet een nieuwe versie eerst bij een klein deel van je bezoekers neer; blue-green schakelt alles tegelijk om.
- Voor webshops en mkb werkt het het best op hosting die strak beheerd wordt, met vaste afspraken over testen, monitoring en snelle hulp.
Inhoudsopgave
- Wat is blue-green deployment precies?
- Zo werkt blue-green deployment stap voor stap
- De database: het lastigste deel
- Voordelen en kosten op een rij
- Blue-green, canary of rolling: wat is het verschil?
- Wanneer past blue-green bij jouw organisatie?
- Ons perspectief op zorgeloos updaten
- Hosting en beheer die je releases ondersteunen
- Veelgestelde vragen
- Bronnen
Wat is blue-green deployment precies?
Blue-green deployment is een manier om software uit te rollen waarbij je de nieuwe versie niet over de oude heen installeert. In plaats daarvan bouw je een tweede, gelijkwaardige omgeving op. Martin Fowler, die de aanpak bekend maakte, beschrijft het als twee zo identiek mogelijke productieomgevingen waarvan er steeds één live is. Een router of load balancer, het onderdeel dat bepaalt naar welke server een bezoeker gaat, wijst naar de actieve omgeving.
Het verschil met de klassieke manier is groot. Bij een gewone update zet je vaak een onderhoudspagina neer, voer je de wijzigingen door en hoop je dat alles werkt als je de site weer opent. Lukt dat niet, dan moet je terug naar een back-up, en dat kost tijd en omzet. Bij blue-green draait de oude versie gewoon door tot de nieuwe klaar en getest is.
Voor een webshop betekent dat concreet: geen onderhoudsvenster midden in de nacht, geen klanten die halverwege het afrekenen een foutmelding krijgen en geen paniek als een plug-in-update de checkout breekt. De oude, werkende versie staat immers nog klaar.
Waarom heet het blue-green?
De kleuren hebben geen technische betekenis. Volgens Dan North, die er later over vertelde, komt de naam van twee naast elkaar draaiende serveromgevingen die zijn team destijds Blue en Green noemde. Neutrale namen hebben een voordeel: geen van beide klinkt als “de echte” of “de oude”. Bij elke release wisselen ze van rol, dus wat vandaag groen is, is na de volgende update de reserve.
Zo werkt blue-green deployment stap voor stap
De stappen zijn bij vrijwel elk platform hetzelfde, of je nu een WordPress-webshop, een maatwerkapplicatie of een API uitrolt. Per stap lees je wat erbij komt kijken en waar het in de praktijk misgaat.
-
Zorg dat blauw stabiel live staat. Je huidige omgeving bedient al je bezoekers. Leg vast welke versie draait, welke instellingen er gelden en hoe de omgeving is opgebouwd. Waar het misgaat: als niemand precies weet hoe blauw is ingericht, wordt groen nooit echt identiek.
-
Bouw groen op als exacte kopie. Zelfde besturingssysteem, zelfde PHP- of runtimeversie, zelfde configuratie en dezelfde koppelingen met betaalprovider, mailserver en voorraadsysteem. Kleine verschillen, zoals een andere cache-instelling, zijn de klassieke oorzaak van “bij mij werkte het wel”. Wie al met een staging-omgeving werkt, kent dit principe: hoe dichter de testomgeving bij productie ligt, hoe meer je test zegt.
-
Zet de nieuwe versie op groen. Dat gaat het betrouwbaarst geautomatiseerd, bijvoorbeeld vanuit Git. In ons artikel over git deploy op een server lees je welke methode bij welk project past. Handmatig bestanden uploaden maakt het moeilijk om te herhalen wat je precies hebt gedaan.
-
Test groen grondig. Denk aan functionele tests (werkt het winkelmandje, kun je inloggen, komen bestellingen binnen), prestatietests (blijft de site snel onder belasting) en compatibiliteitstests met externe koppelingen. Groen is nog niet bereikbaar voor klanten, dus fouten raken niemand.
-
Schakel het verkeer om. De router of load balancer wijst voortaan naar groen. Voor bezoekers gebeurt dit ongemerkt. Let op lopende sessies: een klant die net iets in zijn winkelmandje heeft gezet, wil dat na de omschakeling nog terugzien. Sessies en winkelmandjes horen daarom in een gedeelde opslag te staan, niet op de server zelf.
-
Monitor scherp. De eerste minuten en uren na de omschakeling zijn het spannendst. Houd foutmeldingen, laadtijden en het aantal geslaagde bestellingen in de gaten. Met automatische storingsmeldingen hoor je het meteen als er iets afwijkt, in plaats van via een klant die belt.
-
Rol terug als het nodig is. Zie je problemen, dan zet je de router terug naar de blauwe omgeving. Omdat blauw onaangeroerd is gebleven, ben je binnen korte tijd weer op de laatste werkende versie.
-
Rond af. Is groen stabiel, dan wordt blauw de reserve voor de volgende release. Je kunt die omgeving ook afschalen tot je haar weer nodig hebt, zodat je niet permanent voor dubbele capaciteit betaalt.
Belangrijk: elke omschakeling is een wijziging in je productieomgeving. Leg daarom vast wie besluit, wie test en wie terugdraait. Een praktische aanpak daarvoor vind je in onze gids over change management in IT.
De database: het lastigste deel
De servers verdubbelen is relatief eenvoudig. De database verdubbelen meestal niet, en dat is ook niet wenselijk: je wilt geen bestellingen kwijtraken die op de ene omgeving binnenkwamen terwijl de andere live ging. Daarom delen blauw en groen in de praktijk vaak één database.
Dat vraagt discipline. De documentatie van Cloud Foundry waarschuwt dat relationele databases verschillen tussen blauw en groen kunnen veroorzaken, en adviseert één database die zowel met de oude als met de nieuwe versie overweg kan. Vakmensen noemen dat backward- en forward-compatible: de oude code moet blijven werken met het nieuwe schema, en de nieuwe code met de bestaande gegevens.
In de praktijk werk je daarvoor in drie fasen:
- Uitbreiden. Voeg nieuwe kolommen of tabellen toe zonder iets te verwijderen. De oude versie negeert ze gewoon.
- Migreren. Zet de nieuwe versie live en vul de nieuwe velden met bestaande gegevens.
- Opschonen. Pas als blauw definitief niet meer nodig is, verwijder je oude kolommen. Doe je dat eerder, dan werkt een rollback niet meer.
Een voorbeeld: je webshop splitst het veld “naam” op in “voornaam” en “achternaam”. Verwijder je “naam” direct, dan crasht blauw zodra je moet terugdraaien. Laat je beide velden een release lang naast elkaar bestaan, dan blijft de weg terug open.
Fowler wijst nog op een tweede valkuil: transacties die binnenkomen terwijl groen live is en die bij een rollback verloren dreigen te gaan. Oplossingen zijn wijzigingen naar beide omgevingen sturen of de applicatie kort alleen-lezen maken. Voor grote, tijdrovende migraties beschrijft Cloud Foundry een tijdelijke onderhoudsroute, zodat bezoekers een nette melding zien in plaats van een fout.
Voordelen en kosten op een rij
De voordelen zijn voor een webshop of zakelijke applicatie direct merkbaar:
- Geen of nauwelijks downtime. De omschakeling duurt seconden, niet uren.
- Snelle rollback. Terug naar de vorige versie is één handeling, geen herstel uit een back-up.
- Testen op een echte productieomgeving. Groen is identiek aan live, dus testresultaten zijn betrouwbaar.
- Vaker en rustiger releasen. Omdat de weg terug kort is, durf je kleinere updates vaker uit te rollen. Kleine stappen zijn makkelijker te controleren.
De kosten zitten vooral in capaciteit en inrichting. Tijdens een release draai je twee omgevingen, dus je hebt tijdelijk dubbele servercapaciteit nodig. Met hosting die je kunt opschalen en weer afschalen blijft dat beperkt tot de periode rond de release; lees hoe dat werkt in onze gids over automatische schaalbaarheid van hosting. Daarnaast vraagt de inrichting tijd: een load balancer, geautomatiseerde deployments, gedeelde sessieopslag en monitoring. Dat is een eenmalige investering die zich terugverdient bij elke release die niet misgaat.
Blue-green, canary of rolling: wat is het verschil?
Blue-green is niet de enige strategie. Twee andere kom je vaak tegen.
Canary deployment zet de nieuwe versie eerst bij een klein deel van je bezoekers neer. Je vergelijkt hun foutpercentages en laadtijden met die van de rest en verhoogt het aandeel stap voor stap. De naam verwijst naar de kanarie die mijnwerkers meenamen als vroeg waarschuwingssignaal. Canary vraagt geen complete tweede omgeving, maar wel slimme verkeersverdeling en goede meetgegevens om automatisch te kunnen beslissen.
Rolling deployment vervangt servers één voor één. Er draaien dus tijdelijk oude en nieuwe versies door elkaar. Dat bespaart capaciteit, maar terugdraaien gaat trager omdat je weer server voor server terug moet.
| Kenmerk | Blue-green | Canary | Rolling |
|---|---|---|---|
| Hoe gaat het verkeer over? | In één keer naar de nieuwe omgeving | Geleidelijk, eerst een klein deel | Server voor server |
| Rollback | Direct: verkeer terug naar blauw | Snel: aandeel terug naar nul | Trager: servers één voor één terug |
| Extra capaciteit | Tijdelijk een volledige tweede omgeving | Beperkt | Beperkt |
| Benodigde techniek | Load balancer, identieke omgevingen | Verkeersverdeling, uitgebreide metingen | Orkestratie van meerdere servers |
| Past goed bij | Webshops en applicaties waar elke minuut telt | Grote platforms met veel verkeer | Clusters met veel gelijke servers |
De strategieën sluiten elkaar ook niet uit. Je kunt binnen een blue-green-opzet eerst een klein deel van het verkeer naar groen sturen voordat je volledig omschakelt. Dat combineert de controle van canary met de snelle weg terug van blue-green.
Voor de meeste mkb-bedrijven en webshops is blue-green de logischste keuze. Canary komt pas echt tot zijn recht bij zoveel bezoekers dat een paar procent al een statistisch betrouwbare steekproef vormt. Met een paar honderd bezoekers per uur meet je bij een klein canary-aandeel vooral toeval. Blue-green geeft je dan meer zekerheid: volledig testen vooraf, in één keer live en direct terug als het nodig is.
Wanneer past blue-green bij jouw organisatie?
Blue-green loont vooral als een storing direct geld of vertrouwen kost. Denk aan:
- een webshop waar uitval tijdens piekuren gemiste bestellingen betekent;
- een klantportaal of boekingssysteem waar klanten 24 uur per dag op rekenen;
- een webdevelopmentbureau dat voor meerdere klanten regelmatig updates uitrolt en geen nachtelijke onderhoudsvensters wil plannen;
- interne applicaties waar medewerkers de hele dag mee werken.
Voor een eenvoudige bedrijfswebsite die een paar keer per jaar verandert, is een goede staging-omgeving met een betrouwbare back-up vaak al voldoende. De vraag is dus niet of blue-green “beter” is, maar wat een uur uitval jou kost en hoe vaak je updates doorvoert. Hoe vaker je releaset en hoe duurder uitval is, hoe sneller de investering zich terugbetaalt.
Weet je niet goed hoe je huidige omgeving ervoor staat? Begin dan bij de basis: zijn je servers gedocumenteerd, is je hosting schaalbaar, worden storingen gemeld? Een beoordeling van je IT-infrastructuur laat snel zien wat er nodig is.
Ons perspectief op zorgeloos updaten
Als we met ondernemers praten over updates, horen we zelden dat ze techniek willen leren. Ze willen dat hun webshop of applicatie het gewoon doet, ook op de dag dat er een nieuwe versie live gaat. Precies daar draait blue-green deployment om: de nieuwe versie bewijst zich eerst, en de werkende versie blijft klaarstaan.
Het principe is helder, de uitvoering vraagt aandacht. Twee omgevingen die echt identiek zijn, een database die beide versies aankan, monitoring die meteen alarm slaat. Dat zijn geen zaken die je er even naast doet als je ook een bedrijf runt of klantprojecten oplevert.
Daarom geloven wij in hosting en beheer waarbij je je kunt richten op je core business. Persoonlijk bereikbaar, problemen binnen één dag opgelost en een vast maandbedrag zonder verrassingen. Zo wordt een release iets waar je niet meer wakker van ligt.
Ken
Hosting en beheer die je releases ondersteunen
Blue-green deployment werkt alleen zo goed als de omgeving eronder. Bij NLXS ontzorgen we je van de technische kant: van hosted serverbeheer en betrouwbare WordPress webhosting tot ICT-consultancy en support. Je bent persoonlijk en telefonisch direct bereikbaar met ons team, we lossen problemen binnen één dag op en je betaalt een vast maandbedrag zonder verrassingen.
Ben je webdeveloper en wil je de hosting van je klanten uitbesteden, zodat jij je op het bouwen kunt richten? Bekijk dan hosting voor jouw klanten. Wil je eerst weten wat jouw omgeving nodig heeft om veilig en zonder downtime te updaten? Met onze ICT-scan en ons advies krijg je een helder beeld. Neem contact met ons op via nlxs.nl.
Veelgestelde vragen
Is blue-green deployment hetzelfde als een staging-omgeving?
Nee. Een staging-omgeving is een testkopie die nooit live gaat; na het testen zet je de wijzigingen over naar productie. Bij blue-green wordt de geteste omgeving zelf de productieomgeving door het verkeer om te zetten. Veel teams gebruiken beide: eerst staging, daarna blue-green voor de livegang.
Kan ik blue-green deployment gebruiken voor een WordPress-webshop?
Ja, mits de omgeving erop is ingericht. Het belangrijkste aandachtspunt is de database: plug-in-updates passen soms tabellen aan, en die wijzigingen moeten ook voor de oude versie werkbaar blijven. Ook sessies en winkelmandjes moeten in gedeelde opslag staan, zodat klanten niets kwijtraken bij de omschakeling.
Wat kost blue-green deployment?
De belangrijkste kostenpost is tijdelijk dubbele servercapaciteit tijdens een release, plus de eenmalige inrichting van load balancer, automatisering en monitoring. Met schaalbare hosting schaal je de reserveomgeving na de release af. Wat het voor jouw situatie betekent, hangt af van je omgeving en hoe vaak je updates uitrolt.
Wanneer kies ik canary in plaats van blue-green?
Canary past vooral bij platforms met zoveel verkeer dat een klein percentage bezoekers al betrouwbare meetgegevens oplevert, en met de tooling om verkeer fijnmazig te verdelen. Voor de meeste mkb-bedrijven en webshops geeft blue-green meer zekerheid met minder complexiteit. De twee zijn ook te combineren door groen eerst kort aan een klein deel van het verkeer bloot te stellen.
Hoe snel is een rollback bij blue-green?
Zo snel als je router of load balancer kan omschakelen, meestal binnen enkele seconden tot minuten. Voorwaarde is dat blauw onaangeroerd is gebleven en dat je database nog met de oude versie werkt. Daarom verwijder je oude databasestructuren pas als de nieuwe versie zich bewezen heeft.
Bronnen
- Martin Fowler: Blue Green Deployment
- Dan North over de herkomst van de term blue-green deployment
- Cloud Foundry: Using blue-green deployment to reduce downtime
Reacties0
Nog geen reacties
Deel als eerste uw gedachten.
Meld u aan of registreer u om een reactie te plaatsen.