Answers: <p>I must admit that I don't quite get the examples your giving. Sure, random numbers will be different between the two environments.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>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. </p>
  
  <p>But aside from that, nothing special compared to, for example, running a separate test environment next to your dev/prod environments.</p>
  
Answers: CC BY-SA 3.0
Answers: 2018-04-20T06:57:19.867Z
Answers: "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.
Answers: Ta Mu
Answers: CC BY-SA 3.0
Answers: 2018-04-20T07:54:09.753Z
Answers: 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.
Answers: AnoE
Answers: CC BY-SA 3.0
Answers: 2018-04-19T22:41:55.320Z
Answers: 2018-04-19T22:41:55.320Z
Answers: AnoE
Body: <p>I find a lot information about the <a href="https://martinfowler.com/bliki/BlueGreenDeployment.html" rel="nofollow noreferrer">blue green deployment</a> pattern but maybe miss a point. Please help me to understand.</p>
  
  <p>Could it be scenarios where you can't successfully duplicate the information flow? </p>
  
  <p>Examples:</p>
  
  <ul>
  <li>Captcha request from a local API; can you ensure same captcha goes to blue and green?</li>
  <li>Randomly generated hardware-based UUID's: blue and green wouldn't get same random number, or?</li>
  </ul>
  
  <p>Or does blue/green mean, that exactly such considerations have to flow as well into the software design?  </p>
  
Comments: CC BY-SA 3.0
Comments: 2018-04-19T12:11:58.093Z
Comments: 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.
Comments: Tensibai
Comments: CC BY-SA 3.0
Comments: 2018-04-19T12:23:37.827Z
Comments: 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.
Comments: Ta Mu
Comments: CC BY-SA 3.0
Comments: 2018-04-19T12:37:37.493Z
Comments: I think they're better asked on chat than on main site
Comments: Tensibai
Comments: CC BY-SA 3.0
Comments: 2018-04-19T12:43:00.017Z
Comments: but, from the original picture it is totally not recognizable about horizontal scalability. Actually, an answer pointing to that is imo a worthful contribution.
Comments: Ta Mu
Tags: <deployment><analysis><patterns>
Title: Limits of, or preconditions for of Blue-Green deployment?
UserDisplayName: Ta Mu
ThreadText: # Limits of, or preconditions for of Blue-Green deployment?
  
  (Asked by: username_0 on 2018-04-19)
  
  I find a lot information about the [blue green deployment](https://martinfowler.com/bliki/BlueGreenDeployment.html) 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?
  
  **Tags:** deployment, analysis, patterns
  
  > **Comments:**
  > **username_1**: 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.  
  > **username_0**: 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.  
  > **username_1**: I think they're better asked on chat than on main site  
  > **username_0**: but, from the original picture it is totally not recognizable about horizontal scalability. Actually, an answer pointing to that is imo a worthful contribution.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2018-04-19. Score: 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.
  
  > **Comments:**
  > **username_0**: "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.  
  > **username_2**: 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.  
  
  ---
  
  