patternMinor
Limits of, or preconditions for of Blue-Green deployment?
Viewed 0 times
bluelimitsforgreenpreconditionsdeployment
Problem
I find a lot information about the blue green deployment pattern but maybe miss a point. Please help me to understand.
Could it be scenarios where you can't successfully duplicate the information flow?
Examples:
Or does blue/green mean, that exactly such considerations have to flow as well into the software design?
Could it be scenarios where you can't successfully duplicate the information flow?
Examples:
- Captcha request from a local API; can you ensure same captcha goes to blue and green?
- Randomly generated hardware-based UUID's: blue and green wouldn't get same random number, or?
Or does blue/green mean, that exactly such considerations have to flow as well into the software design?
Solution
I must admit that I don't quite get the examples your giving. Sure, random numbers will be different between the two environments.
Blue-green means simply to have two nearly identical production environments with some kind of router/load balancer in front. Clients talk to the load balancer, and the LB routes requests to one of the two environments.
To deploy a new version, you provision all machines/services/etc. in the inactive environment, test to your heart's content, and then do the instant switch (on the router) if you're satisfied.
Actually, I don't see anything that requires any precondition at all about this. Obviously, one precondition is that you are at all able to create a second, fully fledged production environment in the first place; and that there is a technical solution that works as a load balancer in the above sense. That may get very complicated if you have a widely distributed system which you want to switch completely at once. That may just become to complex.
But aside from that, nothing special compared to, for example, running a separate test environment next to your dev/prod environments.
Blue-green means simply to have two nearly identical production environments with some kind of router/load balancer in front. Clients talk to the load balancer, and the LB routes requests to one of the two environments.
To deploy a new version, you provision all machines/services/etc. in the inactive environment, test to your heart's content, and then do the instant switch (on the router) if you're satisfied.
Actually, I don't see anything that requires any precondition at all about this. Obviously, one precondition is that you are at all able to create a second, fully fledged production environment in the first place; and that there is a technical solution that works as a load balancer in the above sense. That may get very complicated if you have a widely distributed system which you want to switch completely at once. That may just become to complex.
But aside from that, nothing special compared to, for example, running a separate test environment next to your dev/prod environments.
Context
StackExchange DevOps Q#3911, answer score: 4
Revisions (0)
No revisions yet.