LinkedIn
Twitter
You may have seen the excellent post in our Community here for southbound-side blue-green deployments. If you wish to transition between multiple backends (typically 2) in a controlled fashion, you can leverage @Dino's answer with 2 options outlined: 1) target servers with weights or 2) API BaaS with weights. In this post, I wanted to take a step back and outline a few more options and also include information on northbound-side blue-green deployments.
On the northbound-side, this will allow you to test between variations in the API proxy layer (Edge) as opposed to variations in the backend. One of the best options for northbound blue-green is to use target servers as diagrammed here:
In this proposal, a request would first pass through a first layer proxy with the interface they are familiar with (e.g., /v1/widgets). This proxy would also use target servers with relative weights (see more details here). Based on weights, API call would route to a particular target server with specific API proxy configuration. Note that we cannot leverage proxy chaining here since the proxy chaining feature does not support target servers at this time (thus, this solution requires additional network hops between the MPs-- not pictured above). To change the weights, you would only need to redeploy /v1/widgets to use new weights (you can leverage zero downtime deployments to make this easier). A few additional notes:
a) You'll want to secure the 2nd layer proxies (e.g., /v1/widgets-green and /v1/widgets-blue) so that they aren't accessible outside.
b) The first layer proxy's load balancing feature could be achieved through many load balancers and router software externally available outside of Apigee. The design above is to use Edge to do the same without having to maintain another node and/or system for that feature.
On the southbound-side, there are still the 2 options as Dino clearly proposed (with a nice example to boot). In using target servers, you may want to consider the following option to leverage proxy chaining to save network hops with little latency penalty (i.e., <1 ms to use proxy chaining):
In this example, we're assuming all 3 resources (objects, widgets, and items) will need the blue-green switch on their backends. With this design, only the load balancing proxy requires redeployment to adjust the target server weights (again, you can leverage zero downtime deployments as above).
If your setup is sensitive to redeployments (as is often the case at many organizations), you can leverage API BaaS to dynamically adjust weights, as Dino proposed in his original answer. This solution does not involve any target servers. See the diagram here:
You could also leverage KVMs to do the same. The main drawback vs. the option with target servers is that, in a sense, we're rebuilding the load balancing feature of target servers. You're reassigning target.url to change the backend instead of using target servers. In the process, you lose target server features like failover, health check, etc.
And that's it! I'd really like to hear your thoughts on blue-green deployments both for north and southbound sides in the comments below.
Best,
-Alex
