19 Mar 2018

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

We’re going to look at how to integrate LaunchDarkly into an application running on AWS Lambda. 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.

For smaller workloads, you can use the LaunchDarkly SDK as you normally would. Evaluating a feature flag with the nodejs runtime in AWS Lambda looks like this:

This naïve approach is appropriate for serverless workloads that have limited concurrency (e.g., a scheduled job). If you have a workload that has high levels of concurrency or sensitivity to cold starts, this approach will have poor cold start performance because we need to call out to LaunchDarkly whenever a new Execution Context is created. To overcome this, we need to add a second Lambda function, an API Gateway, and ElastiCache to build a serverless flag storage pipeline. We’ll use this pipeline to maintain a store of feature flag configurations so that the application can just get flags from redis and avoid a more costly cold start.

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:

Note that we’re initializing the LaunchDarkly SDK inside the handler. That’s because, by initializing the SDK, we’ll pass the update that triggered the webhook along to the redis store. Generally speaking

Processing Feature Flags

Now that our flag configurations are neatly stored in the Elasticache cluster, we need to change our naïve Lambda function 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.

Originally published on April 14, 2017 by Justin Baker. Updated on March 19, 2018 by Mike Atkins.

 

09 Mar 2018

LaunchDarkly Named 11th Top-Growing Company in the “SaaS 1000”

We’re happy to share that LaunchDarkly was just named #11 on the SaaS 1000 list for the first quarter of 2018. Based on our employee growth over six months and taking into account our overall size, we’ve been recognized as one of the top-growing SaaS companies out there.

“The SaaS Sector continues its high growth. In fact, it has increased,” explains Tom Blue, who curates the SaaS 1000. “This quarter’s Top 1000 companies grew faster than last quarter’s list. Congrats to these accelerating companies.”

It’s true that LaunchDarkly has been growing rapidly—in December 2017, we raised $21M in Series B funding, bringing our total funding to $32.3M. In January 2018, we hit 20 billion features served for customers per day. We’re still only in the first quarter of 2018, and our plans for the rest of the year include even more growth.

These accomplishments are thanks to our incredible, hardworking team led by CEO Edith Harbaugh. In December 2017, Edith was recognized in TechCrunch’s list of 42 Women in Tech Who Crushed It in 2017 and was named #5 in CIO’s Top 20 Female Entrepreneurs to Watch in 2018.

As Edith notes in this interview with LaunchDarkly investor Redpoint Ventures, LaunchDarkly helps everybody who touches software. Our unified platform allows developer, product, marketing, sales, and customer success teams to manage code in real time, letting companies fine-tune features and improve customer experience.

We help companies release their products, services, and updates at a pace that matches the speed of business. Instead of a major product launch every 1-3 years, companies that use LaunchDarkly can push out software updates continually and consistently. Not only does this eliminate risk and allow businesses to move quickly and constantly improve on their service and product, it also translates into greater value for the customer. Ultimately, LaunchDarkly helps our customers help their own customers succeed.

We’re defining a new category in SaaS: Feature management software. Whether disrupting an industry or working to remain competitive, every company wants to provide better service to customers. We are working with a broad base of cross-industry companies, including banking, insurance, shipping, ecommerce, and hardware, to bring clean, functional software to end-users without a hitch.

Thanks to Tom Blue for including us in the SaaS 1000, and congratulations to the rest of the companies on the 2018 Q1 list!

Image: Credited to NASA. From left to right, Margaret R. (Rhea) Seddon, Kathryn D. Sullivan, Judith A. Resnick, Sally K. Ride, Anna L. Fisher, and Shannon W. Lucid—The first six female astronauts of the United States stand with a Personal Rescue Enclosure, a spherical life support ball for emergency transfer of people in space. Complete image here.

13 Nov 2017

To Be Continuous: Getting Acquired, Founder Conviction, DevOps in Continuous Delivery

In this episode of To Be Continuous, Edith and Paul are joined by Keith Ballinger and Thomas Dohmke from Microsoft. They share their experience of being acquired by Microsoft and discuss the role of DevOps in the continuous delivery process. They then consider the importance of balancing founder convictions of product value and how the world is changing, with necessary market validation activities. Keith also shares his thoughts on why early-stage founders should ignore larger companies for as long as possible, focusing instead on building their business.

This is episode #40 in the To Be Continuous podcast series all about continuous delivery and software development.

Continue reading “To Be Continuous: Getting Acquired, Founder Conviction, DevOps in Continuous Delivery” »

01 Nov 2017

To Be Continuous: Transforming Microsoft Into An Open Source Company

In the latest episode of To Be Continuous, Edith and Paul are joined by Martin Woodward from Microsoft and Ed Blankenship from Algorithmia. They discuss the cultural and technological shift that was necessary to transform Microsoft into an open source company. Martin talks about how as the owner of CodePlex, Microsoft’s open source community, he created Microsoft’s Github account. He also shares tricks he used to drive adoption inside Microsoft, such as allowing people to use their personal GitHub accounts, the subsequent challenges that this created and how he overcame them.

This is episode #39 in the To Be Continuous podcast series all about continuous delivery and software development.

Continue reading “To Be Continuous: Transforming Microsoft Into An Open Source Company” »

28 Sep 2017

To Be Continuous: From Monolith to Microservices

In the latest episode of To Be Continuous, Edith and Paul discuss the challenges and benefits of refactoring monolithic applications into microservices. They examine various approaches for creating microservice boundaries and dispel the myth that they should be defined as small as possible.

This is episode #38 in the To Be Continuous podcast series all about continuous delivery and software development.

Continue reading “To Be Continuous: From Monolith to Microservices” »

14 Sep 2017

Beta Testing with Feature Toggles: Testing in Production Like a Pro

We all know beta testing is important—not just for understanding your customers’ needs, but also for stability and security. Every time you do a launch you are essentially asking: “Are there bugs? Is there feedback?” Both with the goal of making your product better.

Testing in production will give you the most information about the success of your new functionality. And because feature flags help separate deployment from release, they make such testing safe and easy. When it comes to beta testing, a lot of the top companies tend to adhere to a similar paradigm—test early, test often, and do it in your production environment.

So how do companies have smooth and simple transitions from alpha to beta testing, and then to full rollout? Read on to learn how top companies are approaching their beta testing using deployment tools with feature flags providing links out to more in-depth descriptions.

But before we get started, here’s a quick terminology review. Pete Hodgson refers to this use of feature flags for betas as “permissioning toggles.” Also known as a “canary launch,” this is often random like a percentage rollout. A set group, or “champagne brunch,” releases to internal users or another section or group.


6 Approaches to Product Launching

#1 Facebook is the prime example of dark launching. Their release management has to be impeccable to operate at such massive scale. Their betas are often up to  million users or more.

“Although we push to production only once a week, it’s still important to test the code early in real-world settings so that engineers can get quick feedback. We make mobile release candidates available every day for canary users, including 1 million or so Android beta testers.”

Read their article on Rapid Release at Massive Scale to learn more about how they do continuous delivery at scale.

#2 Hootsuite gives a typical rollout pattern for its features—starting internally and then slowly exposing to a larger audience.

Typical
Push new code then:
– Dark launch to yourself or your team to test
– Launch to the whole Hootsuite organization
– 10% of all users
– Watch graphs
– 50%
– 100%
– Simple means of rollback if necessary

Check out Bill Monkman’s full deck on dark launching here.

#3 Etsy calls feature flags “config flags,” and gives a lot of credit for their process to Flickr.

“Key system-level and business level metrics (like checkout/listing/registration/sign-in rates) are projected on screens in the office and we have a number of internal dashboards that the team uses (we mainly use Ganglia and Graphite). We also have lots of switches and knobs to help us roll features out to percentages of users and ramp them up slowly, or quickly. Features are used and tested by us here at Etsy for some period of time before they are rolled out publicly.”

They have custom built a feature flagging API, “Feature API” to enable this. Some of the bucketing they use include: admin, internal, users, groups.Read more about Etsy’s deployment practices and check out their Feature API on GitHub.

#4 Beta can also apply to back-end rollouts. Instagram does canary deployments to a subset of servers, using feature flags as a continuous delivery tool. It’s important for continuous delivery to perform these tests, which are key in helping them avoid failed deployments.

But Instagram hasn’t always had this system. Read here to learn how they evolved from a “mish-mash of manual steps and scripts” to a system they could depend on. And check this out if you want more recipes for database migration with feature flags.

#5 Niantic’s Pokemon Go betas are well known and rabidly tracked by its fans. They famously roll out by region—a field test in Japan here, a limited beta in Australia, and then something in New Zealand. Sometimes these betas for features are invite-only. Here’s a write up of how they approached the rollout of the game Ingress.

#6 GoPro released their GoPro Plus product early using feature flags. By breaking the larger release into smaller features with their own testing timelines, they were able to iterate and improve continuously. The video below walks through the technology they used and the timeline from dogfood to a “big bang” marketing announcement.

“At GoPro you can kind of tell we don’t things lightly. We want to do big announcements and we want to come out with great products…we actually had smaller features that would go out, and then go for alpha testing and beta testing along the way. Shortly after March, we actually had most of the applications done from a core feature standpoint, but we kept iterating and improving those core features that we knew we were going to launch with.”

 

Controlling Your Rollout Like a Boss

Did you notice some trends there? These larger companies are using beta testing to do one of the following:

  • Testing in production with feature flags
  • Ability to release early and test small functionalities before a broader release
  • Internal tests that easily become external canaries
  • Regional rollouts

As more companies start to use feature management, these incremental rollouts are not the headaches they once were. Companies can be safer and smarter with how and when they expose features to their end users.

If you want to get started with feature flagging, check out featureflags.io a resource we made for the community to learn best practices.