Designing Fine-Grained Systems - Building Microservices

Reading it through gives you a complete picture of building microservices. I have already had experiences with restful service design, cloud computing and so on. Microservice is just one step ahead. Good to see the author listing various software to use for each aspect and his judgement on them. Very helpful!

This is a good introductory book, unfortunately doesn't provide too much detail, or technical solution in a more deep way, still, present good concepts but without explaining those in the way someone with experience in the field would expect.

Excellent! Provides a holistic view - not only technical architecture but also the business- as well as the important organizational perspectives are covered. Anyone thinking of going the micro-service way - this book is for you!

This book's focus is on the patterns involved with implementing MicroServices. Thus, this book does a fantastic job at explaining these concepts. This book never intended to provide concrete implementation details (i.e. source code) for coding the actual architecture.

Spanning through almost 300 pages, Building Microservices was released at the end of 2015 and aim to provide a very high overview (believe me when I say very high) of microservices and all the aspects that should be taken into account when transitioning from a monolithic application to many small independent services that work together in harmony.

Throughout the text, the author introduces many different topics that must be taken into account, such as testing, and monitoring, among others. Each chapter focuses on a specific subject. Here the author describes the problems of the old one huge application only and the benefits we get by moving towards microservices. He also covers the new challenges this new architecture brings with itself (nothing is free, after all). The whole thing is often coupled with real life anectods from the author's experience.

As stated in the introduction, the book does not dive into any kind of platform or technology, thus ruling out becoming outdated in half a year. At the same time, though, it doesn't satisfy those readers interested in a more hands-on thing.

Building Microservices is a pleasant read. Well written and easy to follow. Most of its content does not necessarily apply only to microservices. The author does indeed discuss generic topics such as team building, versioning, logging. All these concepts apply to a broader spectrum and are interesting to a greater audience. On the other hand, most of them are already known to the majority of the readers. When I first got my hands on this book there was something I was particularly interested in: a step by step example showing me how to break down a monolith into microservices. This is indeed covered by the author (starting at chapter 5, by heart), but at such a conversational level that part of my hunger was not satisfied.

Overall, a good read. Everyone can benefit from it. Still, the book is quite pricey. When I have reached the back cover I was thinking within myself if it was worth it, when we have so many free resources, such as Martin Fowler's.

As usual, you can find more reviews on my personal blog: books.lostinmalloc.com. Feel free to pass by and share your thoughts!

As explained in the preface to this book, "microservices" are small, autonomous services that work together, each of which is focused on doing one thing well. While the topic of microservices is fast-moving, the term itself is new even though the idea is not. Be aware at the outset that some other reviewers here did not pay attention to the philosophy used for this book. Newman indicates that, due to the fast pace of change in this space, he tried to focus this book "on ideas more than specific technologies, knowing that implementation details always change faster than the thoughts behind them" and he fully expects that "in a few years from now we'll have learned even more about where microservices fit, and how to use them well".

After covering an introduction to microservices, including some key benefits and downsides, Newman discusses the architect in the context of microservices, followed by modeling microservices, integrating microservices, splitting monolithic systems, designing systems, and scaling microservices, as well as deployment, testing, monitoring, and security. The most heavily weighted chapters are the ones on integrating microservices and scaling microservices, which consume about 32% of the text, followed by the chapters on splitting monolithic systems, deployment, and testing, which together consume about 31% of the text. While I personally would have liked to have seen the development lifecycle chapters at the end of the book, the reader can simply read these last.

The "Microservices and SOA" sidebar of Martin Fowler's "Microservices" article indicates that the "common manifestation of SOA has led some microservice advocates to reject the SOA label entirely" and "others [to] consider microservices to be one form of SOA, perhaps service orientation done right", but "the fact that SOA means such different things means it's valuable to have a term that more crisply defines this architectural style". Newman instead clarifies the microservice approach by explaining it "as a specific approach for SOA in the same way that XP or Scrum are specific approaches for Agile software development", which "has emerged from real-world use, taking our better understanding of systems and architecture to do SOA well".

The author also wisely points out that "microservices are no free lunch or silver bullet, and make for a bad choice as a golden hammer. They have all the associated complexities of distributed systems,and while we have learned a lot about how to manage distributed systems well (which we'll discuss throughout the book), it is still hard. If you're coming from a monolithic system point of view, you'll have to get much better at handling deployment, testing, and monitoring to unlock the benefits we've covered so far. You'll also need to think differently about how you scale your systems and ensure that they are resilient. Don't also be surprised if things like distributed transactions or CAP theorem start giving you headaches, either!"

As a consultant architect, I especially appreciated Chapter 2 ("The Evolutionary Architect"), because of the sections entitled "An Evolutionary Vision for the Architect" and "Governance Through Code", Chapter 4 ("Integration"), because of the summary that the author provides on integration technologies in the context of microservices, Chapter 5 ("Splitting the Monolith"), because it appeals to my recurring project role as data architect, and Chapter 11 ("Microservices at Scale"), because of the summary it provides with regard to what happens when microservice architectures grow from simpler, more humble beginnings to something more complex in the long-term.

That said, I do agree with other reviewers of this book that there is some overlap between the content provided by the author and what is available elsewhere, although my only real qualms relate to the development lifecycle chapters, which probably would have been better placed in appendixes at the back of the text or minimally as concluding chapters. And while the author does point out example by example throughout his discussions, a bulk of these examples are either text descriptions or explained via high-level diagrams, and it would have been helpful if real-world examples were provided at a lower-level technical level of detail, even if, as Newman notes, this space is moving fast.

This book is essentially a composition of various loosely coupled ideas of different architectural concepts at a high level, with out any direct relevance to microservices and practical guidance. There aren't any use cases, case studies or practical examples to help you understand what microservices are really about and how they work in a real world. The author repeatedly mentioned other people's books and referred readers to read them. After the reading the book, I still feel puzzled with what the book is about and what purpose/benefits it brings for real IT applications..

The book thoroughly discusses all aspects related to adopting a microservice architecture.
It is not a programmer's book in the sense that you'll find no code; instead the author explains the different alternatives available to cope with the implications and problems entailed by this architecture, often accompanying the discussion with insights based on his experience and providing several external references to deepen understanding.

The book is addressed to software architects/technical leads that have the power (and responsibility) to choose to adopt/move to a microservice architecture and should evaluate what that means and coordinate the process afterwards. For a programmer this book might turn out to be a bit dry.

After introducing general microservives concepts and the advantages over traditional monolithic systems, the book addresses the importance of identifying "bounded contexts" in order to define microservice boundaries that allow development of microservices that have strong cohesion, are loosely coupled to one another and are small enough to be developed, tested, deployed and maintained by small teams.

The problem of shared database access between microservices is identified as a big no-no and several alternatives are presented to avoid it.
Also the interaction types among microservices and with the outside world are discussed with emphasis on the synchronous vs asynchronous interaction styles. The pros and cons of request-response RPC and REST and event-based message brokers are discussed.

Another point worth noting is the discussion of how moving from a monolithic system to microservices may incur splitting a single transaction into multiple transactions and what solutions can be adopted to counter this.

When discussing deployment the author suggests ways of managing artifacts produced with different languages/technologies, and explores the option of producing Virtual Machine artifacts complete with OS and all code and dependencies. Also touched is the issue of how to map microservices to hosts, virtualization alternatives and reliability/performance issues to consider with virtualization.

The chapter on security discusses the implications of security on microservice architectures and how the architecture should avoid functionality duplication while maintaining independence among the microservices. It discusses various security options for data in transit and at rest and suggests that different microservices may have different security needs and that such needs can be different for internal and external access.

Attention is also dedicated to microservice failures and how to avoid cascading effects where a failing microservice brings down other dependent microservices or the whole system. Finally scaling techniques to achieve higher reliability or better performance are presented together with the ensuing need to relax on consistency or availability requirements.

I found the title misleading... This is not a book about some new architectural concept or in-depth analysis regarding latest trends in Web Services. The book is an enumeration of good architectural practices with little value for the hands-on professional. (Little value not because they should be ignored, but because hands-on professional already masters them!) Very readable, with a good flow, the book covers high level concepts like: avoid tied couple components, event base systems, synchronous vs. asynchronous... and later goes on to common software practices such as: versioning, logging, deployment, continuous code integration, authentication and authorization... I see the book as a good material for a student starting in this field or managers trying to grasp these concepts. But I can only infer this was not the intended targeted audience.

Microservices are everywhere. Everyone talks about Microservices at major conferences all around the World but they are not new. Big players like the store and Netflix have been building distributed systems using this architecture since for many years. Sam Newman has worked for many companies that try to follow the lead. In this book, the first one on this subject, Sam does an incredible job at explaining all the concepts and condensing a lot of practical advices.

Every decision you should take is discussed. Every choice is debated in light of its advantages and drawbacks. Microservices are hard. That's a fact acknowledged by the author who does not try to hide the complexity of this architecture. However, Microservices has a lot of benefits too and Sam will convince you to seriously consider this style of architecture.

The book clearly lacks details about implementation. This is not the aim of the book, even if the title does confuse some readers. When more details are required (REST, Testing, etc), the author recommends other well-known books. Building Microservices is language-agnostic and this is a great strength. It includes many high-level examples like Netflix even if more details would have been better (examples of bounded contexts, architecture diagrams, etc).

Ultimately, Building Microservices is THE book I was waiting for. It distills a lot of information that is difficult to find elsewhere and it's always better to begin with a general overview which is exactly what this book does.

This is a good high level book about planning for and managing microservices. In my opinion it reads like a conversation a consultant might have with a development manager, and thus touches on a large array of topics, but I was disappointed that there were no lower level examples of "building" anything. Overall a good read on topics related to microservices, but I deducted one star because I felt the title was misleading compared to the actual content.

How do you break the monolith? This book will get you on the right path and put you there on the right time. This might not be now, or when you start a new project, as the author says. Great advice and very good and straight forward examples for real world applications and, most importantly, mistakes that the author did, and you can avoid.

Very opinionated at the beginning but I appreciate the conversational style the writer has incorporated into this book. Covers the basics of Microservices from High Level to have a bigger impact, allowing the reader to take those principles back to whatever language/domain/environment he or she is working on. Sound book.

This is a good book to understand the micro services concepts, how to design stuff and build micro services. The book does not go into much technical depths around how to build and scale micro services, It would have been good to show case examples on how you can scale micro services using any cloud infrastructure like AWS and best practices around it.

Useless theory and absolutely no depth in any material. Passing reference to REST, DOCKER etc etc... book feels more like authors opinion about these subjects rather than any understanding of it. Along with elementary flow charts.

The book does not have any working example... I've never seen an architecture book without code examples and it is horrible. If you want to read 280 pages of cryptic text - the book is for you. If you want to design and implement a microservice - you will be clueless even after you read the book, containing several diagrams only. I assume the author, probably, has not implemented a single working efficient microservice. However, he knows the concepts, uses popular buzzwords and can write text instead of writing code.

Tedious, hard to read and understand.
It's more of a collection of essays, rather than solid content.

And of course the number of references to previous narratives by ThoughtWorks is beyond tolerable.

This book is an amagelmation of the best practices for build large, scalable system. Topics range from: design patterns, API design, continus integration, continus delivery, testing, automation, virtualized environment and containers, monitor, security, database and CAP theorem.

All of the concepts are covered (not the implementations). When more details are required, the author recommends other (well known) books for references. As for software/tools, a few interesting ones are recommened, and it is up to the reader to investigate more details - Understandable as the software landscape changes rapidly.

Recommended reading for architect, engineer and DevOps!