Reliability & operations · Book notes
Release It! read against operational resilience rules and AI
Michael Nygard's stability patterns, production-first thinking and cynical software hold up when read against operational resilience regulation and new AI dependencies.
Since January 2025, banks and insurers in the EU must demonstrate operational resilience under the Digital Operational Resilience Act. The rules require resilience testing and maintaining a register of all ICT third-party dependencies, each with an exit plan.
Michael Nygard was arguing for this kind of thinking long before any regulator. The publisher’s pitch for the 2nd edition of Release It! (2018) was that 80% of a project’s lifecycle cost is in production, and not many books talk about that. He’s also the person who proposed architecture decision records.
Through the lens of a decade working with large financial institutions and Fortune 500 companies, now as a principal cloud architect, I’ll test three ideas from the book against 2026. This will show you where your enterprise should put its next effort into resilience, and what each choice delivers in a live production system.
Life after release
The second edition adds chaos engineering and cloud-native operations to a book already about post-release software. The DORA testing requirement is the same idea, but an obligation the supervisor can verify. Is the evidence the bank gives the supervisor about the same as the resilience of the system they’re actually running?
The missing bulkhead
Timeouts, circuit breakers, and bulkheads are named for service-to-service calls. The idea is that one slow or failing dependency shouldn’t be able to exhaust the threads of all callers. So you put a time limit on each call, and keep a separate pool for each group of callers.
In July 2024, a single faulty security update brought down about 8.5 million Windows machines, grinding airlines and banks to a halt. Breakers between your company’s own services wouldn’t have helped here.. the missing bulkhead was at the vendor level, where one update rolled out to every machine.
To me, this outage was as much a cynical-software failure as it was a failure of testing. A component blindly trusted an update, every machine applied it at the same time, and nothing stood between a single bad file and an entire fleet of machines.
Cynical software meets a model API
The best line from that book hasn’t aged a bit: “Cynical software expects bad things to happen and is never surprised when they do.” Nygard says integration points are the number-one killer of systems, and APIs for models are the newest integration points for most enterprises. Later in 2024, the Financial Stability Board put third-party dependencies and concentration of AI model providers at the top of the list of AI-related financial stability risks.
To me, a model API is just another integration point. It needs a timeout and a circuit breaker with a fallback, or an explicit sign-off that it’s allowed to run without one. Pretending it won’t fail like your database or a partner’s API does is exactly the kind of trusting attitude this book argues against.
You could produce more compliance artifacts (DORA mandates them anyway, so that keeps the supervisor happy), but an entry in a register won’t stop a slow call from exhausting your threads. You could integrate with a second provider, spreading the concentration risk the FSB describes, but now you’re building and testing two integrations instead of one.
Timeouts and breakers on every outbound call are changes you can make in your own code, without negotiating a contract first. You can build fallback options into your model calls, whether that’s a second provider via configuration or a degraded answer. But if you run without either, you need someone accountable to sign for it.