Tradeoffs on the road to Observability
summary
Concrete claims and measurable outcomes steer the choice: a 33‑person company Honeycomb.io reports they deploy up to 10 times per day, keep change failure rates to fail less than one in a thousand, roll back in ~10 minutes and fix forward in ~20, and prefer SaaS plus small pragmatic tools like use thread-loader rather than building bespoke platforms. Look for actual numbers, the maintenance burden described, what was reused versus forked, and whether the built solution reduced ops time and scaled in practice.
AI-written summary · about
chapters (18)
- 0:00Intro
- 1:18The wrong incentives.
- 2:56Appropriate reliability & scalability.
- 3:37Scalability of humans & machines
- 4:20Appropriate observability.
- 5:33Observability isn't just the data.
- 8:17What was the problem?
- 13:10What options did you consider?
- 14:25New code is tech debt.
- 14:59Running software is tech debt.
- 15:25Building the wrong thing is ruinous.
- 16:12Collaborate within your organization
- 16:40Look for similar problems.
- 17:07Document & provide examples.
- 20:26Upstream code & specs.
- 21:17Document technical decisions.
- 23:54A dozen engineers build Honeycomb.
- 24:05We make systems humane to run
related talks
50mObservability and the Development Process
31mNo-Nonsense Observability Improvement
27mOpening the Door to Observability
50mDevOps: Top Lessons Learned on Shifting Left For Accessibility and Other Experts
31mObservability for Developers: How to Get There
31mObservability driven development
47mHow to win in software development with tighter feedback loops
01h 21mTradeoffs in the Software Workflow