How to implement Blue-green deployment with Apigee Edge?

[sudheendras]

Apigee Edge supports a zero downtime deployment, wherein a new revision of the API is deployed to an environment without impacting any applications. The problem with this approach is, once the new revision is in production, every application uses it. If something goes wrong (in API proxy or in my backend) all the applications are impacted. So I was wondering if I can implement a blue-green deployment by allowing a smaller % of production apps use the new revision? And then slowly increase this % ... Any thoughts?

[DChiesa]

Sudhee, two options for you.

• You can do this with TargetServers. Check out this page, and specifically look for the Weighted load balancing option. This requires you to modify the TargetEndpoint when you want to change the weights.
• I've also implemented an approach that does similar, but without using TargetServers. It selects a target url dynamically, based on a JSON array read from BaaS. The proxy uses ServiceCallout to read the array of URLs from BaaS, including the associated weights for each; and then it uses a JavaScript callout to select a target using a weighted-random selector.
  Just change the BaaS entry to modify the weight %. No need to modify the proxy or the target endpoint within it. There is a 10-second cache employed on the weights.

[ksprashu]

Interesting thread @sudheendra1 and good idea with the target servers @Dino.

From what Sudhee has asked, seems like he wants a blue-green deployment at the API level. However what you have mentioned seems like it will work very well for a blue-green deployment of the backend. Correct me if I am wrong. This doesn't help with the APIs itself - though is there a case for this at all?

[sudheendras]

Thanks! @Dino @Prashanth Subrahmanyam is right. I was asking about the API proxies itself, not backend.

[ksprashu]

@sudheendra1 well, since the Apigee layer supports zero-downtime deployment, we could use that to rollback to a previous version.

What I mean to say is that we might not need to do a limited release style like you have asked. We release the new API version to everyone as usual. In case we start seeing issues, then we switch back to the previous version.

I don't see an option to reverting to a previous revision using zero-downtime, so we could create a new revision as a copy of the previous revision and deploy that using zero-downtime.

Of course it still does not help with limiting the number of consumers that are exposed to the faulty API.

[#6]

Hi Prashanth

Is there any topic about how to do the same thing at the platform level ?

Thanks,

Reza

[akoo]

I wrote an article here covering options for both north and southbound blue-green deployments. Would love to hear your thoughts.

[#8]

@Dino I have a similar query :

I am on 4.17.01 .I want to uprade to 4.17.05. I dont want to mess existing server .Hence would want a blue green deployment .

But for data migration from DB i face two challenges:

a) schema changes from source to target DB.

b) i.p. or FQDN name replacement after copying data from source to target cassandra DB.

Could you please help me here .

[6493]

@DChiesa @sudheendras Resurrecting this thread. Is there any published canary or blue green deployment models as I assume this would have been requested by multiple customers? The idea is for limited folks to experience the newer version of the API before complete load and without changing the URL.

[dchiesa1]

Yes, the approach is the same as what I described, except, BaaS is no longer (rest in peace). 

So you need some other way to store the targets and weights.  The KVM is a good choice for this.