Der er så mange implementeringsstrategier at vælge imellem i dag, og efterhånden som tiden går, vil der bare blive flere. Det sagt er to af de mest almindelige implementeringsstrategier, der aktivt bruges af nogle af verdens største virksomheder i dag, Canary og Blue-green implementeringsstrategier.
Når du sammenligner Blue-Green deployment med Canary, handler det ikke kun om hastighed eller enkelhed. En af de vigtigste faktorer at overveje, når du vælger mellem disse strategier, er nedetiden ved udrulning.
For at minimere nedetiden ved udrulning og sikre en problemfri overgang, når du udrulles dine opdateringer eller ændringer, er det afgørende at vælge den mest passende mulighed mellem Canary deployment og Blue-Green.
Lad os derfor dykke ned i, hvad hver strategi tilbyder, samt sammenligne Blue-Green deployment og Canary direkte, og dele vores egne erfaringer med begge tilgange.
Hvad er Blue-Green Deployment, og hvad tilbyder det?
I Blue-Green deployment strategien kan en ny version af et program udrulles straks efter, at det er blevet testet og valideret. Det skyldes de to identiske miljøer: det blå og det grønne miljø, hvilket er grunden til navnet Blue-Green deployment.
Det fungerer, fordi det ene miljø er aktivt og det andet inaktivt. Det betyder, at den nye version af programmet kan udrulles til det inaktive miljø (lad os sige det grønne). Da disse to miljøer er fuldstændig identiske med hensyn til ressourcer, infrastruktur og konfigurationer, kan eventuelle problemer i opdateringen løses, før den udrulles fuldt ud.
Når opdateringen er blevet testet, og udvikler bekræfter, at den virker, skifter man live-trafikken til dette inaktive miljø. Dette gør det inaktive miljø (det grønne) til det aktive miljø og det tidligere aktive miljø (det blå) til inaktivt.
Nu bliver det inaktive blå miljø standby og kan bruges til at teste nye opdateringer, mens det grønne miljø er aktivt og kører den nyligt udrullede opdatering. På denne måde er der praktisk talt ingen nedetid, da trafikken ændres øjeblikkeligt til det inaktive miljø.
Hvis opdateringen har problemer, kan du bruge rollback-funktionen til at skifte tilbage til den ældre version af dit program. Men hvis der opstår problemer, når udvikler er begyndt at arbejde på en ny opdatering i det inaktive miljø, er det ikke længere muligt at rulle tilbage til dette miljø, da den ældre version ikke længere er tilgængelig her.
Selvom mange virksomheder bruger denne strategi, kan man se et eksempel på dette i praksis hos Spotify. Da Spotifys tjenester skal være tilgængelige 24/7, har det altid det inaktive reservemiljø klar, når nye opdateringer udrulles.
Hvad er Canary Deployment, og hvad tilbyder det?
Den vigtigste forskel mellem Canary deployment og Blue-Green er, at i stedet for at have to miljøer, hvor opdateringer udrulles på én gang til alle brugere, frigives opdateringer i Canary deployment strategien først til en lille gruppe brugere.
Hvis opdateringen har problemer, oplever kun en lille del af brugerne det og giver feedback. Når problemerne er løst, udrulles opdateringen til en større gruppe brugere, som giver feedback til udvikler, hvis de oplever problemer.
Denne cyklus gentages med trinvist større dele af brugerne, og alle problemer med opdateringen løses, indtil opdateringen udrulles til 100% af brugerne. For eksempel ville opdateringen først blive udgivet til 2%, derefter 25%, derefter 75% og til sidst 100% af brugerne.
Denne graduelle udrulning i Canary deployment giver en mere kontrolleret og fleksibel udrulning, så udvikler kan teste funktioner og opdateringer i et kontrolleret miljø, hvor kun en lille del oplever potentielle problemer.
Til sidst tilbyder Canary også en lignende rollback-funktion. Men da udrulningen foregår gradvist og i faser, foretages rollback i Canary også gradvist og i faser, indtil en stabil version er nået.
Et velkendt eksempel på denne udrulningsstrategi er Netflixs brug af Canary sammen med et værktøj kaldet Chaos Monkey, som med vilje introducerer fejl i deres system. Hvis en fejl påvirker canary-miljøet, kan Netflix-teamet analysere, hvordan systemet reagerer, og tilpasse sig efter behov. På denne måde kan Netflix verificere, at opdateringen forbliver stabil og resilient, selv under ugunstige forhold.
Blue-Green Deployment vs. Canary
Begge disse udrulningsstrategier tilbyder deres egne unikke fordele, men de har også deres begrænsninger. Det er derfor vigtigt at veje fordele og ulemper ved Blue-Green deployment og Canary, før du tager en beslutning.
Hvis du stadig er usikker på, hvilken du skal vælge efter dette afsnit, har jeg også inkluderet vores erfaringer med disse to strategier og det, vi lærte, i slutningen af denne artikel.
Reducering af nedetid
En af hovedfokuserne i denne artikel er nedbringelses af nedetid ved Blue-Green-implementering sammenlignet med Canary. En af Blue-Green-implementerings styrker er dens hastighed, da du kan implementere din applikationsopdatering eller funktion øjeblikkeligt ved at bruge dets to miljøer.
Canary's gradvise implementeringstilgang giver derimod minimal nedetid, da ikke kun en lille gruppe brugere oplever problemerne, men da feedback gives på hvert trin, kan fejlfinding udføres meget hurtigere og uden nogen nedetid.
Derudover, selvom begge tjenester tilbyder rollback-funktioner, er Blue-Green-implementerings rollback-funktion øjeblikkelig og giver udviklere en pålidelig backup i tilfælde af større problemer. Det er dog værd at bemærke, at en backup-version ikke vil være tilgængelig, hvis der arbejdes på en nyere version i det inaktive miljø.
Canary's rollback-funktion kan kun bruges gradvist, på samme måde som implementeringsprocessen. Den er dog altid tilgængelig, da den ældre, stabile version ikke afhænger af det miljø, hvor nyere opdateringer testes og udvikles.
Med hensyn til nedbringelse af implementeringsnedetid er Canary-implementering overlegen over for risikokontrol og granuleret kontrol sammenlignet med Blue-Green. Men hvis vi rent faktisk kun overvejer nedbringelse af nedetid, er Blue-Green det bedre valg, da skiftet er øjeblikkeligt.
Det er dog vigtig at overveje andre faktorer end nedbringelse af nedetid, når man sammenligner Blue-Green-implementering og Canary-implementering.
Applikationstype
Generelt kan vi dele applikationer ind i transaktions-tunge eller indholdsbaserede applikationer. For transaktions-tunge applikationer er Blue-Green-implementering et meget bedre valg, da høj servicetilgængelighed og minimal nedetid er en prioritet. Det er derfor, Blue-Green's øjeblikkelige skiftning og øjeblikkelige rollback-funktioner giver det fordele over Canary.
Indholdsbaserede applikationer afhænger derimod ikke af realtidstransaktioner. Da disse applikationer typisk bruges til sociale medieplatforme og brugerengagementsservices, er Canary en meget bedre strategi, da du kan udrulles opdateringer gradvist og modtage feedback kontinuerligt på hvert trin.
Infrastrukturomkostninger
En anden vigtig overvejelse ved valg mellem Blue-Green-implementering og Canary-implementering er omkostninger. Naturligt vil omkostningerne være højere ved Blue-Green-implementering, da to separate miljøer skal vedligeholdes.
Det er derfor, Canary's enkelt produktionsmiljø er en meget mere omkostningsvenlig mulighed, hvilket gør det mere velegnet for mindre teams eller mindre ressourcekrævende applikationer.
Skalerbarhed og langsigtet vedligeholdelse
Til sidst kan Blue-Green-implementeringer skaleres, men vedligeholdelse af to komplette miljøer for storskalerede applikationer kan være ressourcekrævende og komplekst. Over tid kan styring og vedligeholdelse af dublerede miljøer tilføje betydeligt overhead, især for applikationer med kompleks infrastruktur.
Dette gør sammenligningen mellem Canary-implementering og Blue-Green med hensyn til skalerbarhed og vedligeholdelse ret simpel at beslutte. Med Canary-implementering er skalerbarhed ofte enklere og mere omkostningseffektiv, da det ikke kræver dublerede miljøer.
I stedet fokuserer det på skalering inden for det primære miljø ved gradvist at udvide brugerbasen, der udsættes for nye ændringer. Dette setup er meget mere håndterbart på længere sigt, da det reducerer infrastrukturkompleksitet og forenkler vedligeholdelse.
Cloudzy's erfaringer med Blue-Green Deployment vs. Canary Deployment
Når vi yder DevOps-tjenester til klienter, forstår vi, at kundetilfredshed, høj tilgængelighed og minimal nedetid er kritisk for deres forretningssucces. I et særligt tilfælde kontaktede en kunde os for at hjælpe med en større infrastruktuopdatering. Teamet skulle beslutte mellem Blue-Green-implementering og Canary-implementering for deres system.
Efter meget overvejelse besluttede vi først at prøve Blue-Green-implementering, da det tilbød praktisk talt ingen nedetid. Vi oprettede et identisk grønt miljø og forberedte os på at udrulles opgraderingen. Der var meget pres, da al trafik ved tryk på en knap ville blive skiftet til det grønne miljø, og som udviklere ved, uanset hvor meget du tester disse ting, er det stadig noget af et lotteri, hvordan det går.
Heldigvis gik alt godt. Overgangen var glat som smør, og vi havde næsten ingen problemer. Over tid, som vores klients tjenester og brugerbase voksede, skulle vi udrulles nye funktioner, og debatten om Blue-Green versus Canary opstod igen.
Denne gang var det dog ikke særlig meget af en debat. Disse var relativt mindre funktioner og bestemt ikke på samme skala som infrastruktureopgraderingen. Så naturligvis valgte vi Canary, da vi kunne udrulles funktioner til små dele af vores klients brugerbase og løste eventuelle problemer gennem brugerens feedback.
Det var bestemt det rigtige valg, da vi selvom vi ikke havde større problemer, nogle mindre problemer dukkede op, som blev rapporteret af de 5 procent af vores klients brugerbase, som funktionen havde været udrullet til.
På Cloudzy tror vi på styrken i tilpassede løsninger. Uanset om din virksomhed har brug for pålideligheden fra Blue-Green-implementering eller fleksibiliteten fra Canary-implementering, har vores DevOps-team erfaringen og viden til at implementere den bedste strategi for din infrastruktur. Kontakt os her i dag for at lære, hvordan vi kan optimere din implementeringsproces og holde dine operationer i gang uden problemer.
Når vi taler om VPS, tilbyder vi nogle af de laveste takster i VPS-industrien med funktioner såsom over 12 placeringer verden over, dedikerede internetforbindelser op til 10 Gbps, enterprise NVMe SSD-lager, kraftfulde 3,23 GHz turbo-hastigheds AMD EPYC-processorer og 99,95 procents oppetid. Se vores VPS-priser for mere information.
Afsluttende tanker
I sidste ende kan man ikke rigtig sige, at det ene er bedre end det andet på nogen væsentlig måde, når man diskuterer Canary-implementering versus Blue-Green-implementering. Det handler blot om use cases og hvilken, der bedst passer til dine specifikke behov.
Ofte stillede spørgsmål
Hvad er den vigtigste forskel mellem blue-green og canary deployments?
Den vigtigste forskel mellem Blue-Green og Canary-implementeringsstrategier ligger i, hvordan opdateringer frigives. Blue-Green-implementering bruger to identiske miljøer, hvor opdateringer anvendes på det inaktive, hvilket giver mulighed for øjeblikkelig skiftning med praktisk talt ingen nedetid. I modsætning hertil frigiver Canary-implementering opdateringer gradvist til en lille gruppe brugere først, overvågning for problemer, før man gradvist udrulles til hele brugerbasebasen.
Er Blue-Green deployment eller canary deployment bedre til at reducere nedetid?
Blue-Green-implementering er generelt bedre til at reducere nedetid, fordi det giver mulighed for øjeblikkelig skiftning mellem miljøerne. Dette minimerer eventuelle forstyrrelser. Selvom Canary-implementering også sigter mod at minimere nedetid, gør det gennem en gradvis udrulning, der kan involvere nogle mindre, lokaliserede problemer, der kun påvirker en lille del af brugerne.
Hvad er omkostningsovervejelserne for blue-green vs. canary deployments?
Blue-Green-deployments er typisk dyrere, fordi de kræver to komplette miljøer. Canary-deployments er mere omkostningseffektive, da de ikke bruger duplikeret infrastruktur. Opdateringer udrulles i det primære miljø, hvilket gør dem til et bedre valg for mindre teams eller mindre ressourcekrævende applikationer.
