Oct 13, 2026 · 59 min · 12 segments
Sam Newman, author of Building Microservices and the new Building Resilient Distributed Systems, joins Benedikt Stemmildt to talk about resilience engineering now that AI writes more of our software…
Benedikt StemmildtHostThe book I wrote for kind of those two main reasons I wrote the book, and this book is focused on resilience engineering in the context of distributed systems.
So it's taking ideas from the world of resilience engineering, seeing how they apply to distributed systems we build with some very concrete, like, practical, like, what's a timeout? How do you do retries and item potency? So very kind of hands-on, easy things, I think, to, to grasp initially.
But also with very much that resilience engineering spirit, which is all about...
I think when people approach resiliency, they, they initially naively think it's about making sure that nothing goes wrong, and that's something I try and deal with in the first chapter.
It's like that, that can be a good idea, but really your focus should be on making sure as many things go right as possible, right? That's the spirit and the kind of concept behind resilience engineering.
So how do we go about doing that in a, in a distributed system? And but also reinforcing the fact that a distributed system is more than just the computers and the network cables.
... how does organizational dynamics, culture, psychological safety, all these other things impact our ability to build resilient systems? That's kind of what the book's about.
One being that although I spend a lot of my time telling people not to use microservices because they're really-- they can add to lots of sources of complexity and pain and suffering, lots of people are doing it anyway.
And so we've got more people building distributed systems than we did, uh, say ten, fifteen years ago.
And, and so now, you know, and, and so, like, a microservice architecture as an example pushes you to distribute more quickly.
Like, you, you-- There's the natural tendency to go finer grain quite early, whether or not it's a good idea.
And I sort of recognize that as much as I tell people to slow down, they don't listen, and that's fine.
The book I wrote for kind of those two main reasons I wrote the book, and this book is focused on resilience engineering in the context of distributed systems.
So it's taking ideas from the world of resilience engineering, seeing how they apply to distributed systems we build with some very concrete, like, practical, like, what's a timeout? How do you do retries and item potency? So very kind of hands-on, easy things, I think, to, to grasp initially.
But also with very much that resilience engineering spirit, which is all about...
I think when people approach resiliency, they, they initially naively think it's about making sure that nothing goes wrong, and that's something I try and deal with in the first chapter.
It's like that, that can be a good idea, but really your focus should be on making sure as many things go right as possible, right? That's the spirit and the kind of concept behind resilience engineering.
So how do we go about doing that in a, in a distributed system? And but also reinforcing the fact that a distributed system is more than just the computers and the network cables.
... how does organizational dynamics, culture, psychological safety, all these other things impact our ability to build resilient systems? That's kind of what the book's about.
One being that although I spend a lot of my time telling people not to use microservices because they're really-- they can add to lots of sources of complexity and pain and suffering, lots of people are doing it anyway.
And so we've got more people building distributed systems than we did, uh, say ten, fifteen years ago.
And, and so now, you know, and, and so, like, a microservice architecture as an example pushes you to distribute more quickly.
Like, you, you-- There's the natural tendency to go finer grain quite early, whether or not it's a good idea.
And I sort of recognize that as much as I tell people to slow down, they don't listen, and that's fine.
The rest of this transcript — segmented and speaker-labeled, so you land on the exact moment something was said
Search every transcript — by keyword, by phrase, or by meaning, across every show Radar indexes
Trends — what is surging across podcasts, measured against its own baseline
Alerts — when a name you follow appears in a newly indexed episode
No account is needed to search Radar.