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!

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.

This is so cool! I’ve had this exact problem before.

Every day I have more sympathy for the Mars Climate Orbiter team. https://science.nasa.gov/mission/mars-climate-orbiter/

I will just say that I published a follow up article that proposes some solutions.

https://thenewstack.io/how-to-shift-testing-left-4-tactical-...

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 :)

^^ this right here, I want to quote this in my next blog post :)

Every shop that's running a dozen microservices on a Kubernetes cluster, is running something that can't be run on your computer.

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'

This has been on my mind seeing all the regulatory debate around AI/LLMs. CEO's calling for regulation when they nakedly wish to prevent new players from entering the market. The most naked I saw was the call for a 'six month moratorium' that was obviously a request to pause development so that latecomers could catch up: https://www.wired.com/story/fast-forward-elon-musk-letter-pa....

Without vendor lock-in, OpenTelemetry observability companies can never gouge you as badly as Datadog does.

Super cool to find a new way to monitor git performance with OTel, would be interesting to see if you can fill out all the DORA metrics with an OpenTelemetry dashboard.

I'll be interested to see more applications of OpenTelemetry baggage like this.

I wish I'd included it in the piece, I'll maybe write a follow up: right now I don't think it makes sense to implement queueing just for your observability data. But if the queue is already there, it's worth considering handling OTLP data with a Kafka queue.

I like this overview. I think that Prometheus especially still needs to be supported, because some great tools rely on it. However you can ingest prometheus metrics with an OpenTelemetry collector.

Pretty neat! I assume it's just measuring traces right now? Any plans to add some top level metrics like build times, prompt length, etc?

Thanks for linking, I should have added it in my initial comment.

I think The Verge's angle is pretty good: it's going to be hard to restore trust, and many developers were surprised at how easy a shift of frameworks is looking for future releases. I'm following a number of indie game devs who got their next release ported away from Unity within a week, including Brian Bucklew of the classic Caves of Qud team

Looks neat! CTA's 'submit' button doesn't work. Raising a typeerror