Help build the future of open source observability software Open positions

Check out the open source projects we support Downloads

We cannot remember your choice unless you click the consent notice at the bottom.

Open standards, lower costs, and centralized observability: Why FalconX moved to Grafana Cloud

Open standards, lower costs, and centralized observability: Why FalconX moved to Grafana Cloud

2024-12-27 6 min

When FalconX, a crypto prime brokerage with offices in the U.S., Europe, and Asia, needed to move off their proprietary observability provider, DevOps Manager Vaibhav Krishna knew just where to turn.

At a previous job, Vaibhav had used Grafana in the early days of Grafana Loki, and he’d seen the growth in offerings from Grafana Labs ever since. He felt the open source tooling fit with FalconX’s ethos, and he saw the potential to save time and money by consolidating on one platform. He wanted a platform that could scale with them (15 TB of logs ingested monthly, and counting), help them with security and compliance, and accommodate modern software development processes—all while removing the burden of his team having to manage it all.

Vaibhav recently talked with Grafana Labs about why FalconX migrated to Grafana Cloud—a process that was completed in a month and instantly translated to 40% savings—and how the fully managed platform checked all the boxes for them.

For starters, tell us why you decided to go with Grafana Cloud.

We had a lot of reasons. First, the setup we had at that time was very expensive. Second, we wanted to expand our footprint. We are in crypto trading and financing—it’s an evolving market, so our requirements change and growth is exponential, but our monitoring infrastructure was not readily scalable. We wanted something that was more of a “plug and play” that is easy to maintain. We did not want the headache of managing our own observability setup.

Our goal was to find a solution that seamlessly integrates with Kubernetes, where most of our applications run. Beyond Kubernetes, we needed a platform that could support additional tools and add-ons across our clusters while offering various plugin support and a single pane of glass for everything.

Were open standards an important part of your decision as well?

Yes, this was important for me and for our team. We are not comfortable with a closed-solution approach as we want real-time visibility into our data and security.

And from an engineering/DevOps perspective, a lot of really good work is happening in open standards. It’s not just about Grafana, but the entire ecosystem of open source tooling, and that open source tech, in my experience, is more fruitful. If you have closed source tools, which don’t integrate well, it will inevitably be a pain point. Given that we had a clear directional vision for our growth as an organization and department, we were very focused on open source solutions.

You used Grafana at a past job, but was everyone else as willing to jump on board?

Moving to a new tech stack is never easy. We had a decent amount of diligence and garnering of internal support, particularly because there are so many traditional name-brand tools out there. Pitching it to the C-level executives was a challenge, too, as some came from companies like Google and were used to completely different setups. On top of that, there were times when investment partners or others suggested alternative solutions. But the Grafana team supported us along the way and designed an incremental approach, gradually shifting workloads and seeing results month over month, which gave everyone the confidence to fully transition.

So how did you ultimately win them over?

I think the evolution of the feature set in Grafana—it’s not the same Grafana as what I used earlier. There’s a lot of evolution; there’s a lot of maturity, and if you look at the roadmap, it’s not only looking at metrics but a holistic approach to observability.

And were you able to save money by switching to Grafana Cloud?

It’s fair to say we were able to immediately save 40%.

What about the functionality? Sometimes you go someplace and it’s 40% cheaper and you get a 40% worse product.

We didn’t see any degraded performance. I think a lot of this cost is also getting slashed because of logs. Logs are the key to cutting costs. OpenSearch is very expensive compared to Loki. We still have metrics in Datadog, and if we do a full flip we will definitely save some cost when we do Grafana Cloud. But I think we would save a lot more in Loki because of the way it indexes and the way it stores data.

I understand you also used Adaptive Metrics, our cardinality optimization feature that helps identify and eliminate unused time series metrics.

I was very skeptical about how well Adaptive Metrics would work. There was this sales call and whatever contract was offered, I was not confident with the metrics calibration there because Adaptive Metrics was calculated there, too. And when he pitched, “Hey, this is how much Adaptive Metrics will slash,” and I was not at all confident. I didn’t think it would even cut down more than 5% or 10% of the overall metrics, but I can see now that it cut upwards of 40% or more. Now I’m very happy with how Adaptive Metrics is working.

So have you tried Adaptive Logs yet?

Now I’m very excited to do Adaptive Logs.

How does your experience today compare to the Grafana you used in your previous company?

I like the way Grafana has matured. From an end user perspective, I really like the offerings and the direction. It started with metrics, then logs, then traces, then you could add other metrics and include all your signals. Then there was Grafana Alerting in place, and IRM, and now Frontend Observability.

I’m looking forward to how Sift will evolve, because Grafana has all of our data, so I would assume that over time we get more mature and it gives us very pinpointed recommendations that are actually solutions—like, why is something broken?

How does that centralization support your efforts?

It makes our life simpler. Whatever tooling I build internally, I have fewer headaches because I only have to manage one stack.

It’s a lot of pain to set up multiple tools, and it’s a lot of context switching, too. Managing more tools is very hard for leaner teams. Even for mature teams, it’s still hard, and it’s pretty unnecessary. From an administrative perspective, it’s very simple because I’ve built out pipelines on how to install Grafana everywhere. Whenever I want to extend to more metrics or more signals, I just modify these existing pipelines. If I have to manage multiple tools, I have to manage all of this internally again, which means I also lose more bandwidth.