In this RedMonk conversation, Austin Parker, Director of Open Source at Honeycomb and a maintainer of the OpenTelemetry project, chats AI, Olly, and OTel with Kate Holterhoff. They explore the implications of AI on SREs and observability practitioners, the development of honeycomb’s MCP server, and the challenges vendors face in adapting to changes in the observability space. The discussion also touches on the balance between speed and quality in feedback, the complexities introduced by software abstractions, and the future role of OpenTelemetry in the AI-driven observability space.

Honeycomb is a RedMonk client, but this content is unsponsored.

Links

• LinkedIn: Austin Parker
• Bluesky:@aparker.io
• “How Does ‘Vibe Coding’ Work With Observability?,” Honeycomb Blog, 7 April 2025.
• “It’s The End Of Observability As We Know It (And I Feel Fine),” Honeycomb Blog, 9 June 2025.

Transcript

Kate Holterhoff (00:12)
Hello and welcome to this RedMonk conversation. name is Kate Holterhoff, Senior Analyst at RedMonk. And with me today, I have Austin Parker, Director of Open Source at Honeycomb and a maintainer on the OpenTelemetry Project. Austin, thanks so much for joining me on the MonkCast.

Austin Parker (00:27)
Thanks for having me, it is super great to be here. Finally.

Kate Holterhoff (00:30)
So exciting. I know, I know. We’ve been talking about this for a while. I think at least since Render definitely last year, I think it came up.

Austin Parker (00:37)
Yeah, I feel like we keep, every time we run an intro, we we gotta do the pod, we gotta do the pod. And then it never happens. And then, and now we’re here, we’re doing the pod.

Kate Holterhoff (00:42)
Yeah, I know we’re done kicking the can down the road. Okay, well for the benefit of folks who maybe haven’t had the chance to chat with you, why don’t you tell us a little bit about what you do at Honeycomb and yeah, just maybe some of your background if relevant.

Austin Parker (00:57)
Yeah, so as you mentioned, I am director of open source at Honeycomb, which is You you wear a lot of hats at any small company slash startup. And I think I am trying to get a record of how many hats I wear at Honeycomb most days. But this year at least, I’ve been involved in two big things. One is working with our product and engineering teams on…

how to really embrace OpenTelemetry as a company. think one interesting thing about Honeycomb is that we were very early to the OTel party, where one of the, I would certainly argue, most OTel native observability tools out there. But even with that said, there’s always more to do and OTel is always changing and growing.

I really try to help our engineering teams be aware of what’s coming and how to really make sure that we’re aligned with what OpenTelemetry is doing. And then also this year I’ve been doing a lot with AI. I’ve been working with our AI team on some of our recent product launches and experiences. I helped build our model context protocol server this year. I’ve been in a lot of stuff like that and it’s gotten me thinking a lot about

observability and our new AI overlords. So that’s been fun. Outside of that, I do a lot of work with the community. I help organize the observability day at KubeCon, OpenTelemetry community days and open source observability summits. Working on some stuff for next year right now too. OTel Unplugged, which is going to be at FOSDEM with our friends at Grafana.

and I am also working on, and in my copious free time I’m helping write the next edition of Observability Engineering.

Kate Holterhoff (02:58)
Wow. my god. Yeah, so I am learning a little bit in this conversation. let’s dig into some of that. This is exciting. All right, so when I invited Austin on, I asked him what he’s been working on lately in terms of like…

thought leadership and he sent me two blog posts. will provide links in the show notes. The first one is, it’s the end of observability as we know it and I feel fine. You know, as someone very close to Athens, Georgia, geographically, you know, I love a REM reference, so that’s fun. I don’t know, who are these people? And then the other one is, how does vibe coding work with observability? Which I cite in my recent piece on the hot vibe code summer.

Austin Parker (03:27)
Who doesn’t?

Kate Holterhoff (03:42)
RedMonk’s blog, so I certainly got some interesting tidbits from that. so I’m hoping we can dig into some of that in addition to, I don’t know, I guess your larger projects at work and in the OpenTelemetry space. So can we begin with MCP? I think that’s a good starting place. All right, so you mentioned in one of these pieces that you built the MCP server, I’m sure, with some help.

Austin Parker (03:58)
Let’s, yes.

Kate Holterhoff (04:08)
at the MCP server for Honeycomb, and that Claude code can use it autonomously. so you mentioned that Claude code wanders off sometimes to query Honeycomb unexpectedly, but actually helpfully. And I thought that was a really interesting framing. So just maybe lay out the history of the MCP server at Honeycomb, what it’s doing and like, what are some of these use cases that you’re seeing?

Austin Parker (04:31)
Yeah. So I think, you know, quite broadly.

You say anything about Gen AI or MCP or whatever and in six months you’re to be proven wrong by the the Interactable March of History. And so I think it’s interesting you brought up that that it’s the end observability as we know it piece, because that was about six months ago, I want to say. Give or take, right? I that was like March, April time frame.

Kate Holterhoff (04:55)
Okay.

Austin Parker (04:55)
And since then, I think there’s been two things that have really happened around MCP and around this AI-powered observability space that’s been really interesting to me. One is I’ve had a lot more time to play with it. And let’s start with that. for those that maybe don’t know, or just a general primer.

At the end of the day, any observability tool is just a fancy query interface, right? You have a bunch of data that is some type, metric, log trace, whatever, right? But you have this big honking stream of data and you need to get through that data and you need to be able to say, ask good questions, ask questions like, okay, hey, I see this thing change. Why did it change? Right? Help me correlate all this stuff together. Help me like figure it out. And

Historically, an industry, we’ve really built query languages, we’ve built very fancy machine learning primitives and ways to sort of surface interesting things. We’ve built these pre-built dashboards and alerts and runbooks and all this stuff to really help to say, okay, I have this data and I kind of know what this data is because I either…

wrote some instrumentation for this very common framework. And I know that when this particular signal goes up too much, that’s bad. And so I’m going to codify that. I’m going to put it in a dashboard, and I’m going to ship it to someone and say, OK, you’re fine until this squiggly line gets too squiggly, and then it’s bad. Because all of this stuff is more or less known. We know generally.

what to care about with an HTTP server. We know generally what to care about with gRPC or we know generally that like error logs mean something is going wrong, right? Like an exception, a stack trace, that’s a signal that like something happened and we should care about that. And we’ve written all this stuff down over and over and over on the internet. And so it should be little surprise that when you take a large language model that is basically trained on, you know,

all the data on the internet, but it also can see like, hey, there’s an exception. That means something’s weird, right? I should care about that.

And I think, and that’s really what led me down this road of MCP in the first place, because my thought process was, you know, this is somewhat not unorthodox thinking at Honeycomb, I would say, you know, the unknown unknowns place, right? But most things aren’t unknown. Most problems that happen in software systems are pretty like they’re not novel.

The novel failures are when you are the result of complexity, right? Like as I get more and more things and a lot of, you know, boring failures tend to accumulate into novel expressions of those failures or like, I have five things that all could happen, you know, that all independently could happen and it’d be fine, but when they all five happen at the same time, like that causes a problem, right?

Like there’s all the… da da da da da da da. Most, you know… I think from a practical perspective, most problems, the way they present are novel, but the problems themselves are not novel. And so if you take that realization, you say, okay, what is the language model good at doing? It’s good at finding patterns. It’s good at like searching through this compressed knowledge of everything on the internet.

If you suddenly give that model the ability to say like, okay, let me go look at data to query across all of this data, then the model is able to do that faster and better than a human. Like when you get down to it, right?

It there and there’s never going to be a time. That’s not true. Which is what led me to write that post in the first place, right? Like there is never going to be like there that we’ve definitely hit this thermocline, I think where. The models will get, you know, you could argue maybe that the models won’t get fundamentally better. I don’t necessarily know if that’s a bet I would take, but you can definitely argue that. They’ll get cheaper to run, they’ll get faster.

they’ll get more efficient, they’ll get better at using tools, they’ll get better at all of these things maybe even if the level of intelligence quote-unquote never really gets above where we’re at right now. And when you combine that with like, most failures, most things aren’t actually in and of themselves non-novel problems, they’re just a combination of these boring problems put together.

then humans are kind of cooked when it comes to the observability game, right? Because you’re always going to be in a place where the robot can now go off and look and come up with hypotheses and generate and discard things much more quickly than I ever can. It can be wrong a hundred times before I’m wrong once. And that, think, is really powerful. That’s a really powerful

Model for us to internalize as sort of like people that care about observability So that’s that’s what got me thinking about You know that that’s what got me down this path right like hey if we can do this if we can really automate this hypothesis generation Then how far can we run with it? What can we really do with that and what I’ve seen, you know over the past six months or so We’re working in this space of writing

the MCP server and getting it front of customers. And that’s what I’m finding people are doing, right? Like the people that we have that are more AI native, you know, they’re just using the AI to do their investigations, right? When a problem happens, they’re not going into the UI, they’re not going and looking at a dashboard, they’re saying like, hey, Claude, what’s up, right? Like figure this out. And yeah, Claude might be wrong the first time, it might be wrong, you know, but…

it gets the right, it can get to the right answer eventually, or it gets the right answer like when you work with it. And you can take the things that you learn and you can sort of, that makes you better at doing this again the next time, right? Because now you can start from position of like, okay, well, I know it’s probably not all of these things. And so I’m going to put that in some sort of rules file, or I’m going to give the model guidance when I prompted to say, hey,

It’s usually something over here, right? Like you’re working with the AI to come up with these patterns of using it that make you more efficient at using it and reduce the number of like…

you know, I’m gonna go over this way, I’m gonna go over that way, right? Reduce the amount of side quests that Claude goes down.

Kate Holterhoff (12:03)
So I thought what was so interesting about that argument and, within the piece, it’s sort of a 60 cent investigation where you have this demo and you’re saying that AI is solving a a complex latency issue for like 60 cents in 80 seconds. And so I feel like there’s two takeaways from this. And the first one is, to the practitioners themselves, like, are we then going to abandon?

the SRE teams that have historically done this sort of work. And the other one is to vendors themselves. And this is, you have some amazing framing around this. say, if your product’s value proposition is nice graphs and easy instrumentation, you are le-cooked. You left out the le when you mentioned cooked earlier. And it’s inexcusable because that’s hilarious.

Austin Parker (12:41)
I did, I’m sorry.

Kate Holterhoff (12:50)
So I want to talk about both sides of this. And let’s maybe begin with the vendors. So what sort of advice then are you giving to vendors who have maybe historically had very beautiful graphs and easy instrumentation? What pivot are you recommending to them?

Austin Parker (13:07)
Yeah, actually want to swap the order real quick because I think what you see… because what the vendors are doing is they are starting from that first part, right? They’re starting from the position of like, oh, well, you don’t need an SRE team anymore. And what I think is interesting is that the other thing I’ve noticed in the past six months is how incredibly wrong that is. Because I have talked to a of people that are, you know, I’m not going to name names. I’m not here to drag people, but I’ve talked…

Kate Holterhoff (13:10)
Let’s do it. Yeah.

You

Austin Parker (13:34)
I’ve talked to a lot of people at a lot of companies that you and I have both heard of who have been evaluating, know, AI SRE agents because that’s, you know, now that’s the hotness, right? It’s MCP. Who cares about MCP? Now it’s agents.

But there’s a lot of companies out there that are building the idea of like, you don’t need a human SRE team anymore. don’t need people to do this. You just need a bot that can go off and do all this stuff for you. And I think, and the practical experience that I have seen people have, at least with off the shelf stuff, I’m gonna put a pin in that and come back to it in a minute. But like with the startups that are saying, oh, we’re gonna build an AI SRE, a general purpose AI SRE,

I have not heard good things from people turning this on against their production systems. I have heard usually really bad things. And again, I don’t want to name names, but I also want to say that I’ve talked to half dozen dozen people about this and they’ve tried them all. Like.

This isn’t a, there’s a good one and then there’s some bad ones. It’s like all of them generally suck.

in general right now there are specific cases where it does work um obviously the ways that they demo work very well but i think even even in though even the people that i would say are more charitable are like it works for things that are very constrained right like if you if you really set up a lot of guardrails and you say like okay you are going to go do this one thing or this or i’m going to give you i’m like hey ai agent i’m going to give you like a run book

and your job is to do the run book. That stuff works Now, I think there’s a real question of like.

Does that how much of an agent is like how much AI is this right? This is this just this seems very deterministic and it’s like yeah, like you have some maybe you have an AI orchestrator that’s Pattern matching to like and when XYZ things happen, we’ve seen this before we need to like go through this run book You know, and that’s a very deterministic thing and I think there’s that there is definitely value there right especially at large large organizations and that’s when I talk to people that like

pretty large, older, more traditional enterprise who already think this way, who that is their incident response for them is like, we go, a failure happens, we check the run books, we check the knowledge base, and we see like, yes, this is an instance of this. And then when that happens, like, okay, step one.

Do this, step two, right? there, that’s a flow chart and that, that stuff. Yes. Like you can make an AI agent that will do that flow chart for you and, replace, you know,

some lower tier sort of IT roles. But that’s a far cry from like, we don’t need an SRE anymore. And so what I think, so back to the first point, which is like, what do the vendors do? I actually am, I’m still trying to figure that one out. I think there’s a…

I think there’s a lot of people that are going to try to figure out stuff. think there’s certainly, you know, I think the most interesting question obviously is like, if we assume, you know, I think, and I think this is the case, like

if you assume that the near-term future, the two to five year time frame is develop, you know, the impact of Gen AI mostly will be around software developers and software development. The impact of Gen AI will be that more people are building and running code. The impact of Gen AI is that we now have, you know, even more complexity out there.

I think the question for vendors is like, okay, how do you make your platform? How do you make your observability platform a better partner, a better way, you know, how do you plug into these, gen AI workflows? Like how do you, you know, what is the interface you give to an LLM? What’s the interface you give to an AI agent? Do you provide sort of your own AI agents that are good at using your tools to use your platform?

what does the integration point look like, right? Like.

These are questions that I don’t think we have answers to. We don’t have like hard and fast answers to, but I think they’re important questions. And that’s kind of where my where I’m trying to lead. You know, that’s where I’m telling people right now. Right. think of the AI is like a weird idiosyncratic, you know, user that you need to write user stories for and start and build along those lines.

Kate Holterhoff (18:32)
you mentioned that fast feedback is the only feedback. And I like that idea because it’s so concrete. But what I have become interested in recently is this new normal of waiting for good feedback.

Austin Parker (18:35)
Yeah.

Kate Holterhoff (18:47)
And so I’m thinking of companies like CodeRabbit, who actually talk about the length of time that it takes to get you back your answer as being a feature, not a bug, and that it shows that it’s working. And I’ve seen this in my own life. When I’m using Claude, and I use the better model to do some work, I’m suspicious if it goes too quickly. I’m like, no, no, you haven’t been thinking long enough. And that’s actually an option, right? Think longer. And so length of time.

actually seems to be suggesting quality in ways that it hasn’t in the past with other SaaS products, right? So, like, we’re in this new normal of waiting. And I’m wondering how that applies to the observability world, because I agree that speed is always good, velocity is always a positive, we all want things to happen quickly. And obviously, if I was waiting way too long—

for response from Claude, would be annoyed, right? But there’s a sweet spot here. And so I’m wondering how you’re approaching that. Like, where is, and I think that goes beyond the you know, the trade off of like speed versus correctness, right? You know, I mean, there’s all kinds of little platitudes about that,

Austin Parker (19:41)
Yeah.

Yeah, I mean,

in the context of like a Gen AI thing, like

The is interesting, the speed is interesting there because you’re really talking about two different things.

Let’s take your code wrapping example. There’s time to first token and then there’s time to, you know, actually getting a response. And I think that every anyone would tell you that, actually you want like the time to first token to be very low. Like you want the, you want to be able to give people the user very fast feedback that yes, I, have received what you are telling me and I am going to start working on it.

Kate Holterhoff (20:36)
Mm-hmm.

Austin Parker (20:37)
And if you didn’t get that, if you just like type something in, if you just hit @coderabbit or whatever in your get issue and then it took five minutes before you got any indication that something was happening, you would be like this sucks. so like,

Kate Holterhoff (20:51)
Very true, yes.

Austin Parker (20:55)
the immediate answer, the no thinking answer often is going to be, you know, could be less correct. I actually, I mean, I do want to also point out, like, often, you know, just like in humans, the

The thinking response is sometimes not the right response. Like you give the LLM too much time and it’ll get it in its own head and it’ll like doubt itself and you’ll give it, you’ll give it anxiety. But that aside, like, yeah, obviously a model, you give the model more time, you give it more tokens, you give it more budget for it to think about things and for it to reason and for it to go through, you know, all these different, you know, very fancy vector maths.

And you will get a different answer versus the snap one. But in the context of a kind of a observability platform or a query platform, then you really do want to be able to optimize for speed of, you want to be able to make trade-offs, should say, around speed and efficiency. I think the best example of this is something OpenAI is doing right now with parallel tool calls. So in GPT-5,

know, GPT-5 is trained to be able to say like, okay, I can just go off and like do five different things at once. I can make five different tool calls and then get off and stream all those responses back. And so if you’re, if you tell GPT-5 like, oh, okay, hey, please go like, hey, I have an incident or hey, please go investigate this thing or help me figure this out. It can say, oh, okay, well, I’m going to come up with like five different theories right now and go do queries.

in parallel to investigate those and then drop the ones that don’t make sense. And if those queries take three seconds, great. If they take 30 seconds, hmm. If they take three minutes, ooh. Right? So there’s, because every moment that the LLM is there, every minute or second that the LLM is waiting for that tool call response, that’s a minute that it’s not doing something else. And I think you do start to get into really interesting sort of,

like tokenomics and stuff if you have very long queries, right? Because keep in mind, caching for most tokens, you always want to be hitting the cache for tokens, because otherwise it’s mundo expensive. But the cache is like five minutes, 15 minutes. If it’s five, then if your queries take five minutes, or if you have to go and do like super queries that take like five, 10,

15 minutes or whatever, then all those tokens have expired in the cache. And now you’re having to like constantly be hitting it with like more expense. You’re sending all this stuff back in and it’s more expensive and like that’s a, you know, that’s a like over here sort of thing. That’s probably not something people are optimizing around. But I do think it’s a it’s really relevant for how we think about inputs into these sort of agentic workflows. Like

The model should have more time. We should give the models more time to think and do stuff, but we want the inputs. want when the model goes and tries to like get something, it should be quick. For the same reasons, it’s good that it’s quick for us, right? Like if you or I want, you know, to find an answer for something, then we want that. We want a quick response, right? We want our Google searches or whatever to be fast. We want our Amazon searches to be quick.

makes us happy. And if you are a non mechanistic LLM person, then you probably want to optimize for the happiness of the model. Because a happy model probably performs better. If such a thing can be said to exist. I don’t know.

Kate Holterhoff (24:41)
Yeah. Everything you say makes sense. And I appreciate you segmenting the time to token versus just responding to the user. And so that seems like some Nielsen-Norman user experience best practices, which we are rewriting in the age of AI. And I don’t know that I’ve seen a good post on that yet. So maybe that’s something you can handle, Austin. You got that one, right? You’re going to write that out?

Austin Parker (24:51)
With yeah with with again

my copious free time

Kate Holterhoff (25:07)
Exactly. All right. So that’s in your capable hands here. Okay. So I want to talk about another larger problem, and that’s about abstractions. And yes. So you dig into it, though. You did the thing. So like, you know, you you’re asking for this basically. But and I don’t want to get too hand wavy with this question, because I think, at the end of the day, we end up in the same sort of issue of like, what’s the right balance for abstractions? Right. But maybe

Austin Parker (25:15)
Hmm.

Kate Holterhoff (25:33)
things are changing, right? We keep talking about how things are subtly shifting, dramatically shifting, right? So yeah, let’s talk about the paradox. So you note that new abstractions make software more accessible by hiding complexity, but then require new observability tools to understand that hidden complexity. And so I’m curious, is this just an infinite recursion situation in these abstraction layers? And where would you say it ends? Like, what’s the sweet spot?

Austin Parker (26:00)
gosh. I wish I could tell you. I do think that some of it’s cyclical. I think there’s a…

Kate Holterhoff (26:05)
Okay.

Austin Parker (26:09)
I posted on Bluesky over the weekend about I saw a post that was like small date. It was called small data. And I went and read it because it confirmed my priors. But but also because I was like, I was curious. It’s like, you hear about big data, big data, big data. It’s like, here’s someone talk about small data. Cool. And what it brought up, I think, was very interesting is that like

Kate Holterhoff (26:31)
Right.

Austin Parker (26:38)
When we talk about hardware, a lot of times now, feel like especially in sort of the B2B SaaS world, we wind up talking about hardware. We talk about hardware through the proxy of like, what is AWS charges or what is Azure charges or what is GCP, right? Or we’re talking about like hardware. We’re talking about hardware. We’re talking about not.

The actual cost of hardware sometimes we’re talking about the cost of renting hardware. And we’re not even talking about actually renting the hardware, we’re talking about renting like time divided slices of capacity on these globally redundant. We’re talking, know, the cost that we pay per byte of data stored or sent or whatever is fantastically disconnected from like all of the underlying things that have to happen for that byte to go somewhere.

Kate Holterhoff (27:10)
Mm-hmm.

Austin Parker (27:35)
But if you look at it from a practical perspective, like what is the actual dollars and cents cost of hardware these days? And what is the actual dollars and cents cost of storage especially? Over the past 10 years, compute has gotten ridiculously cheaper and more efficient. A lot of this is thanks to like Arm64 and, thanks Tim Apple for making Arm viable.

only halfway kidding, but like the prices for NVMe storage have gone super down, right? Like we can, you can get fantastic amounts of storage on a chip at a fraction of the costs that you could have, you know, 10 years ago, right? Like memory has gotten cheaper. Everything has gotten cheaper, smaller, more efficient.

Kate Holterhoff (28:02)
You

Austin Parker (28:24)
And if you think about it in those terms, like what is the absolute cost of something to store bits and bytes on and move them around and do computing, that has all gotten ridiculously cheap. And so we’ve also started to see kind of software like. You know, one one layer up, I guess, if we take hardware as this big journal of abstraction layer and say like, OK, well, you know, software runs another hardware. We see.

databases like OLAP style databases, things like ClickHouse or like DuckDB or whatever that are capable of doing just like quite frankly ridiculous throughput on like low grade, know, on fairly small amounts of hardware. Like I think a not terribly highly specced box can do

and a single instance of ClickHouse can do something like a million inserts per second. Which is a lot. Like.

I would say for 90, like, I don’t, I hate making like broad statements like this, because I feel like I’m always so off. But if you think about, know, of all software on the planet, like how many people are really doing more than a million writes per second to a data store? There are a few, and certainly there are applications that are, but if you average it out and that’s, which is a shitty way to think about this, but still like,

So much of our software is really overbuilt. we’re because the way we think about hardware, the way we think about the capabilities of this is through maybe the incorrect abstraction layer. We’re thinking about it not as the actual underlying capabilities of the hardware that we can use, but we’re thinking about it as what is the value, what is this like hardware to rented time abstraction that we actually pay

And that’s what we actually think about because buying a server and racking a server is like CapEx and we can’t do that. Nobody’s giving us nobody’s giving you know, and I think that’s in some ways that’s the system is incentivized for that, right? Like nobody’s out there giving you credits on racking a server, right? Dell’s not out there saying like, yeah, hey, you’re a startup. Cool. Here’s a new Optiplex or whatever.

or you know, there’s no like free amperes for

Garages. They go. Someone go call Oxide. Here’s a brilliant marketing strategy for them. But like you see my point, right? Like because we think about this way, because the economic value, like the incentives all align to like, yes, we would like we refer you to think about these abstractions in terms of like, what does it cost you to rent these abstractions? And especially now with like the new new wave of stuff where

Kate Holterhoff (30:51)
Ha!

Austin Parker (31:13)
your pay, know, your Vercels, your Lovable, your v0 whatever, right? Replits where, no, we’re actually talking like all of this stuff is like completely abstract. I mean, you don’t have to care about any of this stuff. You just have a prompt and you’re typing into the prompt and it’s building and running an app for you. And it’s all just magic and it happens and dah, dah, dah, dah. Like, and that in and of itself is.

abstraction over an abstraction over an abstraction over an abstraction over an abstraction over and so on and so on and so forth. Like we’re so, you know, a lot of people, especially the new, the next generation of builders, I think are so disconnected from the underlying stuff. And so I think we’re going to kind of see this counter cyclical effect, right? Like where people will choose to say like,

Like, from a business perspective, will make it honestly makes a lot of sense to just be like, do I need IAS? Do I need, you know, all these SaaS things? Like, if I’m if I’m really sitting down doing the dollars and cents, like, doesn’t it make more sense to just go buy a server and rack it and

What am I really losing? Like how, is that extra nine worth is a good way to think about it. because the other way that you can kind of construe this is well, I do all, you know, I, I’m on AWS or I’m on, I mean, the cloud, I’m using these abstractions so I can get more nines so I can have more uptime.

I’m going from like two nines to three nines. But how much does that extra, you know, what is the actual value of that extra nine? And I think that’s a, that’s, that to me is an open question for most people. And so that’s, that’s what got me thinking about the, or back to the point, or I guess that was part of the point, but the small data post was basically this, right? Like hardware, like storage is so cheap, compute is so cheap, everything, all this stuff is so cheap.

Kate Holterhoff (32:41)
Okay.

Right, right.

Austin Parker (33:09)
and we overbuild because of the way, because of this, because the way that we can think about all this stuff is through SaaS, through PaaS through IAS, da da da da. Like nothing says it has to be that way. And I think now, especially like.

What is some of the stuff that’s like, what makes it hard to do like that? What makes it, why, one of the reasons that you pay for someone to manage this for you is because like, Linux admin is actually kind of challenging. But wait, I now have a, I can go pay 200 bucks a month to OpenAI and I have a bot that has memorized every man page ever.

Kate Holterhoff (33:40)
Yeah.

Okay, well, I mean, it sounds like we’re just grappling with the same questions we always have in new ways, which is pretty much what I sort of anticipated you saying. I don’t know. It’s the problems stay the same.

Austin Parker (33:56)
It is. Yeah.

I do think that it,

I think that there is gonna be something to be said about like.

A historical analog I’m reaching for right now is if you think about WordPress and how many WordPress sites there are and how many WordPress providers. And I think that there is a somewhat useful analog there for sort of the sat, the observability, the whatever, right? Cause for a lot of people, WordPress was like WordPress wasn’t just, you know, a CMS. It’s like this is their app. This is

their business software. is the thing that matters. And the great thing about WordPress in lot of ways is it gave people the ability to go and like build these nice web apps and build this presence for themselves that didn’t require, you know, whatever, didn’t require all this other crap. And it gave opportunities for other businesses to come in and say like, we can provide value added services, right? Like we can, you know, I’ve

Like there’s a bunch, think, to the observability point, like you can still to this day go and spin up a WordPress site and there will usually be, depending on your platform, there’s probably like a partner integration where it’s like you click this thing and you get, your observability is taken care of for you, it’s over here, right? Like I can see stuff like that happening for AI apps for like…

AI is an abstraction where AI just kind of becomes like this general purpose like WordPress shaped blob for a lot of people.

I definitely think that companies like OpenAI are thinking about it that way. If you look at what they’ve been trying to do with Codex and aligning all of these development assistance products and putting them together, you can very easily see a world where OpenAI is just like, okay, well, what if we just let people run persistent apps? We’re running a platform, why not? And that’s an interesting…

road to walk down mentally.

Kate Holterhoff (36:07)
Yeah. And I appreciate you bringing up a WordPress reference for my sake, you know, the front-end engineer. I need these these front-end CMS references. You know, they resonate with me in particular. Yeah.

Austin Parker (36:18)
It’s all software. It’s all software.

My most controversial take is there’s…

Very… there’s almost nothing… there’s very little different… I would… I think the current sort of moral panic around AI and software development is very similar to prior moral panics in the front-end space around literally everything that happens that makes front-end easier. I’m old enough to remember when Dreamweaver was the death of the web, right?

Kate Holterhoff (36:54)
my God, yeah, yeah, yeah, yeah.

Austin Parker (36:55)
Like

Kate Holterhoff (36:56)
Okay.

Austin Parker (36:57)
Yeah, I don’t know. whatever. People are gonna, if you want to be mad at me, people can be mad at me. Like, I think it is, you know, every I’m old enough to remember when object oriented programming was the death of software development. And how, you know, I’m old enough to remember when IntelliSense was dumbing us all down and making us into terrible devs. Like, these are just tools. And one of the things that I’ve seen come up bit recently is like, oh, well, the tools are like, they’re poison or they’re they’re

Kate Holterhoff (37:16)
Yeah.

Austin Parker (37:26)
We they’re bad. It’s like.

then or it’s like, we shouldn’t let people use these because of whatever reason, because it like hurts them or something. I mean, I don’t know. Do better. Like literally tools are.

Kate Holterhoff (37:33)
Yeah.

Austin Parker (37:38)
There is a not… There is not necessarily a moral valence around tools or technology. There is certainly one around how it is used and how it is applied. And I think that it’s high time for people that care about that shit to just do a better job than the assholes. Like if you would like to… Like it… Like just do stuff. Do better stuff. Like you control the buttons you push. And if you…

and sitting on the sidelines screaming about like, this is immoral or this is making us all stupid or like, this is evil Like it’s 2025, like I think we have a pretty good fucking idea of what’s good and evil in the world and I think we can

get off our butts and we can do stuff. We can find good applications for those things. We can find things that uphold our own values and uplift the people that we want and make technology and the internet and all of the infinite untapped potential of human connection accessible and important and all this good stuff. It’s not impossible, but we have to do it.

We have to work and it’s. That’s what I would love for people to do more of do the work.

Kate Holterhoff (38:57)
Do the work. I like it. Okay, so we are almost out of time, but I do want to close out by talking about OpenTelemetry and their role in all of this. So you mentioned OpenTelemetry in the context of documentation, and I suspect they’re doing a lot there. So would you mind just giving us kind of a rundown of where OTel is in terms of the larger MCP, AI and observability space? Like, what is OTel’s position? What are you folks doing?

Austin Parker (39:11)
Mm-hmm.

Yeah.

Well, we’re obviously, you know, been very excited to see the growth of Gen AI alongside OpenTelemetry because this is sort of the first big technological thing that sort of happened at Post-Otel, right? Like, and so it’s the first thing that’s growing up alongside of it. And so I think from a practical perspective, what you see is, all these client libraries

and agent frameworks and whatever else, all these things are being built with OTel natively integrated into them, which is great. So they all have tracing, they all have built-in context, they all have metrics, and they’re doing stuff the right way, which is great. And we’re trying to support that through in a couple of ways. One is we’re supporting, development of semantic conventions, so standard attributes and metadata for Gen AI. We’re making some changes to the spec.

to allow for things to aid in the instrumentation of AI apps, things like complex attributes. One of the things that I’m really interested in is one is you just kind of mentioned MCP and docs like Something I’m personally so when’s this come out anyway?

Kate Holterhoff (40:40)
Whenever we want.

Austin Parker (40:42)
Okay, I’m running for re-election to the OpenTelemetry Governance Committee. I just sent in my nomination. So if anyone’s listening to this, I’m gonna give you a campaign speech. But one of things I’m running for re-election to the OTel Governance Committee, and one thing I’m really interested in is if I’m re-elected, is I want to… kind of obliquely refer to the…

Kate Holterhoff (40:45)
Ooh.

Good luck.

yeah, go for it.

Austin Parker (41:09)
this next generation of developers, people that are building with AI and building on top of these like new abstraction layers. And I think OTel has to be for those people, right? And so I want to work on building a better sort of local development experience for OTel. want to work on how to integrate Gen AI into OTel more or like connection points for

OTel and Gen AI, so a good example would be maybe a default MCP server for the collector, something like that, Better documentation for AI. And

There’s a couple of different challenges around all of this, right? But one thing that is, I think, really important is that we don’t lose sight of the fact that saying for AIs makes it sound like we’re just pushing it all off to the AI. But it’s really, it’s about the human and the AI working together to sort of solve these problems. So some of this does mean, when we talk about building OTel for AI, it’s like, we’re actually talking about how do we

How do we allow developers to sort of express their intent around instrumentation, around what they care about observing, and then let the AI get better at translating that into instrumentation? And then how do we encourage the AI to do that in good ways? So rather than just hard coding instruments from fields, how do we get the AI to build telemetry schemas and use code gen and use repeatable things?

rather than kind of one-offs. know, and so that’s something I’m interested in working on, if I’m re-elected. I want to kind of lead some efforts around that.

Kate Holterhoff (42:55)
All right, inspiring and sounds very practical to me. especially in relation to our conversation about how it is that the role of the SRE is going to be shifting here in the next few years. I mean, this is big. The job descriptions are already changing, and I suspect that’s not going to slow down anytime soon. Yeah.

Austin Parker (43:06)
Mmm

No, no,

I mean, think everything everything always changes. I think we’re going to, you know, I do tend to think that we are. You know, there’s going to be a pullback, right? Like there’s. Independent of anything that feels very obvious that there is some there is a bubble around Gen AI. To me, at least, and.

At some point, all bubbles do deflate. And we’ll see what happens there. But I think that again, like I said at the beginning, like you could stop, you could take the model capabilities as they exist today and just do nothing but refine them. And you still have almost a decade, I think, of like productivity improvements and better tooling and all this stuff, right? Like the capabilities are immense of what we have today.

if we can just use it properly, right? Get the right UX, get the right integrations, figure out the right level of abstraction for LLMs. And that’s what’s exciting to me, right? Not like all the other stuff that people talk about with Gen AI.

Kate Holterhoff (44:23)
Yeah, okay. Fantastic. You know, I like to end on an optimistic note, so that’s really great. How can folks keep up with your musings on this? I mean, you mentioned your Bluesky account. You’ve got a blog. Like, where are you expressing yourself these days?

Austin Parker (44:36)
Yeah, I’m aparker at aparker.io on blue sky, aparker.io on the web, aparker.io or aparker.io pretty much everywhere until until whatever happens with that i-o domain happens and then I have to go somewhere else.

Kate Holterhoff (45:00)
Don’t get too far ahead, yeah.

Austin Parker (45:01)
Yeah, yeah, no, one problem at a time. You can also find me around the world. I will be at, if you’re going to KubeCon in Atlanta this fall, I’ll be speaking there. I hope to see ya. Yep, and I will be running some cool OpenTelemetry events there as well, so look me up. yeah, and also I’m just, I’m around. I go places, I do things.

Kate Holterhoff (45:04)
One problem at a time. like it.

You’ll be seeing me for sure.

I can confirm that. You pop up many of the places I am. This is it. It’s Austin. All right. Phenomenal. Okay. Well, really enjoyed speaking with you today, Austin. Again, my name is Kate Holterhoff, Senior Analyst at RedMonk. If you enjoyed this conversation, please like, subscribe, and review the MonkCast on your podcast platform of choice. If you’re watching us on RedMonk’s YouTube channel, please like, subscribe, and engage with us in the comments.

Austin Parker (45:29)
I pop up at a lot of places.