Observe CEO Jeremy Burton on $156M Raise and the Future of Unified Observability

Hey guys, thanks for the throw. We're here with Jeremy Burton, who's the CEO for observe, and they're fresh off of picking up 156 million in additional funding, which is going into a platform for both IT monitoring and observability. And well, there's a lot happening in that space.

Jeremy, welcome to show. Thanks. Good to be back, Coles.

Good to chat. You know, when we first started talking, I think, yeah, every IT organization had some level of monitoring of some sort of predefined set of metrics, and then we all talked about observability as if it was gonna supersede monitoring. And as we kinda look back at it now and kind of feel like it's clear we need both and there's different functions, but can we put all that together in a single platform?

Yeah. I mean, I think, you know, because you do observability, the need to monitor doesn't go away, right? I mean, I, I think monitoring one of the, the primary functions of monitoring is, it, it tells you if you have a problem.

And in, in any scenario from, from now, even into the glorious world of ai, we'll, we'll need to know if there's a problem. I, I think what observability is done is really allow people to investigate and, and ask the question, why? Why, why do I have a problem?

And more importantly, what was the cause or root cause of that problem? So I, I think, you know, every organization, I think some folks would define observability to be inclusive of monitoring. Like we would do that, uh, some folks would send in our monitorings over there, that's gonna detect problems, and then observability is over here, and that's gonna allow us to investigate.

But I think it is certainly correct that organizations will, will need both. So you've been at this a while now, um, but I'm not quite clear. How big is observe these days?

How many customers are we talking about? And, um, what is the scope of the ambitions from here? Yeah, so we tended to focus on the larger organizations.

Um, you know, I think there's a lot of players in the observability space. And, and so I think the low end of the is quite crowded. You know, you can take your pick between sort of open source or, or commercial vendors.

Uh, we've tended to focus on organizations that are ingesting sort of tens or even hundreds of terabytes a day. So a customer count now is, uh, over a hundred. Um, but what's interesting about observe is, um, you know, the, the size of customers we have about, uh, 11 customers now that pay us over a million dollars.

And that's generally because their volume, uh, the data volumes are in the, in the, in the tens, as I said, in some case, hundreds of terabytes a day. So what makes somebody wake up in the morning, especially an enterprise that's been at this for a while and say, we need a different approach to monitoring and observability? Yeah, it happens a lot.

And I, I, I'd tell you that one of the key, uh, determinants of this is, is the growth in the data volumes. Um, certainly when the world moved to, to distributed applications and Kubernetes, you saw like a three to four x increase in the volume of telemetry data. Um, most incumbent vendors would, would charge you by volume of data ingested.

And so the bill that was, you know, once 500 grand a year is now 2 million and sort of on its way to 3, 4, 5. And I think that gives people pause for thought, you know, is there a better way? Um, and so one of the things that, you know, we did from, from the get go is we, we bet on a, on a much more modern architecture, you know, if, if you could ingest data into sort of cheap S3 storage, um, if you didn't have to build indexes, um, if you had elastic compute, then you know, you could put a big dent in the cost of observability.

So I would tell you that like 80 to 90% of the conversations, uh, uh, one of the, the primary motivations is, is, is cost. Um, and then the second tends to be frustration with the lack of visibility, uh, frustration with how elaborate the troubleshooting process is. And by the way, some of this is, is back related to cost.

It's, we wanted to keep our bill down, so we started sampling our traces, we started filtering our logs, and so now we have blind spots. And so now we can't troubleshoot the things that we need to. So, you know, a a lot of, a lot of the, the, the sort of root of all evil, so to speak, is, is cost because of the growth in the telemetry data volumes.

I also wonder though, are we hoarding too much of this telemetry data? I talked to folks and they want to keep log data forever, and maybe we can just get smarter about identifying which of that data we actually need and for how long? Y Yeah, I think that that's a factor.

I mean, I, I, I think over the last, certainly the last three or four years, you, you've seen the rise rise of, uh, pipeline vendors, you know, uh, like Cribble, for example, have done very, very well. And the key value proposition of something like a cribble is to filter out logs that you know, you don't need. And so, you know that that is certainly one way to, you know, put a dent in, in the cost, but the, the, the data volume keeps growing and it's not always obvious the logs that you need to keep and the logs that you can safely throw away.

Um, reminds me, you know, years ago, uh, when I was at EMC, we had this whole strategy of, of, you know, the, the information lifecycle and you know, you, it was created and then you would store it and ultimately you would retire it. And the challenge with retiring data is you don't know when it's gonna be needed in future. Um, and if you see a problem in your systems that you've never seen before, you w you may well need to query telemetry data that you've never used before.

And so, you know, it's not always obvious exactly what you need to throw away. At a certain point you need to keep it. Um, and then, you know, on something like tracing, you know, it's been quite common for years to sample traces, but again, you know, at some point you may well encounter a problem where you need a much higher fidelity of trace data than maybe you've ever needed in the past.

Um, so I think, I think pipelines and throwing data away is a thing. Um, but you know, to a point, you know, you, you, you don't want to do it, uh, to the extent whereby, you know, you've got blind spots or you're losing, um, sort of fidelity and you can't drill to investigate the thing that you really want to. Um, and then there are organizations that for compliance reasons, they have to keep it around for, for, for seven years or, or, or what have you.

Um, and, and I think, you know, in those scenarios where you have to keep it around, you want the cheapest way possible. And, and I think this is why sort of moving to just extremely low cost object storage and then compressing the data on top of it and, and leaving it in a place where it's not gonna cost you a lot of money to retain it for years on end, it it is, is kind of essential. Now you've been around data storage for as long as I can remember, maybe even took on of time.

But, um, is there something that's different about telemetry data from other kinds of data that has unique attributes that we should be thinking about as we kinda collect it, store it, and analyze it? Yeah, I mean, I, I think the way the world is going, although probably not quickly enough, I mean, a log and a trace are not that different. I mean, arguably a trace is, is a structured log.

And I think what the world would be better for is if all instrumentation in all applications was essentially a structured log, uh, because anything that's structured is, is then much easier to query and to reason about. And if, if every log was structured, then we wouldn't need the trace, or if every trace, you know, if our print another way, if all our instrumentation was trace, you wouldn't need logs. And so, um, open telemetry I think deserves a lot of credit for, uh, trying to standardize instrumentation in applications.

Um, I, I think the, the longer we go here, the more instrumentation is going to be structured, the meaning that the, the less duplication will have an instrumentation, and there is a chance at least that the, the rate of growth in telemetry, uh, will slow down. And I think generally that, you know, that will be a good thing. Um, on the other side of things, I would also say we, we have projects underway at observe to do this.

Um, engineers don't like instrument in code. You know, they, they wanna work on building features, right? No one wants to go back and add instrumentation to code.

And as much as open telemetry, uh, does have capabilities to auto instruments, um, it, it's, it's not sort of exhaustive. It doesn't give you all the instrumentation that you would need. And so we've been, um, working with some of the, uh, new cogen, you know, AI cogen tools, uh, to, to figure out ways in which you can, you can prompt these tools to automatically generate the instrumentation.

Um, or, and, and, and by the way, that, that could be if you've got a Greenfield project and you, you do it from the get go, um, or it could be if you've had a problem in a particular part of your code and you've struggled to do the debugging, um, there's no reason why you couldn't have a friendly agent, you know, lurking behind the scenes suggesting that you might need more instrumentation and going and creating that instrumentation for you. So I think the world is gonna change, um, uh, to the, to a greater degree in the next few years because of not just auto instrumentation, but the ability to generate instrumentation from some of these new AI tooling. Um, and I think that there is then a possibility that at some point here that you could use these tools to rip out your legacy instrumentation and put in brand new structured open telemetry instrumentation, which will make it much, much easier to debug on the other side.

So a lot is gonna change the next few years. Do you also think that maybe AI will force that issue because we want to use AI agents to help manage it, but the more structured the data is that they're presented with, the more likely it is they're gonna come up with the right answer for either suggesting something or automating something. So are we on the cusp of kinda being, for lack of a better phrase, forced to instrument thing with a whatever the level of discipline may happen thus far?

Y yeah, because I, I I, I think it is now possible to, to give the level of instrumentation that you need without putting the burden on developers. I, I think the, the, the, the critical, the critical thing is that like developers will, will, will instrument their code if they don't have to do any work. And, and I, and I think the, the ability to generate that instrumentation or, or have an agent generate that instrumentation is, is the big unlock.

Uh, the second thing I'd, I'd tell you is, um, no developer really wants to learn an observability tool, right? They, they, they want to be able to answer questions about their environment from that IDE. So I think the other thing that AI is gonna change here is it's, it's gonna make observability data much more accessible.

So I as a developer should be able to sit down, you know, in my IDE and I'm using Cursor or augment or something like that, and I should be able to have a workflow which says, uh, Hey, augment, look at this ticket, uh, go work with observe to investigate the 500 errors. Um, figure out which part of my code it's in, explain that code to me. And if you can suggest a PR and, and that, that I think a even a year ago or even six months ago, you would've said, okay, that's rocket science.

Like, no one's gonna be able to do that kind of a workflow. But I would tell you that we have customers today, early users of our MCP server that are doing exactly that, and, and it's only gonna get better, um, you know, in the, in, in coming months and years. So I, I think AI is gonna dramatically change.

And like the, the first generation of ai, which we've talked about in the past, AI ops, which I was not a fan of, this generation of, of AI tooling, I think is gonna be a, a, a big unlock for developers, and I think it's gonna change observability forever. To that point, one of the issues that I think we've had is that developers didn't wanna maintain the, the agent either. It was basically an entire DevOps workflow just to maintain the agent.

So will that become simpler as well? Yeah, I mean the, the, the agents that, uh, you use to collect the telemetry, I mean, um, we, we started off determined not to write our own agent. We, we would use things like fluent bits and, uh, telegraph to, you know, collect metrics and, and, and logs and so on.

Uh, the nice thing is, is in the last probably 18 to 24 months, I think open telemetry, the over telemetry agent has really solved that problem, right? And, and I feel like a, an open way of collecting telemetry is, is now available to everyone, and there's no reason why vendors should be deploying their own proprietary agents, uh, into production. And I think from a customer perspective, you know, they're, they're sort of fed up with the proprietary agents as well because that, that is part of the lock-in.

It makes it much harder for them to change vendors if you've gotta, you know, deploy a proprietary, you know, agent to, uh, to collect information. So I think that part of observability is, is, is in a very, very good place. And then I, I'd even tell you that, um, and this is one of the things that, one of our big projects right now is the agent is gonna send telemetry, um, you know, to, to a product like OB observe.

Um, we now are storing that data, um, in Apache iceberg format. So, so even the storage format for the telemetry is now standard. And so again, you know, we'd love it if our customers used observe forever, that would be awesome.

But if at any point they choose to maybe go to a different vendor, at least they've got open collection in place, they've got an open format for their telemetry. And so any vendor that supports iceberg and supports open telemetry collection, then, you know, should be able to operate that. And so maybe for the first time error, you know, customers and you know that they now own that telemetry, not the vendor, 151 million is nothing to sneeze at, but it's not AI billion dollar money.

But what's the plan for this? I mean, what, what's left to be done? Yeah, there, there's, there's plenty left to be done.

Plenty, plenty to keep us busy. Yeah, I'd say, first of all, um, and we've talked a little bit about ai, um, there, there's a, a number of transitions there. I mean, I think number one, we would like to have a full AI native experience when using observe.

So I should be able to converse with observe using a natural language. Um, we, we started to roll out via our MCP server, but there's a lot more work to do there. Um, secondly, um, for the last decade or so, we've had sort of distributed microservice based Kubernetes applications.

The next generation of applications are gonna be, uh, agen AI applications. So, you know, sort of search and replace microservice with agent, and you've, you've got a new app, a new kind of application. Uh, these agents are gonna interact with each other, they're gonna interact with LLMs.

Um, it's all great until something goes wrong. How do I troubleshoot that kind of environment? So we, we recently released something called, uh, LLM Explorer.

Um, that's the, the first release. But obviously, you know, there's a lot more work to do in, in that area. We, we want to be the absolute best at troubleshoot this new breed of, of, of AI applications.

Um, and then on the backend, um, I mentioned earlier we we're making a, a huge sort of architectural shift to, to support Apache iceberg. We want a completely open backend. You know, we, we very much feel like observability ultimately is a game of analytics.

And we want customers to be able to ingest data in an open format and store it in an open format, and really allow them to purely focus on answering questions, whether that's through the observe UI or whether that's from their developer. You know, IDE so plenty of r and d work. And then, you know, we, we inevitably have to hire more sales people because, um, revenue growth, we almost tripled last year, year.

Um, so that, that always feels good. Um, but, you know, the, the hill only gets steeper. Um, and so you generally have to keep hiring in order to, to keep making more money.

All right, folks, well you're hearing in here, observability monitoring, it's instrumentation, it's all coming together. Finally, the question is, is now how quickly can we take advantage of it? Hey, Jeremy, thanks for being on the show.

All right, thanks, Mike. All right, and back to you guys in the studio.