Implementing Feature Flags in Serverless Environments

Leave your on-prem servers behind, but keep the feature flags! Here, we examine how to incorporate feature flags using AWS Lambda to reap some serverless benefits.

· Cloud Zone · Tutorial

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 make 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.

image title

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:

exports.handler = (event, context, callback) => {
    var launchdarkly = require('ldclient-node')
    var options = {port: process.env.elasticache_port, host: process.env.elasticache_endpoint}
    var store = new launchdarkly.redisfeaturestore(options))
    var ldclient = launchdarkly.init(process.env.launchdarkly_sdk_key, {feature_store: store})
    ldclient.once('ready', function() {
        callback(null, 'store updated')

 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.

exports.handler = (event, context, callback) => {
    var launchdarkly = require('ldclient-node');
    var options = {port: process.env.elasticache_port, host: process.env.elasticache_endpoint}
    var store = new launchdarkly.redisfeaturestore(options)
    ldoptions = {feature_store: store, use_ldd: true}
    var ldclient = launchdarkly.init(process.env.launchdarkly_sdk_key, {ldoptions})


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.

aws lambda, serverless architecture, feature flags, cloud, tutorial

Published at DZone with permission of Justin Baker, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.