Here's an exception to these general rules (first names appearing in surnames) is Peterman: you'd think it was some kind of relation to a relative named peter, but it is actually a name for a profession. A Peterman was someone tasked with finding deposits of saltpeter for the production of fertlizer and gunpower.
Yeah. My dad had told me more than one horror story of early tech startups buying truckloads of hardware to scale way beyond demand growth. And I remember when getting on Slashdot meant your service would inevitably go down.
Of course, given stable demand and known requirements, bare metal can be a great option. But it’s not strictly better than public cloud hosting.
I think it’s just been long enough that people have forgotten the limitations of bare metal engineering.
It's surprising how much asset re-use doesn't happen due to small technical hurdles e.g. file incompatibility. Interestingly: for an experienced artist, having a whole library of assets to base your new assets on saves a ton of time, and is almost as fast as asset re-use.
Something I mention any time I'm introducing OpenTelemetry is that it's an unfinished project, a huge piece being the unifying abstractions between those signals.
In part this is a very practical decision: most people already have pretty good tools for their logs, and have struggled to get tracing working. So it's better to work on tools for measuring and sending traces, and just let people export their current log stream via the OpenTelemetry collector.
I think that it's disingenuous to say OpenTelemetry and Sentry aren't in competition. I think it would be good news for Sentry if DT were split from the project, and instrumentation and performance monitoring weren't commoditized by broad adoption of those parts of the OpenTelemetry project.
I think you, the author, stand to benefit directly from a breakup of OpenTelemetry, and a refusal to acknowledge your own bias is problematic when your piece starts with a request to 'look objectively.'
I think that a number of Observability providers are looking at how they can add features and value to parts of monitoring that OTel effectively commoditizes. Thinking of the tail-based sampling implemented at Honeycomb for APM, or synthetic monitoring by my own team at Checkly.
"In 2015 Armin and I built a spec for Distributed Tracing. Its not a hard problem, it just requires an immense amount of coordination and effort." This to me feels like a nice glass of orange juice after brushing my teeth. The spec on DT is very easy, but the implementation is very very hard. The fact that OTel has nurtured a vast array of libraries to aid in context propagation is a huge acheivement, and saying 'This would all work fine if everyone everywhere adopted Sentry' is... laughable.
Totally outside the O11y space, OTel context propagation is an intensely useful feature because of how widespread it is. See Signadot implementing their smart test routing with OpenTelemetry: https://www.signadot.com/blog/scaling-environments-with-open...
An argument that OpenTelemetry is somehow 'too big' is an example of motivated reasoning. I can understand that A Guy Who Makes Money If You Use Sentry dislikes that people are using OTel libraries to solve similar problems.
Context propagation and distributed tracing are cool OTel features! But they are not the only thing OTel should be doing. OpenTelemetry instrumentation libraries can do a lot on their own, a friend of mine made massive savings in compute efficiency with the NodeJS OTel library: https://www.checklyhq.com/blog/coralogix-and-opentelemetry-o...
I think that’s flawed analysis, if you’re running FaaS then sure you can fail to see benefit from small improvements in time (AWS Lambda changed their billing resolution a few years back but before then the Go services didn’t save much money despite being faster) but if you’re running thousands of requests, and speeding them all up, you should be able to realize tangible compute savings whatever your platform.
There really is no one answer, and you're so right that scale is one of the determining factors. Sophisticated tools like Signadot are designed to help dozens of developers use one high-accuracy shared cluster, but that makes no sense if your team is small enough to Slack 'hey I'm going to push my stuff to Staging, no one change anything' for your testing phase :)
I think Honeycomb is perfect for one kind of user, who's entirely concerned with traces and very long retention. For a more general OpenTelemetry-native solution, check out Signoz.
Came here to say the same. It is funny that a term that felt so universal is forgotten today. Probably only memorable now due to the movie 'American Hustle'
A partial documentation is on Wikipedia: https://en.wikipedia.org/wiki/Saltpetre_works
A better narrative of this industry is in Ed Conway's book "Material World" https://edconway.substack.com/p/welcome-to-the-material-worl...