Shahar Azulay: Why the Cost of Observability Is Poised to Decline

Hey guys. Thanks for the throw. We're here with Shahara.

Azule is the CEO of ground cover, and we're having a little chat about observability because, well, the game is changing. We have more, uh, bring your own cloud kind of environments. We're talking about, uh, repatriation and workloads sometimes, and even sovereign clouds are an issue.

And well, we need some way to observe it, and well, right now, that may be a little harder than we think. Shahar, welcome to show. Hey, Mike, thanks for, thanks for having me.

So, walk us through what's changing here. We, you know, historically we go all the way back to, we had application performance management platforms, and then we saw the rise of observability, and, but we now have workloads that are kind of more distributed than ever. So how does that change the way we should be thinking about observability?

So basically we, we see that kind of as, you know, a few waves of, uh, software delivered. It's kind of changed over time. Uh, if we, you know, roll back maybe 20 years, right?

Uh, some of us, uh, you know, remember that that period of time we used to kind of consume software like a physical product, right? It ran OnPrem. We used to purchase it, maintain it.

Uh, it was ours, kind of, uh, in a, in that sense. And, you know, suss kind of changed that, right? Uh, we used to, we started consuming software over the internet online.

It made sense. And, you know, with the boom of cloud, it kind of all connected to the fact that basically we're consuming everything online, right? All of our services are almost third party managed.

Um, this starts to make less and less sense with data rich, uh, applications like observability, security, ai, when the third party is basically holding a lot of data or consuming a lot of data from the customer side, for example, for absorbability, which ground cover, you know, that's our field. Um, we have a, you know, our, our medium customer sends a hundred terabytes of logs per day, you know, to the backend, right? Sending that over to a SUS vendor.

That's where the SUS architecture kind of starts failing, right? It starts consuming a lot of data is start to pay for it. You start to be concerned about data privacy, data residency, data security, uh, you know, while shipping all that over the internet.

And that's, uh, where SS is evolving to what we call BYC or bring your own cloud. So does that mean I need to move the observability platform into something that looks more like an on-premise environment? Or am I trying to get to something that maybe is a little more federated?

How will this play out? So, uh, we we're all used to thinking about on-prem and sus as a binary choice, right? A mire running everything OnPrem.

And then, you know, I'm, I'm biting my tongue on management and, you know, maintenance, and I have a team kind of taking care of that, but I gain data ownership, I gain security, I gain, I gain control, customization, whatever I want, right? Or I choose the other part of the binary choice and just take a suss vendor, and then I get a managed solution. You know, headache, no headaches, you know, someone's managing it for me.

But I lose that sense of, you know, budget control data, ownership data and all that. Bring your on cloud is basically kind of the, both, the, the best of both worlds in one. The data plane is on-prem, which basically just separates the, what, what is the data?

Plane and control plane is us. The data plane is on-prem, like you used to thinking about on-prem. It's yours.

It's running in your cloud premises. It's secure, it's private, but the control plane basically manage the infrastructure that all this, all this data planes resides in is managed remotely through cloud primitives. That basically allows us as a vendor to scale it back it up update features, fixed bugs like you would expect from a sus vendor, right?

So you get all the benefits of suss of hands off deployment. Someone's managing it for me, guaranteeing SLA resiliency while the data plane is OnPrem. So I don't have to worry about, uh, data cost, data residency, data privacy, or any of these things that I lose when, you know, shipping the data to sus vendor.

All right? So I get to have my cake and eat it too, as it were. Um, we were also talking about the age of ai, and I cannot help but wonder if these AI agents that we're all trying to build will, um, also maybe provide a layer of, of abstraction for engaging with observability data that I may not know or, well, I, I'm, I'm probably still gonna care, but I don't necessarily need to know where the data actually resides that I'm launching my query against.

Is that fair? Yeah. And I think, you know, it's clear where the world is going to, right?

Uh, anything that is data heavy is gonna be, uh, abstracted away by ai as they say, right? I, not everybody can, can be a power user. Not everybody can know how to query their logs, traces, metrics, whatever it be, you know, with a proficiency of what AI can offer.

Basically, we can think about it as, you know, the best SRE in your team that you just, that don't have, right? That knows how to get insights from this data that we collect. Um, and this is exactly where bring your own cloud, that that's our belief, right?

That bring your own cloud is enabler for ai. Because again, sus kind of wears away a lot of what AI needs to be, uh, performant. You know, one of the things that AI must have is all the data in one place, right?

When it comes to sus, um, already, you know, um, I already have a lot of friction with the vendor about the pricing model, like paper gigabyte. I, I'm trying to reduce the data that I sent out. And we see that the, the market is moving away from that, you know, single pane of glass dream into multiple vendors after, you know, organizations kind of optimize the pricing model for each of the verticals and observability, right?

They have logs there and traces there to kind of survive the day budget wise. So that kind of wears out what AI can do because data is distributed. And also I'm, I'm constantly trying to reduce data volume, sample rate limit because I don't wanna pay for all that, right?

Mm-hmm. When it comes to bring your own cloud, suddenly we go back to the basics, right? All the data's in one place.

You can store 10 export data, which with much more cost effective choice. And you also get data privacy and the use of your AI in your cloud. For example, if you're using AWS and you're using Bedrock because you don't wanna send all the data to open ai, which makes sense, right?

You can use Bedrock on top of your, bring your own cloud and basically consume your observability data with the AI agent of your choice inside your cloud premises. So we see it as enabler of people being able to even easier con con consume, uh, data with the abstraction of AI, query data with ai, get insights with AI over the bring on cloud, uh, data plane if you want, Right? And if I don't do that, don't I wind up in some sort of weird paradox because I'm limiting the amount of data that I send into the observability platform, so I'm not getting as broad an analytics analytics as I should be, and therefore I'm just kind of making decisions on a narrow based set of data that's probably not helpful.

Yeah, I mean, it's, it, we're, we're, you know, entering 2026 in a second, right? And about three quarters of the world, uh, the organizations of the world, right? Don't have traces.

That's, that's the situation right now. I mean, open telemetry adoption is slow. It's hard.

People don't have traces. So say you ask your AI agent, tell me what's wrong with production, right? Um, it's a, it's only as smart as the daily feed into it, right?

So if you don't wanna pay for a PM or you don't want to instrument a PM, um, you know what the AI agent can do, right? Use the data that you have, the logs that you've instrumented, the things that you put in. It's only gonna be as smart as that, right?

So with bring your own cloud, with the EBPF agent, for example, that ground cover facilitates, it's the ability to, to collect data that that is agnostic to what your developers are doing, but also store masses of this data without being concerned about, uh, budgeting and trade off as much, right? So suddenly you can ask questions, and the AI model will now have much, much more granular data to operate on top of it with all the contextual, um, correlation that it needs to kind of get that insight. And that where it becomes really, really powerful, because that's where I shines, right?

Going through terabytes of data and, you know, getting that, uh, needle in the haystack when all of this data is, you know, granular and contextualized and collected properly. Mm-hmm. And I'm not sure everybody knows what EBPF is, but it basically sits in the Linux kernel and kind of gives you visibility up into everything that's running on that version of Linux, per se.

Um, does EBPF eliminate the need for open telemetry agents? Or are they gonna be more complimentary to each other? How's that gonna play out?

Eventually, we see it as complimentary, but, um, the reality is that EVPF is, uh, is a, is a different way to observe the data. And the most important, uh, reason for it to be very, uh, effective is the fact that it's completely decoupled from your, what your development or developer organization is doing, right? Opt telemetry requires you as an r, as a v, vp, R and d or you know, as an RD team to take that journey, right?

Instrument, open telemetry, figure out how you wanna use it, figure out how you wanna sample it, what you wanna instrument, and then take on this journey, which again, most organization will never finish, right? Not because they don't want to, because not everybody knows how to be proficient in something else, but the product they're building, right? It requires a different set of proficiency.

EDPF is kind of decoupled, as you say, from the Linux ker. It's a Linux kernel capability. I can observe traces going in and out into my application without you doing anything as a developer.

So suddenly I get that unbiased, um, you know, kind of layer of observability that will always be there, regardless of whether you've instrumented or not. If there is a specific point of work to instrument with open telemetry, great, that's already opinionated. You care about it.

So we'll, we'll enrich that with EPF and make sure that the two combined. It's not, it's not to say that open telemetry isn't important, but it's so hard to get sometimes that EPF is just there to kind of, uh, you know, cast a wide net of anything you're missing, Right? 'cause otherwise, I kind of have to have a set of DevOps engineers who know how to deploy open telemetry so I can instrument my applications that the rest of the DevOps team is installing.

Right? Exactly. Which is not easy, right?

Not, not everybody can, can go through this journey and be successful at that. Hmm. Ultimately, is observability gonna become a lot more accessible?

And I'm asking this question. 'cause when I talk to people, uh, initially they were all, at least, you know, we have monitoring tools and those are predefined sets of metrics, and they're kind of like, well, that's good enough for me, because frankly, I can have an observability platform, but I don't even know what questions to ask it. So are we gonna get to the point now where the AI knows what questions to ask and therefore can really, you know, augment and help me out and make observability worth the journey?

Yeah, but I, I, I think we're definitely going there and, you know, AI is gonna help a lot. But again, I think the problem is so, so much more basic. Most organizations are, you know, in survival mode of the data that they collect, right?

Um, you know, when we, when we think about bring your own cloud from the ground cover perspective, again, you can think about it as an architectural meta method, right? To change the way data is being stored and managed. Uh, we could have stopped there and say, great, you know, the data's run running on your, uh, you know, data play right now, it's in your cloud premises.

Uh, we did our part, right? But that's where we take it to the next level to make observability more accessible. Because one of the things that are most painful right now is that observability is packaged because of that price per gigabyte that, you know, that data budget trade off, it's packaged with multiple different, uh, product lines.

Uh, most big vendors have 20, 30 different product lines. You pay for log management, you pay for infrastructure monitoring, you pay for a PM all separately, right? So not all organizations choose to activate all these features.

And, you know, again, when AI comes, comes into the picture, if you don't pay for the data, AI is not gonna know anything. So that's where Corp, for example, took that choice of, if we're already doing, bring your own cloud, if we're already sa saving the data on your premises, if you're already paying for it as a customer, right? 'cause we, we've separated that equation, now we can package the product differently and we, um, provide all the ver verticals of observability all under the same pricing umbrella.

And therefore, when it comes to ai, all of our customers will have traces, all of our customers will have logs and metrics and so on. And that's, as you say, where AI will come in and basically alleviate a lot of the, you know, query language barriers, how to build alerts, how to build dashboards where people kind of get stuck. This will make everybody a power user, but the data is the most important thing on that journey, right?

And once I have that level of observability, well, I need my traditional monitoring tools. 'cause it seems to me like I could just program the observability tool to monitor things already. Uh, well, we, we definitely imagine a world where you, you're not, you don't necessarily visualize and set alerts like today, right?

It's every, everything is very structured, limited right now. You wanna visualize a specific graph, you wanna set a specific alert. It'll definitely be much a bit more flexible than that, right?

You will correspond with, you know, your observability agent to, to that sense a bit more freely, a bit more unstructured. And data will be, um, you know, um, much more accessible outside of these, uh, specific use cases where we, we, they're, they're definitely still gonna be there, right? Of setting alerts, getting them into PagerDuty, you know, waking up at night and all that.

Uh, but data's gonna be a bit more, um, flexible to, to access and query and engage with, uh, outside of these, you know, strict, uh, options. So what's your best advice to folks about how to get to where we want to go? Because I think a lot of folks are kind of overwhelmed with the, with what the piece parts and everything that has to come together.

But is there a simpler way to get started and where is that? Yeah, so I, I think, I think my advice is definitely, you know, figure out if you're, if you're paying right now, is that you don't have all the data or you're limiting some of the data, uh, in, in most cases, the answer is yes. If, if, so, I think you need to look into alternative architectures and alternative data collection methods like EVPF or BRI and Cloud.

com and see that in action. But it's just an example of how the, how the market is shifting towards, uh, new data collection methods, which, which are easier and new architectures for observability that makes sense, right? That are scalable, that allows you to store the data that you can so that you can definitely query it, you know, with AI and with all the use cases we discussed.

All right folks, you heard it here, observability. It's really a data management problem and work backwards from there. Hey Shahar, thanks for being on the show.

Thanks for having me, Mike. All right, and back to you guys in the studio.