OpenObservability Talks

There are some genuinely useful technical insights buried here - like the leader extension solving the cluster receiver single-replica problem and the centralization-without-extensibility antipattern - but they're surrounded by long organizational platitudes, repetitive framing, and mutual back-patting that dilutes the per-minute yield considerably.

“with the leader extension what you can have now is a, um, just deploy a daemon set and then each but one replica in that demon set will be the one monitoring the cluster. If that dies, then another one picks up”

“centralization alone can uh, be really bad. As in like if you just give people uh, uh, a way to deploy OpenTelemetry but you don't allow them to extend it in an easy way, then that's as bad as not having centralization”

Applying Rumelt's Good Strategy/Bad Strategy framework to OTel deployment architecture is a mildly fresh angle, and the daemon-set crowding observation is concrete, but most of the content covers well-trodden platform engineering ground - golden paths, centers of excellence, bottom-up vs top-down adoption - without genuinely counterintuitive or first-principles arguments.

“we chose that framework of um, good strategy, bad strategy... basically you should structure your thinking in three main blocks. One is the challenges that you're trying to solve, the main guidelines to solve those challenges and then the actions to implement those guidelines”

“you end up basically uh, with a node. When the moment of the node spins up, you just have demon says in it and there's no user workloads that can run on that node”

Dan Gomez is a credible practitioner: former OTel governance committee member, SIG End User maintainer, led OTel adoption at Skyscanner, authored 'Practical Open Telemetry', and works as an observability architect at New Relic - he has genuinely done the thing at scale across multiple organisations.

“I was an end user myself not too long ago”

“that made me even happier because it happened after I left the company. Right. But all the. I guess that was part of, you know, it was like my baby in a way”

The episode names real companies (Adobe, Mastodon, Skyscanner) and real contributors (Tiffany from Grafana Labs, Luke from Splunk), and calls out specific technical components like the cluster receiver's single-replica limitation and OTLP GRPC vs HTTP trade-offs. However, there are zero quantified outcomes, no adoption metrics, and most recommendations stay at the architectural-concept level.

“we already have three. I think we're getting a thing. We have Adobe, uh, Mastodon and Skyscanner that have basically published the reference implementations for autel”

“this blueprint calls uh out specifically that the guidance in the blueprint is not aimed at organizations that may have a requirement for you know, uh, 100% completion on every single span”

The host is clearly knowledgeable and frames the topic well, but repeatedly delivers extended monologues that crowd out guest answers, never pushes back on any claim, and the conversation functions more as a structured promotional unveiling than a probing interview.

“So I'm as an external, I brought them to talk to each other and suddenly realizing so. But having the blueprints as like an anchor to, to um, create even the language of conversation within the organization across the different teams”

“And I also see there on the background the uh, Practical Open Telemetry. That's the book that you authored about Autel. So uh, definitely yet another testament of your uh, your credibility”