Flags & Migrations

An infrastructure migration is the transfer of data, information, or technology from one place, or system, to another. Teams may do this for a number of reasons, such as to improve scalability and performance, to improve their caching layer, or even when transitioning from an in-house solution to a cloud-based one. 

Infrastructure migrations can certainly be risky and cause headaches for dev teams, but they don’t have to be so cumbersome when done right. Feature flags are a great tool for managing transitions from one infrastructure component to another. 

Most people usually associate feature flags with smaller releases and changes to the physical appearance/UI of their software. But you can also use them to aid in larger scale projects (such as infrastructure migrations) for things like: maintaining data integrity, testing the new system, deploying changes, and more.‍

Here’s how:

Say you have DAO code that can read and write events to your initial database. The first step will be writing a new DAO that uses the same interface, but has the ability to read and write events to the new database you’re looking to migrate to (i.e. DynamoDB). If need be at this point, query your data in the new database. 

Now, you’ll have one implementation of your DAO interface backed by your original database, and one backed by the new one (DynamoDB). Here’s where feature flags come into play.

You can use feature flags to control reading and writing to each database. Your events will be saved in both places–for good reason. You can start writing events to the new database while maintaining the old one should anything go awry. Now you should ensure that the code that reads the events is “enabled” in both databases. This way, you can read the events in both, compare the two results, and log any errors.

Plan the rollout:

At this point, you’ll want to keep the read flag off for everyone, and begin rolling out the write flag instead. Start tracking the performance of the write flags. If it looks like everything is performing as expected, continue rolling it out to more users until you reach 100% of events being rolled out in both your old and new databases. 

Once you’re satisfied with the performance, you can begin turning on reads for the new database. Similar to the write flags, turn these on gradually and track their performance. You’ll want to be especially cognizant of any error that says “DB1 and DB2 events differ.” Fix the issues as needed, and roll out 100% of events to both databases when you’re satisfied with the performance.

Once all of your reads and writes are on for all users, you should migrate all of your old information from DB1 to your new database (DB2). You can then turn off the read and write flags for your old database as well to ensure you are only left with the new one. 

Hopefully the idea of a migration seems a lot less cumbersome and stressful now that you know how feature flags aid in the process. This is a tried and tested method that many organizations have seen great success with. As long as you mitigate errors and bugs as they come in, this process allows you to take full control over your infrastructure migrations with the confidence that you won’t impact your end users in the process.