What do you think?
Rate this book
The Tao of Microservices
The Tao of Microservices teaches you the path to understanding how to apply microservices architecture with your own real-world projects. This high-level book offers you a conceptual view of microservice architectures, along with core concepts and their application. You’ll also find a detailed case study for the nodezoo.com system, including all source code and documentation. By the end of the book, you’ll have explored in depth the key ideas of the microservice architecture and will be able to design, analyze and implement systems based on this architecture.
328 pages, Paperback
Published December 31, 2017
39 people are currently reading
286 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 18 of 18 reviews
January 27, 2019
Sometimes, I get very bad books. It is one of them. The microservices are a hot subject and looking around to understand the point of view of excellent authors seems to me the best thing to do. Few are excellent, and build-up a convergent view of the subject, many are acceptable, mainly redondant with the first ones. And few (including this one) are bad, throwing a radically different picture and pretending they are right and everybody else is stupid. Really, the author said the other guys are outdated !
This is not microservices, this is a nanocomponent view. The author is dogmatic about what should be done. His point of view carries a lot of problem, including architectural complexity at the system level, lack of strength and safety between component and mainteance nightmare. The author ignore all these issues by stating that's a problem of incompetence and all we need is a really strong architect (like him).
The author is not ignorant, it's pretty obvious along the reading. But the ideas and the arrogance of the author are hard to swallow.
Ma note de lecture en Français ici
This is not microservices, this is a nanocomponent view. The author is dogmatic about what should be done. His point of view carries a lot of problem, including architectural complexity at the system level, lack of strength and safety between component and mainteance nightmare. The author ignore all these issues by stating that's a problem of incompetence and all we need is a really strong architect (like him).
The author is not ignorant, it's pretty obvious along the reading. But the ideas and the arrogance of the author are hard to swallow.
Ma note de lecture en Français ici
January 24, 2021
A really good introduction to microservices and the thought process behind them. There were a lot of good insights, yet at points, I was left uncertain with some more convincing needed.
(Some of) the good aspects:
1. The combination of the message first approach and pattern matching seemed rather powerful in terms of flexibility of the entire system to adapt to the changing business requirements.
2. Really loved the entire discussion around quantitative measurements of error rates, deployment failures and failures in general. I think it is crucial to have explicit discussions on tolerable failure rates, tools to measure these kinds of metrics and processes surrounding that. It is particularly difficult, as typically people have the unrealistic expectation of "everything should work perfectly". Coming from physics, I know that nothing is certain, there's always a level of uncertainty involved. After spending time in software industry, I also learned that there will always be bugs. You can limit their impact, have processes on reducing their number, yet they will appear. Even in production.
3. Automation is a must. Ideally, I'd stress that we should strive for automation in any environment. If it is possible (and cost-effective) to reduce manual labour, then we should integrate that into the workflows. Obviously, microservice architecture takes automation from the realm of good-to-have to complete necessity, otherwise, manual management of all those services would drive one to insanity.
4. Eventual data consistency. This book led me to think more about the entire concept of data storage and expectations behind the consistency of the data. There definitely are a lot of use cases where eventual consistency is good enough for the user, which helpfully leads to higher levels of availability. It's an important conversation to have, yet it can become a rather sensitive or easily dismissed topic in the world where we're striving for perfection.
5. The author also touched on the pitfalls of creating a distributed monolith, when one naively hoped to build microservices. It's particularly easy to get thing wrong, when microservice architecture is requiring a different way of thinking in the first place.
6. There needs to be a shared library that implements communication. Individual services should not need to reimplement how these messages are sent, otherwise, it'll lead to chaos.
7. At the end of the day, projects involve politics. I enjoyed that the author did not shy away and gave some advice on how to gather allies, how to increase political capital and decrease the likelihood of making enemies or having the project cut off before it's even complete.
Some of the aspects I did not like or was not convinced about:
1. I find it hard to intuitively understand the sizing of microservices. The author suggests to consider the microservice size to be about one iteration (typically 2 weeks) of development. However, this sounds rather small and extreme in my point of view.
2. Latency. For example, the discussion revolves around using composition of services to process requests, yet each remote message is an additional layer of network to go through. The book lacked examples of really large systems, how they handle high-performance services and generally brushed off a lot of performance-related questions as future problems.
I found this a really good and instructive book. In terms of microservice architecture, I'm yet to be convinced whether one really needs to start with microservices right off the bat. There are a lot of fine lines here that I do not yet have the experience, nor intuition, to answer. Still, I'd like to find myself in a place where microservices are done right at scale, where I could learn in practice about their advantages and limitations.
Finally, I recommend this book to those who are open to another point of view (despite the hype of microservices) and are curious to see a different approach to the problem. There are a fair number of insights between the pages of the book. Enjoy!
(Some of) the good aspects:
1. The combination of the message first approach and pattern matching seemed rather powerful in terms of flexibility of the entire system to adapt to the changing business requirements.
2. Really loved the entire discussion around quantitative measurements of error rates, deployment failures and failures in general. I think it is crucial to have explicit discussions on tolerable failure rates, tools to measure these kinds of metrics and processes surrounding that. It is particularly difficult, as typically people have the unrealistic expectation of "everything should work perfectly". Coming from physics, I know that nothing is certain, there's always a level of uncertainty involved. After spending time in software industry, I also learned that there will always be bugs. You can limit their impact, have processes on reducing their number, yet they will appear. Even in production.
3. Automation is a must. Ideally, I'd stress that we should strive for automation in any environment. If it is possible (and cost-effective) to reduce manual labour, then we should integrate that into the workflows. Obviously, microservice architecture takes automation from the realm of good-to-have to complete necessity, otherwise, manual management of all those services would drive one to insanity.
4. Eventual data consistency. This book led me to think more about the entire concept of data storage and expectations behind the consistency of the data. There definitely are a lot of use cases where eventual consistency is good enough for the user, which helpfully leads to higher levels of availability. It's an important conversation to have, yet it can become a rather sensitive or easily dismissed topic in the world where we're striving for perfection.
5. The author also touched on the pitfalls of creating a distributed monolith, when one naively hoped to build microservices. It's particularly easy to get thing wrong, when microservice architecture is requiring a different way of thinking in the first place.
6. There needs to be a shared library that implements communication. Individual services should not need to reimplement how these messages are sent, otherwise, it'll lead to chaos.
7. At the end of the day, projects involve politics. I enjoyed that the author did not shy away and gave some advice on how to gather allies, how to increase political capital and decrease the likelihood of making enemies or having the project cut off before it's even complete.
Some of the aspects I did not like or was not convinced about:
1. I find it hard to intuitively understand the sizing of microservices. The author suggests to consider the microservice size to be about one iteration (typically 2 weeks) of development. However, this sounds rather small and extreme in my point of view.
2. Latency. For example, the discussion revolves around using composition of services to process requests, yet each remote message is an additional layer of network to go through. The book lacked examples of really large systems, how they handle high-performance services and generally brushed off a lot of performance-related questions as future problems.
I found this a really good and instructive book. In terms of microservice architecture, I'm yet to be convinced whether one really needs to start with microservices right off the bat. There are a lot of fine lines here that I do not yet have the experience, nor intuition, to answer. Still, I'd like to find myself in a place where microservices are done right at scale, where I could learn in practice about their advantages and limitations.
Finally, I recommend this book to those who are open to another point of view (despite the hype of microservices) and are curious to see a different approach to the problem. There are a fair number of insights between the pages of the book. Enjoy!
August 5, 2018
I wish I could give this book three or even four stars. There’s pretty good content, but also too much of that engineering culture I can’t stand (10x devs, work late at night and weekends, GitHub stars for evaluating libraries, and so on... it is a long list)
July 4, 2018
Interesting discussion about microservices with some good ideas in there, but a little bit too sure of its conclusion. The fact that the gist of the solution involves using the author's library turned me off a bit.
October 9, 2018
An excellent book after seeing so many "recipe" books.
Talks about the concepts - breaks down into patterns and also keeps this consistent throughout.
One tip is to after the first skim to start with the messages before the services section.
Talks about the concepts - breaks down into patterns and also keeps this consistent throughout.
One tip is to after the first skim to start with the messages before the services section.
November 2, 2019
میکروسرویس خیلی پیچیدهست. من تجربهی کار کردن با/تو یه میکروسرویس رو نداشتم. ولی قطعا اگه روزی این تجربه رو کسب کنم، بعدش باید این کتاب رو دوباره بخونم. خیلی نکات و ریز حساسی وجود داره اگر بخوایم یه سیستم رو کاملا استاندارد پیاده کنیم
April 19, 2021
Oh the first few chapters were brilliant, refreshing and setting itself apart from all other ‘microservice’ pseudo-guides.
Of course microservices are not about the services! Of course not! It’s all about the messages! If there’s only one thing to be taken from this book, it is that messages are what’s really important in a microservice architecture. Everything else revolves round messages. The tiny services are there to facilitate messages handling and the rapid changes needed for the messages. The emphasis on automation and infrastructure is just so that we can manage, distribute, trace, and reason with the messages easier. Messages are great for their self-containedness, and their exploit nature preventing implicit coupling in code in monoliths.
Another view to see it, though the author didn’t say it out loud, is to view microservices as pure functions that abstract with only inputs and outputs.
I cannot recommend this book enough for anyone on the microservice bandwagon. Do begin with this book before you touch any other books on microservice.
Of course microservices are not about the services! Of course not! It’s all about the messages! If there’s only one thing to be taken from this book, it is that messages are what’s really important in a microservice architecture. Everything else revolves round messages. The tiny services are there to facilitate messages handling and the rapid changes needed for the messages. The emphasis on automation and infrastructure is just so that we can manage, distribute, trace, and reason with the messages easier. Messages are great for their self-containedness, and their exploit nature preventing implicit coupling in code in monoliths.
Another view to see it, though the author didn’t say it out loud, is to view microservices as pure functions that abstract with only inputs and outputs.
I cannot recommend this book enough for anyone on the microservice bandwagon. Do begin with this book before you touch any other books on microservice.
February 19, 2020
Superb introduction to the concept of microservices, with some very practical hands-on guidance for getting your microservices project off the ground. We used this textbook as something of a template during the early days of our company's formation, and it was extremely useful. We got everyone on the team to read it, and we discussed it chapter-by-chapter.
As we've grown, as as the industry has matured in this space, we've now evolved our architecture and diverged from some of the patterns and ideas in this book, but that doesn't detract at all from how genuinely insightful and helpful this was during the early days. Strongly recommended for anyone wishing to get into the mindset of microservices development.
As we've grown, as as the industry has matured in this space, we've now evolved our architecture and diverged from some of the patterns and ideas in this book, but that doesn't detract at all from how genuinely insightful and helpful this was during the early days. Strongly recommended for anyone wishing to get into the mindset of microservices development.
September 18, 2020
The content of the book is very on-point, there are very few side-talks along the way. I still can't fully picture the image of a system as described by Rodger. The idea of "message-first" is not so radical, but the sizing of the services are really small and pose other issues and difficulties on the process that make us feel that we are only changing the problem-set.
Ofc, for companies that *need* that scale, what we are looking at is that this architecture can produce such power before you going bankrupt. But is that true? Still don't know.. would like to build something similar to have this experience on my belt.
Ofc, for companies that *need* that scale, what we are looking at is that this architecture can produce such power before you going bankrupt. But is that true? Still don't know.. would like to build something similar to have this experience on my belt.
January 15, 2019
There is some decent information in this book. What I really didn't like is the Rodger's attitude about other architectural styles and how he railed against them. He takes his zealousness for microservices to the level of being a zealot.
Another strike against the content is that all the example code is written in a framework that the author wrote himself. It doesn't seem like very transferable knowledge.
Another strike against the content is that all the example code is written in a framework that the author wrote himself. It doesn't seem like very transferable knowledge.
April 28, 2020
A decent review of the Microservices style of software: messages first, then services; uncoupled services; messaging methodology; data handling; and deployment. In my view the basic ideas are well presented; the review of data handling seemed very superficial, while the ideas in the chapter on deployment are essentially obvious if you have followed the preview chapters. In essence, I found the chapters of variable quality.
February 6, 2020
خیلی کتاب کامل و جامعی است
نویسنده همچنین توسعه دهنده یکی از بهترین کتابخانه های توسعه مایکروسرویس برای جاوااسکریپت نیز می باشد و همچنین تجربه پیاده سازی و همکاری در پروژه های بزرگ را دارد.
کتاب خیلی عمیق به مباحث مایکروسرویس میپردازد.
قبل از مطالعه این کتاب بهتر است با مایکروسرویس ها آشنا شده و سپس برای پیاده سازی پروژه های بزرگ این کتاب مطالعه شود.
نویسنده همچنین توسعه دهنده یکی از بهترین کتابخانه های توسعه مایکروسرویس برای جاوااسکریپت نیز می باشد و همچنین تجربه پیاده سازی و همکاری در پروژه های بزرگ را دارد.
کتاب خیلی عمیق به مباحث مایکروسرویس میپردازد.
قبل از مطالعه این کتاب بهتر است با مایکروسرویس ها آشنا شده و سپس برای پیاده سازی پروژه های بزرگ این کتاب مطالعه شود.
May 6, 2020
I like the strong opinions of the author. Some of those opinions do align to my experience and some of them hit the bull's eye and I definitely felt the pains he described there. That's the reason I loved the book as it felt like talking to a person with similar views but with different experiences.
June 23, 2018
Some good stuff here. Would have liked more concrete examples though. I will be mining the footnotes for ideas for a while, would have been nice to have been provided a bibliography or something though.
Currently reading
October 4, 2019some gems:
We have a self-important belief in our work, as artists, that isn’t connected to the reality of our systematic failure.
We have this thing called refactoring, which is the technical term for getting caught making bad guesses.
We have a self-important belief in our work, as artists, that isn’t connected to the reality of our systematic failure.
We have this thing called refactoring, which is the technical term for getting caught making bad guesses.
July 29, 2018
The first few chapters were good (the article case study and the message flow), but later it started covering things that imho are a bit too basic.
November 23, 2024
Focus on the messages to derive the services.
June 7, 2017
This review is for the V5 MEAP -- this means the book is not finished but I want to add some insight for those who are not sure to buy this book beforehand.
Well, the concept of the book is great: you get an introduction to microservices without any technical language / implementation option focus. You will be able to approach designing microservices -- but you have to change your mindset from technology-oriented.
I give currently four stars because of the grammar in the book. I am not a native English speaker (reader) but it hurts me what I read sometimes. I know it is hard to write and correct the errors but a proofread from the author himsel would be not bad prior submitting a new chapter. I hope the final proofreading will eliminate these problems and I can update my review to 5 stars.
Well, the concept of the book is great: you get an introduction to microservices without any technical language / implementation option focus. You will be able to approach designing microservices -- but you have to change your mindset from technology-oriented.
I give currently four stars because of the grammar in the book. I am not a native English speaker (reader) but it hurts me what I read sometimes. I know it is hard to write and correct the errors but a proofread from the author himsel would be not bad prior submitting a new chapter. I hope the final proofreading will eliminate these problems and I can update my review to 5 stars.
Displaying 1 - 18 of 18 reviews