Unlocking Observability: Insights from Christine Yen – KubeCon Europe 2025
Christine Yen from Honeycomb shares updates on front-end observability and a new telemetry pipeline. The importance of observability in software engineering is discussed, along with the challenges in cloud and DevOps terminology. The rise of telemetry pipelines is emphasized, enabling teams to control their data and gain actionable insights. Honeycomb’s tools aim to enhance engineering processes and performance.
Transcript
This is Textron tv. Hey everyone. We're back here at CubeCon.
If you've been watching in chronological order as we go through these interviews, I don't know how many we've done. 15, 18 today, crazy amount, but this is our last one for the day. They're sounds like they're breaking stuff down.
My friend Christine Yen from Honeycomb. Christine, we haven't had you on tech show TV in way too long. It's been a minute, way too long.
I'm excited to be back though. Thank you you for having me. I'm excited to have you back.
Um, so what have you been up to? Honeycombs been up to a lot. Yeah.
Um, I think last year our, our, we have, we had a couple big announcements. We do front end observability now. Yep.
You know, my point of view, uh, observability has always been, frankly more for developers. Um, and we think front end engineers are part of the software engineering team too. So that was a big announcement last year.
Absolutely. See some pretty cool things coming outta that. We launched our telemetry pipeline.
So, you know, there's been a lot of interest in telemetry pipelines in the market, but our point of view has always been when you control both the pipeline and where the pipe, where the data from the pipeline ends up, you can offer some really cool feedback loops and cycles that benefit both the end users and the budget holders. So we announced that in the end of last year. There's some very cool things coming down the pipe there.
Uh, honeycomb for log analytics is also new. Very Cool. You know, we've always been on the point of view that data is just data and we recognize that we want to make honeycomb and observability more accessible to folks coming from, you know, their logging tools in their logging world.
Um, but really I think it's been continued to be fun to see the observability space mature and folks continue to sort of learn to ask for more out of the tools that they've always used and have this question of like, has the way I've always done things, kept up with the way that I want to build software now and maintain software now. Absolutely. You know, we were talking off camera about how AI can mean different things to different people.
We'll come into that in a bit. Yeah. Well, let me just turn it, observability can mean different things to different people.
Oh, yeah. Right. I mean, you walk around here, I forgot if there was 50 or a hundred companies that claim to be doing mm-hmm.
Either something around observability or, or data, uh, you know, closely associated with of course, observability and, but each one has their own take on it, their own skin. And again, I think that's a sign of a, of an immature market, but a hot market, a contested market, a market that, you know, people consider worthy of, of really pursuing. Yeah.
When do you think we'll see it shake out a bit? Uh, do you think we've settled on a very, very common definition of cloud or cloud native? No, we haven't only have a definition of DevOps or cloud.
Yeah. We're bad with that stuff. You know, I am not one for definition policing.
Mm-hmm. Um, and so, you know, as I see the definition of observability these days, will they stretch? Honestly, I'm fine with it.
Um, I don't wanna be trying to play buzzword matching games anyway. What I like to do then is, you know, if someone says, oh, they're looking for an observability tool, we're, I like to ask what they mean or if they're, if it's a sort of a different entry point, you know, my, the problem that I think that Honeycomb really helps you solve is why is my software not doing what I expect for it to be doing? Um, and how do, and if it's not doing that, how do I fix it?
And I think that that is a, a problem that every engineering team deals with. Uh, but b, that really focuses the lens on what, what people are trying to do with observability tools. I think when people, a lot of people cling to that word or try to define that word, they talk about what it, um, what it entails or like what it is comprised of.
Right. People used to be like, observability is logs, metrics and traces. No, it's not.
Those are three types of data I wanna talk about what, what problem you're trying to solve. Yep. So I don't have a prediction on when we're gonna stabilize.
What I can say is like, this is the clarity I try to bring to conversations around the space. Hey, it's an opportunity for honeycomb. Um, you mentioned telemetry, telemetry pipelines.
Yeah. Let's talk about telemetry pipe, telemetry pipes. We've been talking too much today.
Telemetry pipes. Yeah. I think one of the, the, so it's undeniable.
There's been an explosion of telemetry pipelines in the last few years. Mm-hmm. And I think besides the obvious, like it's trendy.
So everyone wants to be in that space. The, the underlying trend, I believe is that with the rise of OpenTelemetry and the standardization of instrumentation and sort of the move away from proprietary agents, engineering teams are starting to see the telemetry that their applications generate as their own. Yeah.
You know, this is, this is mine. This isn't the, the telemetry that some proprietary agent generated to send a send a proprietary endpoint. This is my telemetry that I get to decide where to route, how to filter, how to shape.
And I think that that makes it really cool to explore, okay, what does it look like to build tools to give more control to those engineering teams so that they can decide for themselves what's interesting, what to do with interesting data, how to make that match their budgets. And to some extent, that's always been the philosophy of honeycomb. We've always talked about sampling.
We have our refinery, um, you know, component that allows folks to really tailor sampling to match their area of interest. Um, and the telemetry pipeline is sort of just a maturation of that route. And I think that there's, um, for, for the telemetry pipelines that are standalone, you know, many of them have a clear story.
It's reduced your observability costs or reduce your data flow. Uh, but there's so much potential for, for telling that whole story of how do you manage your data, how do you use your data, and how do you use signals from each one to make, make it easier to do the other. Yes.
Now again, same issue though. There's a lot of people now, well, let me back up. Take something like OpenTelemetry.
Yeah. It's the second, second largest, uh, project here. There are a lot of people walking on this floor who say all this observability stuff.
It's just OpenTelemetry, maybe Prometheus or something under the covers. And therefore, do I need a honeycomb to gimme that, uh, pipe? Do I, can I do it myself and not, you know, deal with IP issues or no.
Or what have you. And, and in that way, and I'm not saying it's right, don't get me wrong, but there are people Right. You know, some, especially some of the classic open sources Of course, Who say we don't need that stinking commercial stuff.
I can respect that people have that point of view. Yeah. And I think whether you're talking observability or you know, the predecessors logging, monitoring a PM, there's always been two parts of the puzzle.
It's the getting data in and then they're getting data out. And, you know, in a previous generation before Tel Vendors had to spread their innovation tokens over whether they would invest in helping their customers get data in or get the process of getting answers data out easier. And the reason I think, um, a reason I think OpenTelemetry is so awesome, and B, the reason I think that observability is so much more than OpenTelemetry is that OpenTelemetry just standardized the getting data in piece.
Right. Which is great once you get data, data in, no one cares what that's like. Um, and so prior to OpenTelemetry, everyone was just reinventing the wheel.
Wonderful. Now that we have this open standard vendors don't have to waste time, energy, money reinventing the wheel, reinvent the wheel, we can create a better world where end users don't have vendor lock-in can use this open standard and then basically force the vendors to compete on what the best experience is getting the answers out. And so the, the, a lot of those open source solutions that maybe predated OpenTelemetry or, uh, are, are saying this about OpenTelemetry and observability of vendors, I think, again, are entitled to their opinion.
And I would bet there are some pretty cool ways we can answer questions that they haven't been able to Thought about yet. Yeah. Yeah.
But, but that is, trying to think of the company, a friend of mine, so I was involved in Techstars early on in Boulder. Cool. And there was a company, and I, I'm blanking.
The dude was from Mexico. He was working in a McDonald's True story. And he came up with this idea, him and his friend coded it.
It's the piece of an app, like you could, it's a component to an application that'll send off the email. Okay. And I forgot the name of the thing.
It got bought by, um, I think it got bought by No, it's for the one of them. It got bought by. Okay.
Anyway, it was such a, a revelation. It's the same thing you were talking about. Once you, you take that off the table as a, a competitive advantage, then everyone, all right, everyone has that.
What do you do with it? How do you build from here? Yeah.
And that's what, that's, that's what starts separating winners from losers, right? Yeah. If, if everyone has the ability to suck data in how you, as you say, put data out Yeah.
Or, or make that data actionable intelligence or whatever, that's Well, this question, that's the difference, right? That Exactly. And, and this is why I refuse to say observability is types of data, right?
Because if I say that, then absolutely you can just commodify, okay, well, I show a graph, you show a graph. Our tools are, and All our graphs are the same, all Graphs are the same. Right.
But Honeycomb has always been about what can you do with this data? What questions can you answer? What does your investigation look like?
One of our product principles since forever has been no dead ends. Because how often have you used one of these, these tools? You've looked at a graph, you've been like, this looks weird.
Why does that look weird? And you've tried to go in deeper and you can't, and you're stuck. That's awful.
I've been there. My co-founder's been there. And so, you know, one of our core principles was whenever you see a graph, you should be able to stick your hands in, modify it, find out what the, what underlying data is there.
Um, you know, why does it look funny so that you can answer your question and go on with your life. I think that there is so much more honeycombs not a data company. Honeycomb is a tool that provides answers so that you can have better process engineering processes so that your engineering culture can be as high performing as it can be.
It's so much more than just the data and the tool. And again, that's why I question like, yeah, OpenTelemetry is a piece of it, but if you, if all you were in this game for was to take data in and spit data out blindly Yeah. You're, you're, you're missing the whole part of the puzzle and why I think our customers love using us.
I I, I I don't disagree with you at all. I, you know, I, I'll pause it. That even o hotel is not a data thing.
I mean, o Hotel's a way of getting data out. It's a tool. Yeah.
Every company's data is kind of unique to them, and how much value they get from that data Yeah. Is somewhat your job. Right?
That's what they're coming to you for. Yeah. We have this data.
Getting it out is relatively, you know, table stakes today. What could you do with that data for me, that doesn't make you a data company that makes you an actionable company. Right.
You And what's funny is, again, it's it's never like a a one way street, right? No. With Honeycomb, a thing that we often see with our customers is they're, they're realizing that we can let them do things with their data that they hadn't considered before.
And so it, it lets them go back and it, it lets them add things to their data where, you know, if they're one click checkout platform, now they can add merchant ID and be able to break things down from, from merchant. They're able to add, well, We're finding things that we're not able to be combined before. And that's like synthesis, right?
There's a lot of conversation about, um, like business context in DevOps and previously business intelligence and DevOps, you know, never the twain shall meet, right? And we're seeing a lot of these engineering teams realize, oh, if I put some of these concepts that exist, like at the company level into my engineering telemetry, I can start to do things like demonstrate engineering impact in a way that my CFO can understand. Oh, I can talk about this to the product team.
And that, that is the sort of thing we see be transformative. That's right. That's where inspiration Yeah.
Comes. Yeah. And it goes from There.
And this is where if you're just like, oh, it's OpenTelemetry, and then we show a graph, like you're not, you're not gonna get that kind of, those light bulbs. So I will tell you, you need to just walk around the floor and tell people that stuff because there, there definitely is that undercurrent. Anyway, we gotta wrap up.
All right. Hey, we didn't mention Honeycombs website. io.
There you go. You know what, I've been following Honeycomb and Christina and Charity and the whole Honeycomb team trip for a long time before Observability was cool. They were observability and they're still cool.
Check 'em out. We're here at K Con, we'll see you all tomorrow. Alan Shimel.
We're out.