Feature flags are a crucial element for a SaaS platform to continuously deploy and upgrade production and sandbox environment without impacting clients. Software Engineer Prashastha Mudannayake takes you through what feature flags are, and how we use them in WealthOS.
Why feature flags?
Let’s start with a non-techie-ish example to illustrate how feature flags work.
As you may know, modern household electrical systems are designed with individual circuit breakers that isolate electrical circuits in different areas of the house (apart from the main switch that disconnects the house from the electrical grid).
This enables electricians to service/troubleshoot issues in these individual circuits, without taking the entire household off the grid. So, if you want to install a hot tub or add a game room, all you have to do is to add a new circuit breaker and extend the existing electrical system. Electricians can work on repairs without getting electrocuted and the tenants can continue with their regular activities in the rest of the house.
When building an enterprise FinTech platform, we are continuously adding new features and improving existing features. So, having the option to toggle ‘on’ and ‘off’ individual features is hugely beneficial, as it allows engineers to work on features with a minimal impact on end users.
What is a feature flag?
A feature flag is a variable that holds a ‘true’ or ‘false’ value to determine whether a piece of code enclosing a logic or a feature should be executed or not.
Feature Flag Code Segment
The above segment of code is a simple example of a feature flag. The logic of the beta feature will be embedded within the ‘if’ block as mentioned by the comment, and is executed conditionally depending on the value of the variable ‘enableBetaFeature’.
Feature flags can enable or disable features of the software, either when the software is being deployed (deploy-time feature flags) or dynamically when the software is being executed (run-time feature flags).
Deploy-time feature flags allow engineers, testers, and end users to have different deployed configurations of the same software. End users will not be exposed to any ‘work in progress’ features, removing any impact due to ongoing development. While software engineers and testers can continue to refine and test ‘work in progress’ feature on a different deployment.
Once software engineers and testers are confident of the robustness of these new/improved features, the feature can then be enabled on the end-user software deployments.
Instead of setting the value of the feature flag within the code, and going through the pain of manually updating the value of feature flags for each deployment, it is possible to integrate feature flags into the CI/CD and deployment pipelines. This adds to the usability of the deploy-time feature flags by reducing the effort and time required to enable or disable beta features.
Run-time feature flags on the other hand are more product-centric and can be used to do feature re-configurations dynamically during the software runtime. Going back to the household electrical system analogy, we can think of a run-time feature flag as a switch which can be used to turn on and off a light or an electrical appliance.
Run-time Feature Flags vs. Deploy-time Feature Flags
Feature flag implementation at WealthOS
In order to understand how we use feature flags, here’s a quick overview of the usage of the WealthOS cloud-native SaaS (Software as a Service) platform. For each user that is utilising the WealthOS platform (from internal users like developers, quality assurance testers etc. to external customers), we deploy their own instance of an API gateway, a multitude of AWS Lambda functions in a microservice, and an auto-generated API specification. However, all deployments are sourced from a mono repo where developers maintain the code base. The mono repo at a given time contains both stable features and work-in-progress beta features.
We developed the deploy-time feature flag to omit beta features from the deployments made for external users (sandbox and production).
Incorporating deploy-time feature flags into the CI/CD pipeline
By introducing a two-stage process into our existing deployment pipeline, we were able to give the option to omit or include features tagged as beta features from a deployment.
- The first stage was to remove information related to the feature from the API specification document, by introducing a feature flag property to the configuration file which is used to automatically generate the API specification document. However, this alone will not prevent access to the beta feature, since the API endpoint that routes requests to the Lambda function(beta feature) via the exposed gateway endpoint still exists.
- By utilising the capabilities of the AWS SAM CLI’s deploy command, we were able to set a parameter override to successfully disrupt the route between the exposed gateway endpoint and the Lambda function(beta feature) by removing the existing gateway method. As shown in the following diagram. This is done during deployment according to the value assigned to the feature flag.
Exposed vs. Concealed Beta Feature Endpoints
Conclusion
Once successfully integrated into the deployment pipeline, deploy-time feature flags provide the option to include or omit beta features with a simple ‘flip of a switch’ when initialising a deployment. This allows developers to maximise release agility and ensure a minimum impact on end users.
Look out for our blog on run-time feature flag capability, which will be developed in the second phase of feature flags.
Read the original article here.
