Zero Downtime Deployment of BusinessWorks Container Edition with Kubernetes — Part 5
Canary Strategy
In my previous posts we created and deployed a Micro Service using TIBCO BusinessWorks Container Edition into Kubernetes (I used Minikube), and then upgraded it using the Recreate,Rolling Update and Blue/Green strategies.
In this post, we’re going to take the original deployment of Version 1.0 (which we rolled back to at the end of the second post) and upgrade it again to 1.1, but this time using the Canary deployment strategy.
With a Canary deployment strategy, we want to deploy a new version of a micro service and route some traffic to it, whilst most traffic goes to the original version. If we see no issues, we can increase the number of new Pods of the new version — taking more and more of the traffic over time.
In this example, we really need more replicas to show it working a little better, so I will deploy our original version with 3 replicas instead of 2. I created this manifest and removed the original deployment and re-deployed this new 3 replica version.
To deploy a Canary version of the application, there’s not a huge amount of work that we need to do to our manifest. Literally all we need to change is the Application name itself! You can add in the Version as a Label, or an Environment label if you wish. In my Canary manifest, all I’ve done is to change the application name, then deployed it using the kubectl apply command below.
This starts a 4th Pod, the 3 original Pods are left alone, the new Pod is started and the Service starts routing traffic to the new Pod on a 4:1 basis:
As you can see from the screenshot — a percentage of our calls are now being routed to our Canary deployment. We can continue to monitor the application and we can decide to scale down the original application, and scale up the Canary application to vary the load between the versions as appropriate.
When we are happy, we can re-deploy the Canary version as the production version just by scaling down V1 and/or deleting the deployment completely.
As in my previous posts — you can watch the corresponding video here to see the Canary Strategy live!
Conclusion
My original intention of this series of posts was to show how you could employ Rolling Updates to existing TIBCO BusinessWorks Container Edition applications with zero downtime. I realised that of course, there’s more than one way to skin a cat (as they say), so it needed to cover off other deployment strategies too.
What I think it shows is how mature Kubernetes really is — but also how mature you have to be as an organisation to be able utilise such powerful functionality.
As Martin Fowler says — “You have to be this tall” to use Micro Services, and this rings true with Container based deployments in Kubernetes — you’ve got to have a proper understanding of how your micro services are interacting with each other and how your deployment practices affect each of those micro services.
Of course, the other aspect I haven’t covered is that all of this should all be automated in your CI/CD Pipeline!
I’m a strong believer that you’ve got to really understand what’s going on under the covers so that you can appreciate and get the best out of your automated pipeline — so when things go wrong — you know how to resolve them.
