Using Feature Flags to Move from a Monolith to Microservices

In recent years, companies accelerating digital transformation and innovation have been decomposing legacy monolith applications and moving to distributed systems architectures (almost universally spoken about as microservices). If you and your team have decided to undertake this migration, you’re likely excited about the compelling upsides of a distributed architecture. Maybe you’re considering how you’ll execute this migration to a distributed system — while still delivering value to your customers. It’s a meaty challenge! A phrase often used to describe this process is that it’s like changing a tire on your car while driving down the road. 

I’ve participated in a few successful migrations to distributed systems, and in my view there are a few essential components:  

• A well thought out technical strategy 
• Skilled technical leaders
• Feature flags

Why feature flags? Feature flags allowed my team to migrate a predefined set of traffic or users to our new distributed platform and do granular segmentation of our product and its features. The use of feature flags accelerated our migration by allowing us to test everything against our production services and de-risked having spikes in engineering emergencies. Any new feature or customer journey that hit any of our new microservices could be rolled back at a moment’s notice.

Feature flags and progressive delivery allow you to put a feature or a new bit of code that you want to expose to a specific audience behind a flag that you can quickly turn on and off. While this is great conceptually, the devil is always in the details around how to put feature flags to work during your migration. Often the lion’s share of the work is done before you ever insert a flag in your code or ramp your traffic allocation for your new feature to your test group. 

This is the work to analyze your current system, find areas that you can discreetly migrate, and get your organization aligned on the sequencing of migration.  Creating and aligning on the plan for migration is a significant task!  Feature Flagging is at the root of those conversations and if the plan is crafted well, writing feature flags and turning them on is actually the easiest part of the process. 

I want to share a few key things I learned during the process of migrating a product to a distributed system with feature flags. Hopefully some of what I’ve learned can help you accelerate your own migration and increase the chances of a positive outcome during your migration.

Incremental migration is key

One of my biggest learnings from past migrations: you need to obsess about how to break down your product into smaller and smaller chunks. 

Big bang migrations are not your friend, but it’s often hard to know how to approach finding small areas of your product to migrate. 

As with monolith to microservices migrations, there is lots of amazing content about how domain-driven design and domain modeling can help simplify your software by organizing your product around your business domains. I’ll take you through a quick example of how I might approach breaking up a simple domain into feature flag components below.  

Let’s use a fictional online retailer that sells apparel in every country on the globe. Let’s say you’ve identified a “checkout” domain as a core domain that you want to think about migrating to microservices. What are all the ways you can break down your product and the features you provide your customers in your domain? 

Well, you’re a global online retailer, how about slicing by country?

Can you divide your checkout experience by the types of products you sell that you could use a feature flag on?

How about segmenting by the number of products in a checkout?

How about flagging by shipping or payment type?

The bigger your matrix, the more opportunities you have to use feature flags to mix and match the user journeys that you can migrate or invent to route traffic incrementally from your monolith to your new distributed system via feature flags while still maintaining functionality for customers.

Start with the things that have high business value and change frequently 

If an area of your product is changing rapidly, you’re likely going to have developers with current context available to help with migration. A team with fresh context coupled with a high rate of change increases your chances of finding opportunities to flag off an area and migrate it.  

Leveraging the matrix we developed above, you can start to identify things like high-value geographies, features with a high rate of code change/updates, and potential new clothing releases as possible dimensions to segment your product. You can even invent a new consumer journey that could help you artificially add a new dimension to your matrix.  

Always keep in mind that the system you have today is making you money. To minimize impact to your current customers, leveraging targeted feature flags (rolling out features to granular slices of your audience) enables you to get creative and maintain the flexibility to balance value delivery, risk, and priority across your product while you migrate away from your monolith that is still serving your customers.

Foster shared ownership with your business stakeholders

One of the hardest parts of any migration out of a monolith is turning off the old code and killing maintenance of those old features. Once you’ve moved 80% of a feature or old business system to your new platform it can be difficult to cut the cord on the last 20%.  Often, there are features that still provide some value, but not enough to bring with you to your new systems, or that last 20% doesn’t have funding or a team to migrate it, so it sticks around as a perpetual thorn in your side. 

Getting savvy about how to convince your business partners to raze that bridge when the time comes is key. Start thinking about that last mile before you get there. One of the most effective ways to do this is a simple profit and loss for operating your flag and all of the legacy code it is keeping alive. Plan your strategy for the last mile before you turn on your first feature flag!

As you get more and more comfortable with rolling out code with feature flags, start to take one step further toward progressive delivery and start to roll out ownership of that feature flag and its outcomes to the business stakeholders who care most.

Your feature flag is providing immense value for your business partners by creating a bridge out of your monolith, but that can be a hard bridge to burn if there is still value in your legacy system that you can’t or don’t want to migrate. 

Some of the metrics I’ve tracked to make a case for retiring legacy systems:

• Percentage of development cycles dedicated to maintaining old things vs. building new things 
• Revenue attributed to legacy systems vs. engineering overhead (typically pretty easy to track and calculate) 
• I’ve even used low eNPS scores that cite having to maintain legacy systems as being a potential engineering retention concern as a key metric

Be creative, find your metric, and be a squeaky wheel!  

Is your organization planning or in the midst of a migration to a distributed architecture? Are you planning on using feature flags?  I’d love to hear about your experience!  Twitter, LinkedIn

If you are interested in getting started with progressive delivery, you can sign-up for a free Optimizely Rollouts account.