Its audience I would say is small organization technical leaders, though it has useful bits and pieces for developers and anyone on a start-up product team, or still slightly behind the curve enterprise sub-team, thinking about scaling up and into more sub-teams.

I picked up a few nuggets and reminded myself of others. However, if you are interested in the people side or organizational side of hypergrowth it's not that useful, if you are interested in the deeper side of SRE or DevOps or resiliency it's not enough, if you want to know how to do practical services or microservices in-depth, it's not enough. For me, it's a bit like a cheapish tour guide. You get an idea of the topics that matter in the space, and broadly correct guidance, with some useful starting tips, but it's not going to give you much more than that or much meaningful novel insights.

Things I picked up that were relevant to me/helpful:

• In general fail as close to the source as possible, use patterns like retries, circuit breakers.
• Establish internal private operational goals for service-to-service communications and monitor them continuously.
• Measure and Track Availability
• Automated Change Sanity Testing
• Keep a risk matrix (then remove worst offenders, mitigate for those that are hard to immediately tackle, review regularly)
• Watch out for High Severity and High Likelyhood - existential (triggered plan - only act when it happens... ok sometimes)
• Two mistakes high analogy - nice way to consider that you need to be able to deal with two mistakes before the model aeroplane crashes.
• STOSA - single team-owned service architecture
• What does it mean to be a service owner? API design, develop, data, deploy, when to deploy, prod changes, environments, service SLAs, monitoring, oncall for incidents, reporting.