In this episode, Edith and Paul dive into the question of specialization. They discuss the pros and cons of working with specialists vs. generalists, and how your decisions in this area can have a wide ranging impact on your product and company. This is episode #25 in the To Be Continuous podcast series all about continuous delivery and software development.
I sat down with LaunchDarkly Lead Software Engineer Patrick Kaeding to get his take on feature flags for the back-end and how feature flagging works with microservices.
Andrea: How does feature flagging help in back-end projects?
Patrick: It helps in general to be able to rollout to a small set of canary users and see if things go wrong. You can gather feedback from performance metrics or error logs. You can give a smaller customer access to the new feature or even a group of customers who know they are testing out something bleeding edge. Then you can make changes and react to the feedback and then roll it out to all users or roll it back. This helps mitigate risk and lets everyone sleep better at night.
Andrea: What was it like before you used feature flags?
Patrick: You would have to make a change – and test it of course, that part hasn’t changed – but then you would release it out to all of your users. You’d be watching everything to make sure nothing went wrong – and it would be a lot more stressful. You might have to time your deploy for a low traffic time, which meant staying up late on the weekend to be able to do the deploy at that time. And if something went wrong, you’d have to rollback the deploy. And if there’s any sort of data model change, sometimes rolling back to the old code is easier said than done. You might have to make sure you have a reverse migration in place and that adds a whole lot of complexity. Of course with feature flagging you still need to make sure both code paths still work in the data model. That’s still something you have to think about.
There comes a time in every developer’s life when you realize you need to migrate from one database to another. Maybe you started off with MongoDB, and it was great while your app was small, but it just can’t handle the load now that your made it to the big leagues. Maybe its time you bit the bullet and put that huge events database in DynamoDB (or Cassandra, or…).
Moving databases is no small task, but it doesn’t need to be so risky.
One of the common misconceptions is that feature flags are only useful for new features, or for cosmetic changes. It turns out they are extremely useful for doing things like 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.