1/ We all know that observability is "hard and getting harder."
What single aspect of a system best predicts broken observability workflows? It’s not just *scale*, it’s *depth*.
And that’s why we need to talk more about deep systems. (Thread)
lightstep.com/blog/how-deep-…
What single aspect of a system best predicts broken observability workflows? It’s not just *scale*, it’s *depth*.
And that’s why we need to talk more about deep systems. (Thread)
lightstep.com/blog/how-deep-…
2/ Why are deep systems so problematic?
It’s because what we control in production is so much smaller than what we’re responsible for.
To illustrate the fearsome scope of responsibility with real-world data, here are some anonymized @LightStepHQ customer system diagrams:
It’s because what we control in production is so much smaller than what we’re responsible for.
To illustrate the fearsome scope of responsibility with real-world data, here are some anonymized @LightStepHQ customer system diagrams:
3/ The textbook definition of stress is “responsibility without control,” and system depth helps us understand why things have become so stressful:
4/ If “observability” (sic) revolves around siloed metrics and logging products, every human managing nested dependencies in a deep system takes on responsibility for a disorganized firehose of data.
Again: practically the textbook definition of stress!
Again: practically the textbook definition of stress!
5/ Taken individually, distributed traces can solve certain isolated problems.
Taken in the aggregate, though, traces can form the backbone of a new and greatly simplified approach to observability.
Taken in the aggregate, though, traces can form the backbone of a new and greatly simplified approach to observability.
6/ When our traces rank and filter the rest of the telemetry firehose, we can bring "responsibility" and "control" back into relative proportion... and finally enjoy lower-stress, intuitive observability in deep systems.
