Browse the Knowledge Hub211 resources
Release It!: is it worth reading?
How production systems actually fail, told through incidents, and the patterns that prevent cascading failure.
We earn nothing from any link on this page. No affiliate links anywhere in this library.
- published
- 2018
- key ideas
- 3
- reading path
- 1
Release It!
Design and Deploy Production-Ready Software
by Michael T. Nygard
- Publisher
- Pragmatic Bookshelf
- Year
- 2018
- Edition
- Second edition, substantially expanded for cloud and microservice architectures.
- ISBN
- 9781680502398
Useful when you are: Practising tester, Senior / lead
Verdict
Should you read it?
Read it if
You test or operate anything distributed. It is the best available answer to the question of what to test beyond the functional requirements.
Skip it if
You work on a standalone application with no integration points, which is increasingly rare.
If you only read one thing
The stability antipatterns section. It is effectively a test charter list for anything with an integration point.
The argument
What it argues
Nygard opens with real outages, described in enough detail that you can see exactly how a small fault propagated into a system-wide failure. The pattern is almost always the same: something slow rather than something broken, a resource that is not released, and a failure that spreads through synchronous dependencies.
From those he derives stability patterns, circuit breaker, bulkhead, timeout, fail fast, and the antipatterns that produce the failures in the first place, chiefly unbounded resource pools and integration points without timeouts.
For a tester the relevance is direct: it tells you what to deliberately break. Most of the failure modes it describes are never tested because they are not features and nobody wrote a story for them.
Key ideas
Ideas worth taking from it
- 01
Circuit breaker
Stop calling a failing dependency so the caller is not dragged down with it. Now standard in resilience libraries, and the pattern originates here.
- 02
Integration points are the number one killer
Every call to another system is a failure mode. Slow responses are more dangerous than errors, because a timeout holds a resource while an error releases it.
- 03
Design for failure, not just for correctness
Systems should degrade in predictable ways under stress. Testing should therefore include deliberately inducing those conditions rather than only verifying the happy path.
Criticism
What has dated, and what it gets wrong
The second edition is long and the cloud and microservices material is thinner than the stability patterns that made the first edition essential. Some patterns are now provided by service meshes and platform infrastructure, so the implementation detail is less needed than the thinking behind it.
Reading paths
On our reading paths
Performance and reliability
Book 1 of 4 · Performance testing
Start here. It catalogues the ways production systems fail and the patterns that contain failure, which gives a performance tester a list of things to test for.
- 1. Release It! (this book)
2. Designing Data-Intensive Applications
3. Systems Performance
4. Site Reliability Engineering
Keep reading
What to read next
Reading about quality is cheaper than learning it in production.
QAble runs QA for products in BFSI, gaming, healthcare and SaaS, with engineers who have read these and argued about them. Start with a free QA audit.