Introducing OTel Blueprints and Reference Implementations

Justy Okay, so the new OTel Blueprints thing dropped and I gotta say, I'm kind of relieved someone finally said 'here, just do it this way'.

Cody Relieved? Or just lazy?

Justy Hey, I resent that. But seriously, have you seen how many ways there are to configure a Collector now? It's exhausting.

Cody Right. But that's the point though. The blog post by Dan Gomez Blanco makes this distinction between essential and accidental complexity that I think people are glossing over.

Justy Wait, like the Fred Brooks reference?

Cody Exactly. Essential complexity is just the reality that OTel touches everything—browser, mobile, kubernetes, databases. You can't simplify that away.

Justy Sure.

Cody But the accidental stuff? That's us. That's teams spinning up their own pipelines without talking to each other. And I'm skeptical a PDF blueprint fixes an org chart problem.

Justy I mean, maybe not the org chart, but Cody, think about the team that just wants to instrument their service without becoming a distributed systems PhD.

Cody Hm.

Justy If there's a reference implementation that says 'drop this config in, get traces out,' that's huge for adoption. It lowers the barrier to entry significantly.

Cody It does. But here's where I get nervous. The article talks about 'prescriptive, opinionated ways' of deploying. History tells us people treat opinions as suggestions.

Justy True.

Cody We've seen this with the Operator before. Great tool, but everyone tweaks it until it's unrecognizable. What makes Blueprints different?

Justy Because it's coming from the End User SIG and Developer Experience SIG together? It feels more grounded in actual pain points rather than theoretical perfection.

Cody Maybe. I just worry we're trading one kind of complexity for another. Now instead of configuring pipes, we're configuring which blueprint to ignore.

Justy That is such a Cody take. 'The solution to our problems is probably just another thing to break.'

Cody I'm not wrong though! Look at the semantic conventions part. If two teams grab different blueprints that don't align on attribute naming, you're back to square one.

Justy Okay, fair. But isn't having a starting point better than the wild west? At least now there's a canonical 'happy path' to point people at.

Cody I suppose. It definitely cuts down the 'how do I even start' paralysis. The reference implementations could save someone three days of YAML hell.

Justy Three days? Try three weeks. Remember when we tried to get context propagation working across those legacy services?

Cody Oh god. Don't remind me. That took HOURS just to figure out which sampler was dropping the spans.

Justy See? A blueprint that says 'use this sampler config for this scenario' would have saved us so much grief.

Cody Alright, alright. I'll concede that for greenfield projects or teams new to observability, this is a net positive.

Justy Thank you.

Cody But for the mature messes? The ones with five years of half-baked instrumentation? I don't think a blueprint magically untangles that knot.

Justy No, but it gives them a target state to migrate toward. You can't fix everything at once, but you can say 'okay, next service we onboard uses Blueprint v1'.

Cody Gradual migration. Yeah, I can get behind that. As long as we don't pretend it's a silver bullet.

Justy Deal. No silver bullets. Just slightly less sharp tools.

Cody I'll take it.

Justy So, verdict? Blueprints are good, but they won't fix your team's communication issues.

Cody Precisely. They reduce accidental complexity only if you actually follow them. Which requires... wait for it... organizational discipline.

Justy Wow, revolutionary. Anyway, I'm going to go poke at the reference implementations on the OTel GitHub and see how opinionated they really are.

Cody Let me know if you find one that doesn't require reading a hundred pages of docs first.

Justy If I do, I'll send you a link. Chat soon.