4

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:

  • 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?

Improve this question
4
  • Your cases are already existing out of blue/green deployments, any application deployed on a cluster of machines will experiment them. As such I don't get what your question is about, if you don't already handle horizontal scalability, blue/green is not an option at all anyway.
    – Tensibai
    Commented Apr 19, 2018 at 12:11
  • But, this is a good and clear precondition which was not obvious to me: "you have to master horizontal scalability to enable blue/green!" Thanks. Also stupid questions help to learn if answered towards missing understanding.
    – Ta Mu
    Commented Apr 19, 2018 at 12:23
  • I think they're better asked on chat than on main site
    – Tensibai
    Commented Apr 19, 2018 at 12:37
  • but, from the original picture it is totally not recognizable about horizontal scalability. Actually, an answer pointing to that is imo a worthful contribution.
    – Ta Mu
    Commented Apr 19, 2018 at 12:43

1 Answer 1

Reset to default
4

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.

Improve this answer
2
  • "have two nearly identical production environments" in my understanding blue green also implements a continuous sync of the live production data so that you can have zero downtime as you do not need to copy over latest data which changes every second in high-traffic environments.
    – Ta Mu
    Commented Apr 20, 2018 at 6:57
  • Yes, of course, @Peter - e.g., if there is an Oracle DB or whatever in the background, then you will have to think about how to sync those as well (online hot standby), -or- have two DBs (separate data but same schema), one for playing and one for production, where you don't sync the actual data (maybe you have not enough storage to keep both, or you are not allowed due to data security/confiendiality and so on). This is nothing special about blue-green though.
    – AnoE
    Commented Apr 20, 2018 at 7:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.