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?
Sudhee, two options for you.
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?
Thanks! @Dino @Prashanth Subrahmanyam is right. I was asking about the API proxies itself, not backend.
@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.
Hi Prashanth
Is there any topic about how to do the same thing at the platform level ?
Thanks,
Reza
I wrote an article here covering options for both north and southbound blue-green deployments. Would love to hear your thoughts.
@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 .
@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.
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.
User | Count |
---|---|
2 | |
1 | |
1 | |
1 | |
1 |