Canaries and rollouts

A ‘Canary deployment’ is the idea that a version of an application can be rolled out to sit alongside a live production service and receive production traffic. If its not obvious, the canary reference is a nod to the old practice of having caged birds in mines to give an early warning of the presence of harmful gas. Should the bird/ new version of the app keel over with its legs stuck up in the air, a miner/deployment team will know that something is amiss and get the hell out. By using labels (see main article), we can easily deploy and discern between different versions of an application and just as easily take them offline again (imagine using a ‘version:1.0’ and ‘version:1.1’ label in this situation). Similarly handy is an option to have kubectl for Kubernetes to automatically perform a rolling update of an application to a new version. When the, surprisingly named, rolling-update parameter is used, the platform will start replacing (one at a time) the pods running the old version of the application with an updated one. The progress of this can be viewed and (even more impressively) it can be interrupted and rolled back to the previous version by a single command. This allows for services to be updated with no interruption from the point of view of the user (assuming the application has been built correctly to support it). Anyone who has read the words ‘restore from tape’ in the rollback section of a deployment plan can be forgiven for having tear or two in their eyes at the moment.