Feature Flags – The Great Experiment

Add one more to if that is a feature or bug; is that a feature, bug, or flag?

By Ravi Lachhman
October 21, 2019

Building software is a great experiment. Many times we are required to do what has not been done before; this is core to innovation work. Though a lot of the iteration and experimenting tends to happen before software is shipped. Building something from scratch or even jumping into an older project mid-stream requires lots of iteration.   

Once we deploy, for many software engineers the experimentation on the existing tends to drop off and onwards to the next set of features in the backlog. Product owners/managers typically collect feedback to help prioritize the next set of features. From a software engineering perspective this can feel a little “chicken or egg-ish”; without a feature actually deployed to get feedback on how do we if know we are on the mark? 

As a software engineer, I want to put something out in the wild to get feedback and see adoption or lack of adoption and pivot. Easier said than done without the help of robust pipelines (don’t worry your friends at Harness are here to help). Enter the world of Feature Flags or Feature Toggles that allows us to experiment with the concrete. We now can deploy a subset of new functionality to specific users or infrastructure to get feedback on concrete features and/or infrastructure changes. Effectively dipping our toes to see how our ideas are accepted or if additional polish is needed.

Toggle the Flag

Feature Flags can go by different names by how they are implemented. I was introduced to Feature Flags a few years ago by accident. Before setting my iPhone to automatically update the installed apps, I would navigate to the AppStore after some time to update my apps on at a time. One evening I saw that my FaceBook App was over a gigabyte which was very large. I texted one of my software engineering buddies and his update was 350 MB or so and he told me I was most likely in a Dark Launch Test. Talk about A/B testing on steroids! 

If you are unfamiliar with what an A/B test is, A/B tests are hypothesis-based tests with two (or more) variants.  Those who follow stringent A/B testing definitions are only testing two variants which could include a large number of features versus the control. 

With the addition of a Canary Release strategy, the pieces are in place to have the ability to release to a small subset of instances or users in a safe manner.  Feature Flags bring in programmatic ways to expose or subtract functionality from users. As a software engineer, this is very exciting because we can eradicate the “chicken or egg-ish” mindset and get our ideas into the wild faster. 

The burden of software engineers continue to increase. In part two of our Service Mesh series, we dipped into the point that software engineers are starting to be expected to be experts in areas not traditionally handled by development teams, e.g infrastructure.

Infrastructure Feature Flags

With the rise of codification in traditional infrastructure and the availability of cloud-native infrastructure, our software engineering teams are now faced with “run what you write” team structures. Making widespread infrastructure changes can happen with a few clicks or some crafty YAML files and a CLI or two. 

Application infrastructure is very complex and having good distributed system skills on the ever-increasing and granular cloud native landscape is difficult. Building for scaling and uptime requirements while making prudent changes can be seen as rolling the dice sometimes, but Soak Testing can help us there. 

Especially with items that have significant impacts, Soak Testing is important. If you are unfamiliar with Soak Testing, Soak Testing is performance/load testing at peak load for a long duration to observe behavior.  

Performance/perf environments are not new things. Though they can be seen as expensive only needed for certain types of architectures; for example, a high load / low latency messaging system. Today with our applications becoming more distributed and the ease of elastic infrastructure, performance and soak testing are becoming more the norm so flip the infrastructure flag.

Get me a Feature Flag

If looking at implementing a specific feature flag for a specific language, there are many projects and frameworks out there to get you on your way. By simply Googling for “feature flag for XYZ language or infrastructure” would return some salient results. 

There are platforms that are purpose-built for Feature Flags. Honorable mentions are Launch Darkley, Split IO, and Airship. With the rise in commercial vendors, a proliferation of Feature Flags are enhancing development in software teams. 

Even our friend Kubernetes itself allows administrators to turn on or off certain features with Feature Gates. With so many Feature Flags around us, a contemporary argument against feature flags though with ease of implementation can have Feature Flag sprawl [remember containers are the new VM sprawl?]. The sprawl argument can be applied to most technologies and as we go along the Feature Flag journey will get better with time as practices become more mature. Don’t be afraid to experiment.

Experiment Away with Harness

Having a robust pipeline is important when working with Feature Flag based teams. With every flag or toggling, you are effectively increasing the number of deployments. At Harness, we develop our platform with Feature Flags internally and embrace the benefits of this new paradigm. Potentially if using the Harness Platform, you can leverage Barriers to help synchronize different Workflows inside your Pipeline.  To supercharge your deployment experience today, sign up for Harness today! 

Cheers,

-Ravi

➞ Back to Blog

Leave a Reply

avatar
  Subscribe  
Notify of