The build-or-buy dilemma in Feature Management

16 Dec 2024

DevOps

The build-or-buy dilemma in Feature Management

Introduction

 

Organizations invest significant time, often months or even years, into modern application development life cycles. However, deployment can feel like a pivotal moment. While many Continuous Integration/Continuous Deployment (CI/CD) practices aim to simplify and reduce the stress of deployment by making it a regular occurrence, it can still pose substantial challenges and lead to various issues.

To mitigate these challenges, some organizations recognize the advantages of separating code deployments from releases using a technique known as Feature Flagging. This approach allows for gradual and progressive rollouts, enabling changes to be tested with a limited user base in real-world scenarios without a full-scale launch. Such a strategy is particularly beneficial for organizations that have faced significant setbacks from previous rollout issues.

However, it’s not uncommon for organizations to opt for what seems like the easiest route: building feature flag capabilities in-house. While this initial enthusiasm may stem from a desire to customize the solution, it can quickly lead to frustration and complications, undermining the very goal of reducing deployment stress and risks.

Common Pain Points with Homegrown Feature Flags

 

  • Cross-team Development, Collaboration and Visibility

When an organization decides to create an in-house feature flag solution, it typically begins with a single team focused on their specific requirements. This approach makes it challenging to extend the solution to other teams, let alone achieve corporate-wide usage and standardization. Homegrown feature flag systems often struggle to support multiple programming languages, which are common across organizations, and may lack the necessary access control and permissions for safety and security.

Moreover, organizations face uncertainty when they cannot consistently track the status of feature flags. This lack of visibility into how flags are evaluated in production and across different environments can hinder enterprise adoption.

Additionally, organizations often underestimate the effort and time required to create and maintain documentation for the feature flag solution. This documentation is essential for enabling other teams to utilize the system effectively. Unfortunately, it typically demands ongoing work to cover potential use cases and is complicated further by the need for manual updates to the flags.

  • Maintenance and Governance

While developing a custom system may initially seem feasible, it comes with significant maintenance costs, especially as feature flags become a crucial component alongside core applications. Any issues with a homegrown feature flag solution can lead to outages, directly impacting users. This approach ultimately adds another layer of complexity to the application platform, necessitating thorough monitoring and maintenance to ensure smooth operation.

  • Advanced Feature Management

Organizations are creating homegrown feature flag platforms for simple use cases, but they often find it challenging to engineer advanced capabilities such as percentage rollouts, user targeting and segmentation, A/B testing, automated kill switches, ecosystem integration and more.

Leave it to the Experts – LaunchDarkly

 

The lists above can be expanded to include additional pain points associated with homegrown feature management solutions.

It’s essential to concentrate on core application development and address your users’ real needs, rather than investing time and resources into creating a custom feature management solution. Let LaunchDarkly handle that for you.

Intuit, a technology company providing financial management solutions to around 50 million customers, relied on a custom feature flagging system based on configuration files. Developers discovered that updating these files was risky and often led to errors. Additionally, any changes to feature properties had to be made directly in the codebase, which was updated only once a month. As a result, when modifications were made to feature flags, it could take as long as 10 minutes for them to go live for users.

Intuit quickly recognized the benefits of LaunchDarkly. Within just six months, the organization created over 600 feature flags. With LaunchDarkly, teams can easily toggle these flags on and off as needed, ensuring that users only experience the features that have been activated. This has boosted teams’ confidence in the quality of their deliverables.

https://launchdarkly.com/case-studies/intuit/

Whether you’re developing a homegrown feature management solution using a config file or database, or you’re still in the early stages of implementation, LaunchDarkly can help you reach your goals. It offers robust and advanced release management, monitoring, and experimentation capabilities, empowering all teams to deliver and manage their software effectively.

At Vsceptre, we connect people with technology. Contact our specialist at charliemok@vsceptre.com to arrange a free one-on-one consultation session.

Related Articles

The Disruptive Effects of Mobile Application Outages on Large Enterprises in Hong Kong

The Disruptive Effects of Mobile Application Outages on Large Enterprises in Hong Kong

In today’s digital age, mobile applications are essential for large enterprises to connect with customers and drive growth. However, even the most meticulously tested apps can experience outages, leading to significant consequences for both users and the organizations behind them. This article explores the impact of unforeseen downtime, the repercussions on end users and company reputation, and how tools like LaunchDarkly can help alleviate these challenges. Learn how enterprises can uphold application reliability and ensure customer satisfaction amidst unexpected disruptions, leveraging Observability tools with the help of Vscetpre and LaunchDarkly.

Demystifying Log to Trace correlation in DataDog

Demystifying Log to Trace correlation in DataDog

If you have a chance to attend any presentation or public seminars from the APM vendors, you may come across some demonstrations of how easily to jump from trace to log or log to trace to diagnose a slow API call. This is one of the key differentiation of using a siloed approach for monitoring vs true full stack visibility. Often times, the technical details and prerequisites of how to achieve this are omitted from those overview demos. Today I am going to take a more detail discussion of how to ensure your application can achieve the log to trace correlation. We use DataDog as the example monitoring backend in this exercise.