blelump (2) [Avatar] Offline
#1
Hi,

let me share my thoughts about this book. Somewhere in the middle of the 2017 I've ordered both, Microservices Patterns and The Tao of Microservices (already released and printed) as a MEAP access. The table of contents of these two books looked very complementary so I've decided to take them both.

The table of contents of the Microservices Patterns tries to cover essential topics from the event-based world and for me personally, the excitement slightly ends here due to various reasons covered below.

# The title of the book -- Microservices Patterns.
When I see "Pattern" word in a book title, I expect a very specified and tailored content to the pattern word. In particular a list of receipts, like in a cookbook, that resolves very concrete problem or what ingredients you need to mix in order to get particular taste. In the case of "pattern", it can be summarized to "when A and when B then apply X" or "when C then apply Y". No more, no less. There're various pattern-applied books around touching the topic somehow. Lets just consider "Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions" or even the older brother from Manning, "SOA Patterns".

The thing is, all the patterns described in this book have been covered many times in literature and are nothing new. Perhaps I've expected something more being 'a child' in the microservices world. It seems, however, it is not so different than the world before microservices era, when CQRS + DDD + SAGA's were already known, but now evolved to the "micro" scale. I don't know what I've expected...

# Mixing the author's personal frameworks into the book content.
I am sure all the topics covered in this book can be described just fine without any additional frameworks or boilerplate, just to introduce another layer of complexity. It suggests framework first approach, whereas this is an implementation detail and does not provide any additional value to the problem description (it even makes it more diffcult, because you need to grasp some framework details).

# The overall style of the book.
As I went through the each next chapter, I have wondered, has anyone ever read this before releasing? Even though this is beta version and even though it will be probably fixed in the final release, as a MEAP reader I would expect at least a bit better text quality, where links to particular chapters work, "XYZ" or "TODO" things never happen and the content I read is straighforward (i.e. see the table 6.1, what these question marks mean?).

# The attitude to the monolith applications.
Even though the monoliths may be a pain, they are not the pure evil that have evolved to the monster creatures, because of various factors. Either DDD or even CQRS, in some circumstances, may be a foundation of big monolithic application that work just fine. The microservices, if designed badly, may be the same hell and they are not the cure here. Actually the book does not serve any concrete technique or approach to the 'how to, in practice, escape monolith hell?' problem when you already have a "big ball of mud".


Minor observations:
Quote: "What’s more, the FTGO developers would like to experiment with non-JVM languages such as GoLang and NodeJS. Sadly, this is not possible with a monolithic application."
The word 'experiment' sounds confusing here. Any technology is an implementation detail -- their purpose/application is to solve the problem, whether it is technology X or Y is not important. What about: the developers want to apply the technology X in order to solve the particular business problem and they're not able to do it in monolithic application? smilie


Since I've read The Tao of Microservices more or less at the same time, I have quite good comparison of these two. Personally I consider The Tao of Microservices as a much closer book to my expectations about the overall 'microservices' term (due to the reasons I've mentioned above), but I think this is not a place to complement another book. I've just wanted to share this reflection. I think this book may be a good start for someone not familiar with the intentions behind DDD or CQRS, but still, this book leaves me unsatisfied. As I said above, perhaps I wanted something that haven't ever existed... smilie
ceracm (102) [Avatar] Offline
#2
A few points

# Even though the monoliths may be a pain, they are not the pure evil ....


Not sure why you think that the book claims that monoliths are pure evil. I've even explicitly stated that microservices are NOT a silver bullet and you should choose them carefully. Having said that the FTGO scenario of monolith hell is extremely common in my experience.

# Mixing the author's personal frameworks into the book content.


The goal of the book is provide a working example application. That involves implementing some relatively complex concepts, such as transactional messaging. Because I defined some frameworks then (a) the underlying details of using, for example, Apache Kafka APIs are abstracted away so you don't need to understand them (b) you have a useful framework for your own applications.

# The overall style of the book.


All of those things will be cleaned up before the final version.




303018 (1) [Avatar] Offline
#3
I totally agree with chris's observation. In order to explain the implementation details, you have to talk about framework. The framework is very open in my opinion and built on top of spring boot. There is nothing wrong to talk about code as it explains things clearly. Even if you dont like the framework thats ok at least it goes into details on how to implement microservices. Great book chris...cheers