How a Feature Flags Portal Helps Businesses Manage IT Products
We continue to talk about feature flags (FF) — switchers in the code that start and deactivate product features. This time we’d like to tell you about our concept — a Feature Flags Portal that allows business customers to manage the FF modes, and therefore also the product features.
Our first article on Feature Flags discusses how this tool helps speed up the launch of new features, increase the product competitive ability and generally simplify the team processes. Now we have launched the pilot production of a portal for managing feature flags. And we’d like to tell you about this decision.
Feature Flag is an IF-statement that runs part of a code when a certain condition is met. The code can be enabled or disabled by the developer or by more complex parameters such as schedule or the user level of access. Or conversely, the feature is disabled if the system load exceeds the specified cutoff.
The idea behind the Feature Flag Portal is to allow product owners to either enable or disable functions without involving the development team. On the portal, a customer sees only those functions that are ready for acceptance and implementation. For a user, this is a guide to action: to test or to enable a feature set. And at the right moment, the customer can independently switch the flag, enabling the function in the product to be activated.
Such an operation principle helps to change the development teamwork style, which enables micro-releases and removes the need for a delivery agreement with the customer. The task is put on prod as soon as it’s ready. In turn, the customer manages the acceptance and implication of features on prod. Everyone does their job without needing to bother each other.
A basic feature set allows users to switch flags and monitor the status of all features centrally. Later, we plan to add the possibility to remove irrelevant flags from the list, group them by different filters, and display analytics. Then, features can be launched with configurable parameters, for example, with an indication of when the date should be enabled or disabled.
How the portal helps a business customer:
A/B research and beta-tests: You can lay out a strategy for dividing users into the logic of switchers. Thus, part of the audience will see a new feature set, and the rest will work with the main version.
Separative access to functions: Switchers can automatically enable and block functions for different users. For example, to connect paid features or run a trial mode for new customers.
Crash protection: System switchers are allowed to enable or disable the entire product components. For example, if the load exceeds a certain critical level that causes problems in the external service that is connected to your product.
Ultimately, switchers bring product management closer to business needs. With a simple switcher of functions at hand, a customer can monitor the status of the product on the fly.
Portal architecture
The MVP version of our portal was a simple web page that displayed the statuses of the product functions. The settings were kept in a simple configuration file.
When the idea caught on, the MVP grew into a compact product of four modules:
- Switchers Management Microservice contains all the logic for their processing. Microservices receive the flag configuration at startup from configMap for their namespace and store it in the local memory. If flags are enabled or disabled on the portal page, the agent changes all configMaps, and microservices update their local configuration via feedback.
- Front-end Module enables and disables switchers.
- Agent provides data consistency in local storage, which replaced the config file with settings.
- Starter (optional) allows the testing of a feature set of each switcher before switching.
Most importantly, our portal is a Cloud Native product that was originally developed for use in microservice applications in the Kubernetes infrastructure. So it’s compatible with any product, regardless of the platform it was written on.
Since we have ready-made SDKs for .NET and Java, our teams can quickly launch the logic of working with feature flags in their products. This includes not only a switching mechanism, but also the high-level context of use, meaning that the feature doesn’t switch at the moment when using, as well as preventing the process from crashing. Besides, these SDKs provide our customers the opportunity to experiment with the portal in their product.