serverlessmom

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.

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...

lol that was me, finally upgraded! love the service!

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.

Slightly longer: having many versions of the same SDK required added to startup time.

It’s a 50% reduction in startup time, and each “run” for a pod is fairly quick.

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.

oooooh I love this, I was writing against mocks a few months ago, and love to see others talking about more sophisticated testing methods: https://www.signadot.com/blog/why-developers-shouldnt-write-...

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.

Notably the OTel docs acknowledge this mismatch between current implementation and design goals: https://opentelemetry.io/docs/specs/otel/logs/#limitations-o...

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...

Yes I work at Checkly, though I didn’t answer authoritatively since this one wasn’t written by me!