Beyond this, I can (re)use client libraries to work with examples, create one-off utility scripts, etc.
Beyond this, I can (re)use client libraries to work with examples, create one-off utility scripts, etc.
Instead of juggling dashboards and collections of requests, or relying on your shell history as Matklad mentions, you have it in a file that you can commit and plug into CI. Win-win.
At some point, that testing shell script can be integrated into your codebase using your working language and build tooling.
`True leaders are hardly known to their followers.`
But. IMO, statistics and probability can’t be replaced with tooling. As software engineering can’t be replaced with no-code services to build applications…
If you need to profile some bug or troubleshoot complex systems (distributed, dbs). You must do your math homework consistently as part of the job.
If you don’t comprehend the distribution of your data, the seasonality, noise vs signal; how can you measure anything valuable? How can you ask the right questions?
> On the other hand, at higher-levels, you want to string together widely different functionality from many separate subsystems without worrying about specific errors...
I feel like the Rust ecosystem of crates has naturally grown to handle these two ideas pretty well. `anyhow` for applications, `thiserror` for libraries.
You clearly haven’t seen our Datadog invoice :)
Jokes aside, I liked the idea of listing things by level of detail.
One related issue I run into all the time is how context gets lost when moving between layers. You start with host metrics, then Kubernetes wraps the host and overrides the tags, and suddenly you can’t filter host metrics by node anymore. Watch out.
If anybody is hesitant give it a try!