Galaxy Brain is a blog post series covering previous talks at our annual user conference, Galaxy.
Favor Delivery is a Texas-based on-demand delivery platform, so they know a thing or two about responding to real-world conditions in real-time. At a Galaxy session in Austin, two of the Favor team joined us to share their journey of adopting LaunchDarkly and how they're using it to drive continuous delivery and customer value at Favor.
Our guests:
- Ivan Valle, Staff Software Engineer at Favor Delivery
- Daniel Kaparunakis, Senior Android Developer at Favor Delivery
They were hosted by Jonathan Nolen, SVP of Engineering and Product at LaunchDarkly. As usual, we’ve got some highlights for you below, but there’s more to the story so be sure to watch the session in full.
You can also catch up on all the insightful talks from Galaxy here, but before you head over there, stay with us to hear about that one time Favor really stress-tested LaunchDarkly’s scaling capacity (to the tune of 200 million requests).
Favor's LaunchDarkly journey
How did you discover LaunchDarkly?
Daniel is a seasoned LaunchDarkly user, having worked with it for five years across three different companies. Ivan shared that Favor adopted LaunchDarkly a few months prior to the session, as they were looking to move away from their home-built A/B testing service. The service “was dismissing a lot of features, and while we could invest a lot of time into building, it was just better to go with LaunchDarkly,” Ivan explained.
How is your org set up? Which teams are using LaunchDarkly and for what?
On Favor's client-facing side—about half the company—every team is in the process of adopting LaunchDarkly, with all web SDKs, Android and iOS SDKs integrated and some flags already in production. The other teams working on the backend are still ramping up their usage, having introduced the Relay Proxy for their legacy PHP services.
What were you excited about gaining by moving off your home-built service?
For Ivan, the answer was easy: “A UI! We only had a database and a REST API on top. So any single time we had to make a change, you either had to make a database change which isn't ideal. So the console's a very powerful feature there.”
What business value do you get out of having a feature management solution?
Moving towards continuous delivery and being able to deliver products faster were the key benefits for Favor. "Because we had this legacy A/B testing service, every single time we wanted to roll out a feature, it was just naturally slow," Ivan said. "This allowed us to move quicker."
What use cases for feature flags have been useful?
A/B testing
"Something that Favor really cares about is A/B testing," said Daniel. "So we've made extensive use of the data export feature. We've essentially set up a pipeline to get any flag evaluation all the way from what happened on the client, all the way down to some AWS instance." The benefit is that they don't have to sift through any data that was generated through their homegrown servers.
Shifting traffic in real time
One capability that LaunchDarkly has enabled for Favor is to route traffic between contact centers in real time, without requiring engineering input or creating any impact to the customer. "Product can kind of slowly monitor the traffic into the new contact center and change the percentage without any engineering effort," Ivan explained.
This might mean handing out a different number for SMS, and "as far as the customer knows, they're talking to Favor using SMS, but in the background we're sending that from Zendesk over to Twilio and it's all happening behind the scenes."
How has adopting LaunchDarkly benefitted your customers?
"Indirectly, we move a lot faster," Daniel shared. "Rolling out a flag, creating a flag, going through that process is no longer something that engineers, even product managers or anyone else has to spend time on."
Risk mitigation was also a huge win at a prior company Daniel worked for. "Risk mitigation was extremely critical, it was a point of sale," he explained. "So stability, the system working all the time, every time was very, very important. LaunchDarkly was critical to us being able to release, release often and quickly and just turn things on and off depending on how well the rollout was going. So just making the product more valuable and perform better."
Lessons and advice for companies just starting with LaunchDarkly
Have a process
At one of the companies Daniel previously worked for, things got out of hand quickly. "We ended up with something like between 500-1000 flags and that's very hard to manage. That's a lot of cognitive load."
Ivan's advice is to have a process that makes people ask, "Why are you flagging something, why does it make sense?" If you approach everything from a place of risk avoidance and stick everything behind a flag "because we can," that's when things can become unruly.
Start with smaller features
Daniel recommended working your way up to using feature flags on your biggest features. "You want to get those technical issues ironed out before you introduce it into the big feature."
Expanding use of LaunchDarkly from one team to many
Start small, Ivan advised. "There are a lot of features within LaunchDarkly, like the workflows and all that. You don't necessarily have to commit to using all these features at once. It's totally acceptable to use a local SDK and for one team only," he said. "Then as you bring more teams on, bring in the Relay Proxy for some more efficiency, bring in the workflows for some guardrails."
What's been most surprising about using LaunchDarkly?
Experimentation has become more entrenched in Favor's culture. "Our existing A/B testing service was kind of difficult to manage," explained Ivan. This led to a reluctance to conduct A/B testing or put things behind flags, "but now it's so easy—changing the cover button, why not? Let's go ahead and throw a feature flag on it or an A/B test flag on it and see what performs better."
Daniel left us with an example to demonstrate an unintentional test of LaunchDarkly's scaling capabilities with surprising results:
"One of our test features ran on a service and we didn't set it up to cache the value. So every time the server spun up, we had a flag evaluation and that was a pretty popular service. So we did test your scale when we hit it 200 million times in a span of two weeks. So in terms of scale, things worked out pretty well."
There's always more to the story than we can capture here. Check out the full session and hear more from our customers in Galaxy Brain: What Engineers and Pro Chefs Have in Common.
