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.