Feature Flagging to Reduce Risk in Database Migrations
Download as PPTX, PDF1 like825 views
The document discusses the implementation of feature flagging to mitigate risks associated with database migrations, highlighting its advantages over traditional methods. It contrasts maintenance window approaches, zero-downtime strategies, and feature-flagged migrations, underscoring the benefits of no downtime and the ability to monitor impact during gradual rollouts. It also addresses considerations like schema changes and user rollouts in the context of these migration strategies.
Feature Flagging to Reduce Risk in Database Migrations
- 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
- 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