Thread by @mipsytipsy

if you can solve your app problem with a monolith, do that
if you can solve your architecture problem with a LAMP stack, do that
if you can debug your problem with printf to stdout, do that

just watch out for the day when the solution reaches its edge & becomes the new problem.

https://twitter.com/zkat__/status/1284749086130712578

so, hey; I know I JUST said this, and I stand by it.

BUT ALSO.

if all you know are logs and print statements, you could probably stand to invest in your own repertoire of observability and telemetry tooling and techniques. it's an easy lift, and the payoff can be enormous.

yes it makes your work better in production, but even just on a personal level, better developer tooling is a force amplifier and an effort maximizer, a time saver and dot connector.

phenomenally productive developers are ones who tend to their personal toolkit. it pays off.

this thread began with someone inquiring if it was really worth her time to learn what traces are all about, or if logs are good enough.

despite all the scoffing down thread -- despite my own tweet! -- I think my answer here is "yes. you should learn what tracing is all about."

It can simultaneously be true that logs are sufficient for this use case, AND it is time to acquire a working knowledge of traces and tracing use cases.

it is time for the median developer to have a working familiarity with tracing. this will be table stakes very soon.

it is not just a microservices vs monoliths thing, although microservices do force the point.

but some of our most avid and adept users of tracing are monoliths. turns out monoliths need traces too!! which has forced us to radically rethink what tracing means to development. 🤔

I guess you could now think of spans as the new log line; only instead of stating a fact, they denote a context switch in work.

whether it's a single web request, or a process executing, or a CI job running... across time they all look like

"do A then do B then do C then do D"

with logs, you get

"A
B
C
D"

...yet most of the interesting stuff exists in the interstitials! network hops, process forks/memory allocators/thread pools, connection attempts, db queries, latency of all sorts sizes, nonreproducible concurrency states, sequencing decisions...

spans also give your ABCD, of course, but they rightly place the *work between the work* front and center.

also, tracing forces you to drag this out of the realm of eyeballing text and into the staggeringly more potent realm of visualization by time.

You may see your process log a query several times (more often you will NOT see it, interspersed between other request spew) --

but you will SEE your trace fork off 40 identical queries. you will SEE it chain 40 sequential blocking queries in a row.

these are categories of problems that I know extremely well as a DBA. because even very good software engineers never catch these issues at the code or logging level.

they ALWAYS get caught by the database folks.

always.

(eventually 🙈)

anyway. are there still use cases where printf to stdout is the right solution?

sure, some. but.. how to put this...I would want to hear the case for it made by someone who had enough facility with both to evaluate the tradeoffs. 🙃