The second edition is more cautious than the first and is better for it: it defines what a microservice is, works through coupling and cohesion, shows how to split a running system without stopping it, how to separate the database, how to communicate, test and observe services, and what happens to the organisation that does this.
What I did with it
I mostly use it to say no. The prior question is whether the problem is technical scale or organisation; if a company has one team and one system, splitting it into services adds latency, partial failures and an operational burden with nobody to carry it. I now say that with the book behind me rather than as an opinion.
What does transfer, always, is the chapter on distributed workflows. Between an ERP, the tax authority, the bank and the logistics operator there is no transaction that can be rolled back in one move: there are steps and compensations, and they have to be designed. When someone asks what happens if the external system accepts and ours fails, the answer has to be written beforehand, not improvised on the day.
And the material on separating databases gave me the argument against integrating through shared tables. Two systems writing to the same table are married without a contract: neither can change anything without breaking the other.
What I left out
Nearly all the operational content: orchestrators, service meshes, progressive rollouts. That needs a platform team, and anyone without one is buying a permanent problem. It is also fair to say the book suffers from what it warns against: six hundred pages about something most people should not do, and that proportion does not help the message land.