Zero Downtime Deployment of BusinessWorks Container Edition with Kubernetes ? Part 5

Table of Contents

• Canary Strategy
• Conclusion

Canary Strategy

In my previous posts (Part 1, Part 2, Part 3, and Part 4)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 microservice 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 the Version as a Label, or an Environment label if you wish. In my Canary manifest, all I?ve done is change the application name, then deployed it using the kubectl apply command below.

This starts the 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:

Kubernetes Dashboard with Live + Canary Deployed Pods

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 

Conclusion

My original intention for this series of posts was to show how you could employ Rolling Updates to existing TIBCO BusinessWorks Container Edition applications with zero downtime. I realized that of course, there?s more than one way to skin a cat (as they say), so it needed to cover 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 organization to be able to utilize 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 microservices are interacting with each other and how your deployment practices affect each of those microservices.

Of course, the other aspect I haven?t covered is that all of this should 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.