18 Aug 2017

Risk Reduction and Harm Mitigation

Risk Reduction is trying to make sure bad things happen as rarely as possible. It is anti-lock brakes, vaccinations, clothing irons that turn off by themselves, and all sorts of things that we think of as safety modifications in our life. We are trying to build lives where bad things happen less often.

Harm Mitigation is what we do to make sure that when bad things do happen, they are less catastrophic. Fire sprinklers in buildings, seat belts, and needle exchanges are all about making the consequences of something bad less terrible.

What does that mean for a DevOps world where our risks and harms are very different? Charity Majors says we shouldn’t split the world into developers and operations, but into product and infrastructure—and I think that’s a useful way to think about risk too.

Product risk is problems that users experience. We can usually predict and mitigate the danger by testing and being aware of common failings. For example, we can expect and plan for users that may be on a flaky connection, or that they may try to exit a page without saving information. We can work around these problems because we know they’re out there. But our deployments are not something they should see until we’re ready for prime time. For this kind of risk, we use feature flags to control what content is delivered.

Infrastructure risk is more about the inherent fragility of delivering software. CDNs, fiber, servers, switches, towers…the whole system of getting data to people has failure zones. When we are trying to reduce infrastructure risk, we assume that latency is ever-present, networks are intermittent, and we won’t always be able to count on everything working right the first time. We try to build in robust and flexible ways than can route around failures. This is the place we might use feature flags to control failovers or to create circuit breakers to prevent flooding a fragile sector.

Product harm reduction is about making sure that users can have a positive experience, even if something happens that makes it less than ideal. We want to preserve their blog drafts, keep them from committing errors, only show them things they are allowed to change, and above all, avoid giving them a blank page. Something has gone wrong in the trip to the user, but they shouldn’t have to suffer for it.

Infrastructure harm reduction is the ability to pull back breaking fixes, shunt users away from vulnerabilities, and respond near-immediately to things that have gone very wrong. Harm reduction at this level is the kind of action a pager-responder can take to get things back on track before doing more intensive repairs and investigations in the morning.

In my first week, I spent a lot of time thinking about how to summarize our product for a variety of audiences. “Feature flags as a service” is short and pithy, but only works if you can bring your own definition of “feature flag” and a business understanding of why you would use them. What about “Feature flags allow you to make changes in near real-time instead of waiting for a deployment, and LaunchDarkly helps you manage and track flags across an organization”?

Well, that works, but it still doesn’t get to the core of why an organization would want to use feature flags. What I’ve come up with so far is this:

Feature flags segment the risk of creating a product into manageable parts.

Creating and deploying software is risky. We can accidentally build in errors, we can deliver it badly, or to the wrong people, and it can interact in unfortunate ways with existing software or hardware. As organizations, we want to do our best to do no harm and provide benefit. Using feature flags lets us wrap our features in decision points that we can then use to make life easier for our users.

Here are some types of risks that are reduced by using feature flags:

  • Server falls over from too much traffic
  • Canary launch is not well-tracked, problems are missed
  • Old features and workarounds are invisible and get left in place
  • Feature with vulnerable content is deployed
  • API endpoints are exposed to unauthorized users

Managing your feature flags is a post for another day—today I ask that you take a few minutes and think about how you can reduce risk and minimize harm in your organization, your project, or your code. How can you make things robust enough to resist failure, instrumented sufficiently to identify a failure spot, and flexible enough to reduce harmful consequences on the fly?

03 May 2017

Integrating Feature Flags in Angular v4

A little while ago, we blogged about eliminating risk in your AngularJS applications by leveraging feature flags. Like all good web frameworks Angular continues to release new versions providing opportunities to tweak and update your code. The benefits of Angular over its predecessor include a built-in compiler,type enforcement, and a complete re-write in Typescript. All valuable of updates for reducing agony within the software development lifecycle.

If you’re thinking of making the switch to Angular, or are already using it, LaunchDarkly is here to help you eliminate the risk all the way from your initial migration to future successful launches. In this article, we’ll discuss how to eliminate risk and deliver value in your Angular project.

We’ll build on Tour of Heroes (which we’ll refer to as TOH from here on out), a demonstrative Angular app which showcases the framework’s basic concepts. Essentially, TOH is a live roster of superheroes, including search functionality and the ability to modify hero details. To learn more about TOH, and to get familiar with Angular, check out the official tutorial.

Creating our Feature Flags
Suppose we want to limit the usage of our search and modify features to a certain subset of our users. To achieve this, we’ll create two feature flags, toh-search  and toh-modify . In our case, we’ll allow logged in users access to search, and only the administrator will be able modify heroes.

An implementation of toh-search in the LaunchDarkly console

Integrating

Now, we’ll create a service which handles everything LaunchDarkly’s JavaScript SDK will throw at us. Note: for simplicity, we use a dummy user-switching feature (located in the user component of the project folder).

LaunchDarklyService’s constructor starts by initializing the SDK, and follows up by calling the built-in on method, which will update the feature flag values within our app whenever the user is changed, or the feature flag configurations are modified. This is handled by a Subject-typed variable,   flagChange , which will later be subscribed to by in the app’s components.
With our service functional, we’re now able inject it as a provider into TOH’s “search” and “hero” components, granting them full access to our feature flags!

In the hero-search component, we subscribe to the aforementioned flagChange , which will let Angular know that the search component should be toggled whenever the respective feature flag configuration is changed. The hero component is modified in a similar fashion to introduce the toh-modify  flag.

See it in action!

Search:

Modify:

Be sure to check out the complete project on GitHub, we’d love to see what other features you can build into Tour of Heroes!

14 Apr 2017

Go Serverless, not Flagless: Implementing Feature Flags in Serverless Environments

A demonstration of LaunchDarkly feature flags with AWS Lambda

Serverless architecture, while a relatively new pattern in the software world, is quickly becoming a valuable asset in a variety of use cases.

There are some notable business advantages to serverless architecture:

  • Faster development – easily harness existing backend services and third party APIs to quickly build and deploy apps.
  • Lower cost – substantially decreased operational costs by not having to manage infrastructure in addition to the componentization of the entire application (only scale what you need to scale).
  • Less maintenance – scaling, load balancing, and patches are a thing of the past, serverless platforms take care of it all for us.

Coupled with feature flags, a serverless application allows teams to control feature releases without having to redeploy, which is especially useful for serverless applications that tend not to focus on persistence and be more stateless in nature.

In this article, we’ll start with the assertion that you have already decided that serverless functions makes the most sense for your application architecture. What you really need is the ability to continue using feature flags in this type of architecture. This is where LaunchDarkly has got you covered.

Let’s start with a simple app model that stores a bit of user data on demand and that can retrieve values when requested. This app is going to include the use of two AWS Lambda functions an API Gateway, and ElastiCache to build a serverless pipeline. AWS Lambda lets you run code without provisioning or managing servers.  On the other hand, LaunchDarkly is a feature flag management platform that allows you to easily create and manage feature flags at scale.

Storing Flag Configurations

AWS turns out to be a well-equipped platform for serverless feature flagging. In our implementation, we create a webhook in LaunchDarkly to hit an API Gateway endpoint which acts as a trigger for invoking a lambda function.

Then, the lambda function can have LaunchDarkly populate a Redis ElastiCache cluster by initializing its SDK with the built-in “RedisFeatureStore” option. This lambda function built on the NodeJS runtime would look something like this:

Processing Feature Flags

Now that our flag configurations are neatly stored in the Elasticache cluster, a second Lambda function may be used to retrieve and process flags without waiting for any outbound connections to LD! This is achieved by enabling LaunchDarkly Relay mode in the SDK options. The function’s “event” parameter can be used to pass in a user to be evaluated by the LaunchDarkly SDK.

Take Aways

It’s important to understand that there are multiple ways to implement feature flags in your serverless architecture.  The method will depend on your app’s structure, your serverless provider, and your implementation timeline. You can check out this guide to feature flagging for best practices and ways to get started.

 

07 Apr 2017

Feature Flag Transition & Setup Guide

A step-by-step guide for integrating LaunchDarkly into your app and adopting feature flagging best practices

You’re now at a decision point. You want to buy a feature flagging management solution, but you are not sure how difficult the switch might be. You either have an existing system in place or you’ve never tried feature flagging before.

The transition process is actually not as daunting as you think. In fact, it’s an opportunity to clean up technical debt, mitigate risk, and start deploying better software, faster. From start to finish, this guide will walk you through the process of successfully integrating LaunchDarkly into your development process.

1. New Team Member Orientation

  • Use the QuickStart tutorial.  Create a feature flag for the platform of your choice using the step-by-step tutorial. We provide well-documented SDKs for Java, JavaScript, PHP, Python, Go, Node.JS, .NET, Ruby, Python Twisted, iOS, and Android.
  • Install LaunchDarkly in a test app.  In the QuickStart section, select “Install an SDK”.  Use this guide to install a simple feature flag in the test app of your choice. LaunchDarkly provides “hello-world” test apps to help you get familiar.
  • Check out our documentation. It’s important to understand the LaunchDarkly fundamentals.  In LaunchDarkly, feature flags are evaluated in-memory using one of our SDKs. Our user interface (app.launchdarkly.com) lets you create feature flags and targeting rules that are streamed to our SDKs in real-time.  You pass user objects to our SDKs, which evaluate the appropriate flag values for those users in microseconds. These feature flag events are sent asynchronously to LaunchDarkly, allowing you to easily manage users via our dashboard.
  • Start targeting users and playing with percentage rollouts.  Go to your feature flag dashboard and select a feature flag (docs).
    • On the targeting tab, you can:
    • Target individual users
    • Create custom targeting rules
    • Manage percentage rollouts
    • Set a default rule
    • Set an off variation
  • Create a multivariate flag. LaunchDarkly can do more than just evaluate true and false feature flags. Create multivariate flags that have multiple flag variations. These variations can be strings, numbers, and JSON arrays/objects.

2. Select a coordinator and document the transition

Your coordinator will take ownership of the transition process.

  • This coordinator should be familiar with feature flagging best practices and serve as the primary contact between your organization and LaunchDarkly.
  • Construct a document and/or use your issue tracker to itemize the switch. This is an opportunity to implement best practices in your development and release process.

3. Separate feature flags from configuration values

Scan your application and identify your feature flags.

  • It’s important to understand what a feature flag is, and what it isn’t.
  • The primary purpose of a feature flag is to control access to a feature based on the context of a user. On the other hand, a configuration value is primarily used to configure a permanent parameter, irrespective of a user’s context.
  • Feature flag use cases
    • Roll out a new checkout flow to 1%, 10%, and 100% of your users
    • Toggle a new beta feature for your beta testers
    • Sunset a poorly performing feature
    • Manage a long-term state, like maintenance mode or subscription plans
    • Serve a new upgrade to users who live in Canada and have an Android phone
  • Configuration value use cases
    • Set the hostname for your application server
    • Set authentication credentials and settings for services and backend stores
    • Set static rate limits for your application service
    • Set a directory path for data storage

4. Clean up technical debt by removing old flags

Remove the feature flags you don’t want anymore

  • This process is an opportunity to mitigate technical debt and remove all of the clutter from the past. LaunchDarkly has flag statuses that indicate when you particular feature flags are safe for removal.

5. Identify components that you would like to flag

Now that feature flagging will be easy, you should identify components of your application or particular processes that you would like to feature flag.

  • LaunchDarkly supports both boolean and multivariate feature flags. Boolean flags return true and false, but multivariate flags can return strings, number, JSON objects/arrays. You should hold a brainstorming session where everyone can identify the existing components they would like to flag.

6. Setting up your feature flags

If you have existing flags, you can use LaunchDarkly’s REST API to import your existing flags.

  • You can also use the API to bulk create new flags or simply use the LaunchDarkly UI.

To organize and document your feature flags, LaunchDarkly lets you add a name, description, and tags to each feature flag.

  • You can also name and provide descriptions for variations
  • Your team should decide the best ways to standardize naming conventions

7. Invite your team and start releasing faster with less risk

The coordinator should onboard team members, help set up projects and environments, and ensure that permissions are properly calibrated.

  • Develop guidelines for what new features need to flagged and how you will use LaunchDarkly to practice feature flag-driven development

We’re here to help!

We want to make the transition fast, easy, and productive for you and your entire team. Contact us at support@launchdarkly.com and we will answer all of your questions, provide guidance, and help you get started.

04 Apr 2017

We got your RBAC

How LaunchDarkly gives teams granular access and security control for their feature flag management

Enterprise companies take security and privacy very seriously: risk must be mitigated, customer privacy must be protected, and software releases must be controlled.  Feature flags are essential tools to granularly control software releases, but with great power comes great responsibility.  When you have hundreds of stakeholders using a product, you need to make sure that every team member has the exact permissions they need: no more, no less.

Powerful tools demand powerful access controls.  This means that your demoing account executive should not be able to toggle off live production features unless they are explicitly allowed to enable for a customer.  Likewise, your developers should be able to use feature flags in their own environments, but might not have access to disable functionality that customers depend on.

Custom Roles

To make this a reality, LaunchDarkly has built an extremely powerful and granular access control system that we call custom roles.

Custom roles let you control access for every team member and every feature in LaunchDarkly, from a particular flag’s percentage rollout to the ability to toggle a flag on or off.  You can create a role using our custom roles builder.

Here are some possible custom roles:

  • Lock your production environment down to a small set of trusted users
  • Distinguish infrastructure-level feature flags (controlled by your devOps team) from experiments (controlled by product management or marketing)
  • Allow QA members to control feature flags on designated QA environments only
  • Allow your designers to add users to betas
  • Allow sales to turn a feature “on” for a user

Security

Equally essential for security is the ability to prevent nefarious access and brute force attacks.  Companies want to make sure that the platform controlling their feature releases conforms to security best practices.

As such, LaunchDarkly provides multi-factor authentication and session control for all customers.  Multi-factor authentication (MFA) improves the security of your account by requiring a second verification step in addition to your password to login. In LaunchDarkly, you can enable multi-factor authentication for your team’s account, which requires you to enter a verification passcode from a free authenticator application you install on your mobile device.  You can also require all team members to enable MFA before accessing their accounts.

Moreover, LaunchDarkly’s session control offers administrators a set of controls to manage how long users stay logged in to their account, and how often they need to re-authenticate.  This allows admins to take proactive measures when an account is compromised or a laptop is lost, providing full control over LaunchDarkly account access.

Summary

Feature flagging is increasingly becoming central to a company’s software development and release lifecycles.  As part of a company’s critical infrastructure, feature flag management platforms must have enterprise-grade security to ensure that customer data is safe and that every team member has the exact access they need.

03 Mar 2017

Launched: Feature Flag Variation Editing

LaunchDarkly Feature Flag Variation Editor

Feature flags are powerful when serving variations like true and false. However, they are even more powerful when you can serve variations that are strings, numbers, JSON objects, and JSON arrays — which we call multivariate feature flags.

Previously, we allowed you to create multivariate feature flags with defined variations, but we did not let you add, edit, or delete variations once they were created. Now, you can!

With support for edit variations, you can now edit feature flags after they are created.

You can now:

  • Manage pricing in an e-commerce app by serving number variations
  • Dynamically control configuration values
  • Serve hex values to control CSS styles
  • Sunset variations that are no longer necessary

Editing Variations

When you navigate to any feature flag, you will notice a new Variations tab. This is where you will be able to edit your flag’s variations.

For boolean flags, you can edit a variation’s name and description, but not the value. This is because boolean flags can only serve true and false values.

LaunchDarkly Feature Flag Variation Editor

For multivariate flags, you can now add, edit, and delete variations even after the flag is created. Moreover, you can edit any variation’s value, name, and description. Keep in mind that you cannot change the “type” of variation being served after the flag is created.

LaunchDarkly feature flag variation editor

When you add, edit, or delete a variation for a multivariate flag, the change will apply to all environments within that project. For example, if you have a feature flag called “Checkout Flow” with 4 variations: A, B, C, D and you deleted variation D, then every environment will only have 3 variations (A, B, C) for the “Checkout Flow” feature flag.

We’re excited to deliver this new feature to you and would love to hear your feedback at support@launchdarkly.com.  You can reference our docs for more info.