Submind YouTube summaries
Thumbnail for Observability Costs Are Spiraling. Here Is How Tsuga Fixes It | Gabriel-James Safar

Observability Costs Are Spiraling. Here Is How Tsuga Fixes It | Gabriel-James Safar

Watch on YouTube

Video summary

The video addresses the critical issue of exploding telemetry volumes driven by the rise of AI agents and autonomous systems, which are causing observability costs to spiral out of control for many enterprises. Gabriel James Safar, CEO of Tsuga, explains that traditional platforms often fail in this new environment because they cannot handle the sheer volume of data generated or maintain sovereignty over sensitive information. As organizations increasingly rely on Large Language Models (LLMs) and AI-generated code, the need to analyze performance without losing control becomes paramount; however, many companies find themselves trapped by vendor lock-in once their valuable telemetry data has been sent to third-party providers who may use it against them or charge prohibitive fees for egress. Tsuga was founded with a specific mission to help enterprises regain data sovereignty and take back control of their AI infrastructure through its "Bring Your Own Cloud" approach. The company's philosophy is rooted in the idea that observability agents should be open source to prevent vendor lock-in, while storage formats must also remain open so that data can flow freely into business intelligence tools or private AI models without leaving the customer's environment. This architecture allows companies to store and process all telemetry within their own cloud infrastructure, ensuring they do not pay an "infra tax" to a third party for using their own data. Furthermore, Tsuga supports multi-cluster deployments where organizations can keep specific portions of their data in different geographic regions—such as separating US, European, or Brazilian datasets—to comply with strict local laws and geopolitical concerns regarding AI sovereignty. Beyond technical architecture, the discussion highlights that human factors are often the biggest barrier to adopting new observability solutions during a transition from legacy platforms. Tsuga addresses this by employing forward-deployed engineers who work directly with customers to redesign their data collection architectures, install open-source agents like OpenTelemetry efficiently, and govern the quality of telemetry assets across large organizations. The company's strategy involves empowering central teams within enterprises to establish observability as a shared language while providing tools that make it easier for engineering teams to deploy code frequently without sacrificing visibility into new issues introduced by AI-driven changes. Ultimately, Tsuga aims to flip the traditional pricing paradigm where companies are forced to sample data heavily just to keep costs manageable; instead, their system is designed to handle ten times more data volume than typical solutions while keeping ownership with the customer. With recent funding focused on product development, expanding sales coverage in key markets like Europe and the Middle East, and enhancing marketing efforts, Tsuga positions itself as a solution specifically for large-scale organizations that prioritize owning their stack, governing their data quality company-wide, and scaling observability without being blocked by budget constraints or proprietary limitations.
Read the full video transcript
Today, telemetry volumes are exploding. Audible costs are spiraling out of control and traditional platforms can't handle the rise of AI agents. By the time organizations realize they have lost control of their data, it's already too late. They are trapped. Now, Tsuga is stepping in to help enterprises regain data sovereignty and take back control over their AI infrastructure. And today, I have with us Gabriel James Saffar, CEO of Tsuga. First of all, Gabriel James, it's great to have you on the show. >> Thanks for having me. >> It's my pleasure. Uh first of all, I would love to know a bit about the company itself, the name, when the company was created, and what market shifts made you as well as your investors to completely rethink enterprise observability. So, let's talk about the story of the company. >> So, my co-founder Sebastian and I, uh we we have been working together for quite a few years. Tsuga is our third company together. The first one was a total failure. The second one got acquired by Datadog. And we were in charge of a pretty large suite of products uh over there. And after our times uh had come, we we left. And [snorts] uh what was clear from talking with large enterprises uh was that the Datadog model was great in a variety of ways. It was the best product for many customers. But at the same time, it was not following a variety of shifts that we were seeing seeing with uh uh notably larger organizations, organizations that have very large uh systems. Um And so so that's what gave us the idea of creating Tsuga. Um Tsuga, as a word, uh is a family of pine trees that grow in Japan and in the region of Seattle in the US. Um and these are these are trees that have good properties for building things. And that's why where the name came from. My wife is Japanese, so that's why a Japanese name was was nice. Uh well >> Excellent. Uh thank you the history and the story of the company. Now, uh the fact is that uh we are seeing a massive surge in AI agents and autonomous system. And of course, when it comes to observability, a lot actually when I go to CNCF CubeCon, observability is I think one of the topics uh hottest topic these days. Of course, OpenTelemetry, the maturity, and it is becoming, you know, very very critical piece of technology in modern world. Can you talk about how is AI fundamentally changing what enterprises actually need from their over tools, and what the current breed of tools is failing to provide them given the AI workloads? >> So, if you put yourself in the shoes of any company with a large uh IT IT uh system, uh the first issue is AIs, so LLMs and agents, are a new sort of service. Uh so, if you want to understand how your services are working in production, you need to understand these services uh because if you don't, you won't be able to uh to analyze that they're not going fast enough, they're not performing as expected, uh they are uh too expensive. So, traditional observability problems. Uh so, problem number one. Problem [snorts] number two, if you want to uh benefit from AI, you will want your engineers to deploy a lot more often, right? Uh a lot more code made by AI, so a lot more code churned onto production. But so, if you do that, and if you want to identify that some of these uh new deployments are introducing issues, you cannot uh keep the same sample rate as what you used to. You need to keep a lot more data in order to to see that. But, IT systems kept growing in the past 20 years. And so, the telemetry volumes have kept increasing. So, you have new services, you have an increase in the data volume. And last, in LLMs, you have a problem that is just like in logs and in traces in the past. You have a lot of information that you probably don't want to skip to let into the observability and not have the upper hand upon, right? If you're a company with health care and one of your customer is telling personal information about their health, that information will be in the telemetry of your LLMs. And so, is it okay to have that information sent into a third party? Probably not. So, these are the structural issues, increase of volume and increase in sensitivity, and new sort of services that enterprise have to tackle. And on the other side, the opportunity is what AI/SRE can bring to the table. So, you can see that as different topics that enterprise can seize in the age of AI and how they need to deal with. >> Can you also talk about if we just forget about AI for a second because AI is putting a different kind of strain on the workloads and observability. In general, if you look at the whole observability space, if you look at open source side of it, you know, open sensors, open telemetry, you know, open tracing, the and now open telemetry has kind of become a big project in the space. Are you Once again, if we ignore AI, are What do you feel about the whole evolution of observability? And then, if you bring AI into the picture, did AI as accelerate the evolution of AI observability or that evolution was already due? AI just kind of stepped in to make things faster. What I'm trying to understand is the evolution of observability as it was happening, did AI change it, speed it up, or make people rethink it? >> Indeed, what you are working is the notion of data collectors, right? Uh so, the agents in the ancient ancient meaning of the world, right? So, these So, the observability agents, so the the the thing that collect the telemetry have been closed source for a very long time and it created issues because it created a vendor lock-in for enterprises using observability and that was pretty bad. I think getting rid of uh these locked closed source agents uh has been a top priority project for the past 5 years in many many enterprises. What AI is bringing to that is that the transition is much simpler. It's much easier using AI to to do the transition. It doesn't make it uh instantaneous, right? But, it makes it easier. So, AI is helping uh enterprise become less vendor locked when it comes to the data collection of the observability. On the other on the other side, telemetry is extremely valuable. You can do a lot of things. Of course, you can troubleshoot, you can do analytics, you can identify optimizations in your systems. But, it's also business data, right? And so, if you can feed telemetry to your AI, uh you can unlock uh a lot of value by bridging it notably with uh business information. So, I think that a project for many enterprise has been also to own the data, which was not possible uh with the products in the past. That's why we brought bring your own cloud as well, right? Because bring your own cloud uh allows customers to own their data. Uh and so, if they want to feed it to their BI tools, to their own AIs, they just can do that because the data is there. >> And since you mentioned, you know, they do want to own data and which has been case, but the whole thing when you move to the cloud, we do talk about data gravity there, you know, once the data is in there, egress cost can make it very, very hard for you to move. But now we are talking a lot about data sovereignty in Europe, a lot of laws are coming in, AI sovereignty is being talked about because of this whole geopolitical conflict going on, countries are very, very, you know, kind of you can say skeptical of trusting each other. So they do want to move in data. Uh At the same time, we can talk about privacy and all those things. Can you talk about uh what is driving this change in priority for data sovereignty, whether it's AI, whether it's geopolitical, or evolution of technologies, and what role is Observability and Soda playing in this space? >> Uh so I know we talk a lot about Europe in that domain, but Europe is not alone, right? Canada, Brazil, Japan, India, Australia, uh countries in the GCC like uh KSA or UAE. All these countries have jurisdictions that make it more and more important to choose where your customer data is being stored. And why? Well, because these countries understand that this customer data is very valuable and giving it away is not a good idea. And the same way these countries see that, the companies see that as well. So for me, uh where there is a big shift is that the notion of sovereignty is not only country level. You can see that also as company level. I want to be sovereign in the sense that I want to own the pieces of my stack and I want to own without having to pay a tax my data. Because if I don't, then all of a sudden a vendor can just use my data to feed my competitors. And that's something that I don't want as a company. So the notion of sovereignty, I don't think we should hear that only at country level. We should also see that at company level, notably for companies that are important, right? If you're a big company, you are a sovereign entity. So in that regard, the approach we have in Tsuga is bring your own cloud, meaning that we are compatible with all the the open source data collectors. So you can keep your own collectors, open telemetry or others on one side. The data is stored in your the the entire processing, the entire observability system is in your cloud, meaning that the data doesn't leave. Meaning that you keep the control, the data is yours, you don't pay a tax to to use it, right? You don't pay an infra tax to use it. And on top of it, even when we look at AI, we work with your the bring your own agent approach. So you can choose your AI systems and run it on top of the telemetry and we provide a variety of products and systems to make your AI model that you approved because it's very much a political decision what AI and what's the AI push for your company. And you can just apply that to our system and we'll harness it so that it works. >> Let's talk about cost of it. A lot of organizations are kind of drowning in rising telemetry volumes and cost. Can you talk about why our traditional approaches to observability are not sustainable in this new AI era and how Tsuga is also focusing on the cost aspect. >> If you will, so that's what we discussed at the beginning, right? You need you have more services, it keeps growing, and you you need to sample a growing amount of the data. So, the volume of telemetry keeps increasing. At the same times, there is one thing that is fixed. And what's fixed is not the amount of telemetry. What's fixed is the budget. Uh so, if you're an enterprise, you have a budget and you don't want to blow it up. Uh so, uh for these reasons, historically, the solution was to tell you, "Okay, what about sampling?" Even more, even more always more, always more as well, right? You sample and you keep in the end 1% of the data or 0.1% of the data. But then, it defeats the purpose of telemetry because you never know uh when you're going to need a metric, when you're going to need trace. Uh so, the more you sample, the more you create operational uh problems for your teams because they need to spend a lot of time in reducing the volumes. And uh the more likely it is that you won't have the right data when you need it to do analysis or troubleshooting. So, that's why we want we wanted to flip the paradigm, right? Uh if we were not bring your own cloud, we would need to sell you observability. It would have a cost on our infra, and then we would need to sell it to you 5x more to have 80% gross margin. The goal is to flip that and to say, "We're going to make it work so that even if you have a huge amount of data, we'll make it work uh so that uh the pricing allows you to keep maybe 10 times more data than what you could do with another system. And because it's in your infra, uh potentially, you can even negotiate better prices with your cloud vendor, which can have a good impact on your global cloud bill. So, that's the approach. The approach is instead of putting an infra tax, uh we want to design a system where you can have as much data as you need for your teams to go at the fastest speed possible. >> Now, when we talk about uh of course telemetry, of course the first word that or first term that comes in my open telemetry and of course open source looking at this geopolitical crisis, open source kind of become the universal language. It removes a lot of, you know, barriers to entry. But, the the the the beauty of open source is that is committee maintained, is not controlled by a single vendor. That means you're not locked or you are on the mercy of that vendor. The problem is that open source can solve day one problem very easily. You can download the code, you can get it installed. But, then day two becomes a big challenge. That's why you need enterprise grade. That's why commercialization in open source is very, very important for the success of open source. Sometimes you cannot have a Puritan word. You may want everything to be open source, but you may have to have a mix of open source and proprietary. What is Sumo Logic's approach towards open source and observability? >> So, we we are strong believers in in the fact that the data collectors on one side should be open source because these data collectors, these agents, you put them in your system, in your code. So, if ever you want to to leave your vendor, you need to be able to. So, if it's close source, it's creating a the wrong pressure on the value. At the at the other side, the the storage format needs to be open source. So, that uh the data is not locked into our own ecosystem, but it can be used across your Databricks, your BigQuery, your Athena, uh etc., etc. So, we are big believers in the data should be open source through and through. Uh and in the middle, the goal is for us to make a very opinionated product. So, on that front, it's harder to be open source and extremely opinionated. Uh so, for now at least uh the the the central piece of the product is not open source, but we ensure that uh well, but there but there is a pressure for us to deliver because if we don't deliver enough value, uh our customers have open source data collectors at the entrance, open source data uh at the exit, and so they can get rid of us uh and uh keep their data flow end-to-end even without us. >> And that is the right approach to not uh forcing people to get logged in you know. And now uh which is also a very good segue that as organizations are trying to transition away from legacy platforms, what is the biggest roadblock that they usually hit that if when you talk to them, they talk talk about all those challenges problem, and how do you folks help them get past that roadblock? >> The the the the answer uh the answer won't surprise you. The biggest blocker is usually the people. Uh you have people observability is used by a huge community uh within a within an organization. So many workflows depend on that. So usually, the biggest blocker are the people. How can we empower the people? Then, of course, so that's the biggest blocker. That's the biggest thing that needs to be identified with the central team so that we can empower them and show them how uh with the transition their life is going to be easier. Uh in SigNoz, [snorts] we have a lot of rules to help on governance of telemetry, govern the quality of data, the quality of observability assets, uh enablement. Uh So, that's how we can help the central teams do that, but that's one piece. The second piece that is complicated is the data collection, notably for organizations that come from uh products with closed source uh solutions. So, on that, we have forward deployed engineers who can help them uh change uh their collectors. So, install uh OpenTelemetry agents to make it efficiently, design the architecture. To give you an example, we support multi-cluster. So, if you're an organization, you want to keep a part of your data in the US, a part of your data in Europe, a part of your data in Brazil, you can do that in a single interface in our product. What should be the data flow? Where should go What should go where? Is something very important where forward deploy engineers can help identify the bottlenecks, help design the architecture, and implement it if that's what's going to make the organization more more efficient. Um We like to say that we are not a SaaS, but we are a SaaS. So, we are a SaaS in the sense that we are a software and a service. So, we have forward deployed engineers. We have great partnerships with partners in the ecosystem, and we empower them to bring a lot of value. So, we focus on the human factor, and of course, a set of tools to make that more efficient so that transitions can be a success. >> Now, let's talk about the growth of Super you folks raised, I think, 30 million if I'm not wrong. Talk a bit about with this new funding round, what is going to be the primary focus for investment and company growth, engineering, product team, sales? >> So, three investments. Number one is we need to observability even when you know what you need to do because we've been in the space for so long, my co-founder, my head of product, many of our engineers, that we have a good idea of things that we want to build. But even if you have a good idea, the world is changing, and there are a lot of things to do. So, we're going to keep investing on the product. There is a lot of things we want to do and that we have not done yet. So, that's number one. Number two is we're going to invest in our sales team. Currently, we have sales people in France, Germany, UAE, US, UK. The goal is to increase that coverage by recruiting amazing sales people who know how to work with the most sophisticated enterprises and to recruit the forward deployed engineers who can work with them. And last, we're going to invest in in marketing in order to to support this motion. That's very classical, right? For a series A, product, sales and marketing to support the sales. >> When it comes to observability space, you mentioned a lot of names. It's a very busy space. You know that it's a crowded busy space. Why should an organization look at Sugar when they want to solve their observability problems? >> That's a very good question. So, our goal when we made Sugar was to create a product that works for a very specific set of organizations. And that's the organizations who care about at least one of the the following three, right? Sovereignty, ensuring that they own their data through and through, that they control where the data is stored, where they control the AI that work on telemetry. So, sovereignty is number one. Number two is governance. So, ensure that observability is practiced correctly company-wide by empowering the central teams to make observability a shared language across all the organizations and we do that through the product and through our enablement. And last, for scale. We we we we are best used with organizations that have a very large scale in volume of data notably and who very often are blocked onto solutions that are not great, but because it's the only one that work for them in terms of organization of or budget. And that's where we can help, right? So, sovereignty, governance, scale. >> Gabriel and James, thank you so much for joining me today and sharing your insights. I'll be a lot of things are happening in the space, so I would love to have you back on the show, but I really, really appreciate your time today. Thank you. >> Thank you very much. >> And for anyone watching who's struggling to manage their telemetry data and cost, definitely check Sugout and what this team is building, and I look forward to chatting with you folks again. Thank you.