Feature Flagging to Reduce Risk in Database Migrations

I won’t say that feature flagging your database migration will make everything easy, but it will make it easier to test it with real, live data (for a subset of your user base), and much easier to roll it back if something goes wrong. I will explain how you can use feature flags to gradually apply a database migration or schema change, while constantly verifying that the new model passes integrity checks. This ensures that the migration can be applied in a controlled manner, with very little risk.

Transcript

1. Feature Flagging to Reduce Risk in Database Migrations By Patrick Kaeding Lead Engineer at LaunchDarkly @pkaeding @launchdarkly
2. About Me & LaunchDarkly • Current: Lead Engineer at LaunchDarkly • Past: Engineer at Atlassian • LaunchDarkly is a cloud-based feature flag management platform • Separate deploying code from releasing features • Manage risk of releasing features • Measure impact (both KPI and Ops performance) @pkaeding @launchdarkly
3. Database Migrations • Sooner or later, it is inevitable • Schema changes • Moving to larger database cluster • Moving from one kind of DB to another @pkaeding @launchdarkly
4. Maintenance window Database Migrations (Bad Old Days) Application Old Database @pkaeding @launchdarkly
5. Database Migrations (Bad Old Days) Old Database New Database Migrate Maintenance window (application offline) @pkaeding @launchdarkly
6. Maintenance window Database Migrations (Bad Old Days) Application New Database @pkaeding @launchdarkly
7. Maintenance Window Approach • Pros – Simplicity – Can always be used (since both code paths don’t need to work at the same time) • Cons – Downtime – If there is a problem, redeploy old code and restore from backup – All or nothing @pkaeding @launchdarkly
8. Zero-Downtime Approach Database Migrations (The Less Bad Days) Application Old Database Write Read @pkaeding @launchdarkly
9. Zero-Downtime Approach Database Migrations (The Less Bad Days) Application Old Database Write Read New Database @pkaeding @launchdarkly
10. Zero-Downtime Approach Database Migrations (The Less Bad Days) Application New Database Write Read @pkaeding @launchdarkly
11. Zero-Downtime Approach • Pros – No downtime – If there is a problem, you can keep running from the old database/schema • Cons – All or nothing @pkaeding @launchdarkly
12. The Feature-Flagged Approach Database Migrations (Modern Times) Application Old Database Write Read @pkaeding @launchdarkly
13. Feature-Flagged Approach Database Migrations (Modern Times) Application Old Database Write 100% Read 100% New Database @pkaeding @launchdarkly
14. Feature-Flagged Approach Database Migrations (Modern Times) Application Old Database Write 100% Read 100% New Database @pkaeding @launchdarkly
15. Feature-Flagged Approach Database Migrations (Modern Times) Application Old Database Write 100% Read 100% New Database @pkaeding @launchdarkly
16. Feature-Flagged Approach Database Migrations (Modern Times) Application Old Database Write 100% Read 100% New Database @pkaeding @launchdarkly
17. The Feature-Flagged Approach Database Migrations (Modern Times) Application New Database Write Read @pkaeding @launchdarkly
18. Feature-Flagged Approach • Pros – No downtime – Gradual rollout allows you to monitor – You can roll back just as easily (or partially roll back) – Compare results with live data • Cons – Longer period for both databases to be operational @pkaeding @launchdarkly
19. Demonstration @pkaeding @launchdarkly
20. What about… • Schema changes? New fields? Restructured data? • Which users get the new DB? • Open source alternatives? @pkaeding @launchdarkly
21. Questions • pkaeding@launchdarkly.com • @pkaeding • @launchdarkly • https://launchdarkly.com • Blog article: http://kaed.in/db-blog • Demo code: http://kaed.in/dbcode @pkaeding @launchdarkly