One of the presenters at our latest Trajectory conference was Sidney Wijngaarde, Software Engineer at Chronosphere.
Chronosphere provides customers with a cloud-native observability platform that can ingest massive amounts of metric and trace data, powering use cases like notifications, triaging, and root cause analysis.
Sidney's particular team works on controls. He started by explaining that in a cloud-native world, they have to be very agile and launch features quickly. However, Chronosphere is a solution other companies look to in understanding when their systems are down, especially during a crisis. This means they need to have a high standard for reliability and security with every feature released.
As always, we recommend you watch the full session to get the full effect. In the meantime, here's a quick breakdown of how Sidney described the LaunchDarkly use cases for his team.
Feature releases
Sidney's first use case was a familiar one: feature releases. He explained that prior to using LaunchDarkly, his team had to have engineers redeploy services to release features to their customers (oof).
"Now, we can separate the business decision of releasing a feature from the engineering decision of how to develop it," he said. "And that's been really powerful for us with releasing."
Tenant configuration
Sidney explained that every tenant of his team's system has its own stack, so managing the differences between them was kind of a nightmare prior to using LaunchDarkly. "Now, we have a UI, and audit and control, and an easy way to understand what's being served where," he said.
External clients control plane
Chronosphere has a handful of services it doesn't actually host. Instead of building a one-off config management system to control these processes in the field, Sidney explained that his team leverages LaunchDarkly to gain the ease of use of what that platform provides, as well as the liability—something that's much easier to do than building their own solution.
Instance debugging
As one of the newer use cases for the Chronsphere team, Sidney described how they use LaunchDarkly to flip on, in his words, a "verbose debugging" for an application without redeploying and losing all the context and the specific circumstances that caused the issue. This saves his team from the need to undertake costly logging methods or detailed traces throughout certain code paths in their system.
But wait! There’s more…
Sidney also took some time to go over what he refers to as reliability tweaks, the first of which is a LaunchDarkly client wrapper his team built. Using a diagram, he outlined how they use the client wrapper to ensure that the right user is passed into the LaunchDarkly client to target flags appropriately in production.
The second example Sidney provided was persisting feature flags:
"This is a use case where if we use LaunchDarkly to manage this rate limit, we definitely need to make sure that it's always correct because we could potentially ignore metrics that customers are sending and lose data," he said. "So, instead of having just one link to LaunchDarkly—which is the standard way that LaunchDarkly is architected—we've used their enterprise model to back up feature flag data in a persistent store inside of our cloud."
Impressive, right? There's more to it, of course (along with another diagram), but you'll have to watch the full video to see it.
So, how about those outcomes?
Sidney closed things out by mentioning that his team is now up to 150 feature flags in production. "The developers within Chronosphere have really felt the efficiency gains of being able to just develop and hide features while working on them—but then be able to flip them on at a moment's notice."
Check out the full video here to get more of the details we couldn't cover here and to see Sidney explain things with some added visuals for even more clarity.
