paulh (6) [Avatar] Offline
You have

"SOA and the microservice architecture also differ in how they treat data. SOA applications typically have a global data model and share databases."

Bad SOA did this, but good SOA implementations did exactly the opposite, i.e. Sales had a Customer entityt and Marketing had a Customer entity each in their own data stores which might vary widely. Any updated were acquired via messaging e.g. Marketing updates customer status to Preferred and Sales sees this message and changes its own data store.

You might want to mention the idea of "golden source" for each data element at some point.
206288 (1) [Avatar] Offline
I'd actually second this opinion with regards to all the points made in the book about SOA

The earliest definition I can find of SOA is the wikipedia page from 2005 ( - this definition of a service is pretty close to the accepted definition of a microservice. Please note the point that is made about it not requiring specific technologies to qualify as SOA.

When discussing architecture, it is important to separate the description of the architecture from the way it may be implemented. There are many, many examples of poorly implemented SOAs - criticism of these specifically should not be generalised into criticism of the architecture. I am currently repairing a very poorly implemented microservice architecture - seeing this terrible thing does not make me doubt the architecture but the level of knowledge and education present in the developer community.

In all other respects this book is addressing this knowledge shortfall - although I haven't finished reading it yet, everything else I have encountered makes perfect sense. IMHO a microservice architecture is a service-oriented architecture with most of the anti-patterns precluded i.e. a natural successor as opposed to something different entirely