DevOps Patterns and Antipatterns for Continuous Software Updates

By Baruch Sadogursky

Elevator Pitch

So, you want to update the software for your user. What can possibly go wrong?

Join us for some awesome and scary continuous update horror stories and some obvious (and some not so obvious) proven ideas for improvement and best practices you can start following tomorrow.

Description

So, you want to update the software for your user, be it the nodes in your K8s cluster, a browser on user’s desktop, an app in user’s smartphone or even a user’s car. What can possibly go wrong?

In this talk, we’ll analyze real-world software update fails and how multiple DevOps patterns, that fit a variety of scenarios, could have saved the developers. Manually making sure that everything works before sending an update and expecting the user to do acceptance tests before they update is most definitely not on the list of such patterns.

Join us for some awesome and scary continuous update horror stories and some obvious (and some not so obvious) proven ideas for improvement and best practices you can start following tomorrow.

Notes

This talk is a collection of failure stories about software updates with advice on how to prevent those in your systems. As usual with epic failures talks, it’s educational and a lot of fun.

We’ll start by reviewing what are the driving forces behind software updates, how do we update, and why some update multiple times a day while others only update once a year. We’ll continue to review some of the epic fails, including Google WiFi, Knight Capital, CloudFlare, Jaguar and others. The patterns we are going to suggest are Canary Deployments, Observability, Local rollbacks, Feature Flags, and others.