Production-Ready Microservices: Building Standardized Systems Across an Engineering Organization

by Susan J. Fowler

One of the biggest challenges for organizations that have adopted microservice architecture is the lack of architectural, operational, and organizational standardization. After splitting a monolithic application or building a microservice ecosystem from scratch, many engineers are left wondering what s next. In this practical book, author Susan Fowler presents a set of microservice standards in depth, drawing from her experience standardizing over a thousand microservices at Uber. You ll learn how to design microservices that are stable, reliable, scalable, fault tolerant, performant, monitored, documented, and prepared for any catastrophe.

Explore production-readiness standards, including:



Stability and Reliability: develop, deploy, introduce, and deprecate microservices; protect against dependency failures

Scalability and Performance: learn essential components for achieving greater microservice efficiency

Fault Tolerance and Catastrophe Preparedness: ensure availability by actively pushing microservices to fail in real time

Monitoring: learn how to monitor, log, and display key metrics; establish alerting and on-call procedures

Documentation and Understanding: mitigate tradeoffs that come with microservice adoption, including organizational sprawl and technical debt
"

Genres: Technology, Technical, Programming, Software, Architecture, Computer Science, Computers

153 pages, Paperback

First published December 15, 2016

Reviews

[Rod Hilton · Rating 3 out of 5]

I wanted to like this book a lot more than I did. I see Microservices as a "fad" that's picking up a lot of steam, and I work with microservices but want to know how to be more effective building them. The notion of a book entirely devoted to discussing how to make your microservices production-ready was very appealing.

However, like many other reviews of this book, I found it to be far too high-level to be very useful. Almost every section makes the reader think "that's really interesting, I'd like a little more detail on that" only to have the subject change for the next section. You never get that detail you're craving, and it's very unsatisfying. In fact, I don't think there's almost any part of the book where an engineer could read it and then come away thinking about what to do next to improve their microservices. The only "next step" after reading anything is to read something else. The only exception to this is the Documentation section, which actually provides a fairly decent template for writing microservice documention, because documentation is so high-level that a high-level discussion of it actually felt appropriate.

The author states "each section of each of the chapters within this book could be expanded into its own book" as a way of basically dismissing the idea of incorporating direct useful details into this book. And yet, Eberhard Wolff's "Microservices" does exactly that - containing almost all of the information in this book, PLUS all the details you'd need to actually incorporate the information from the book into your microservices, and it clocks in at 395 pages, a mere 2.5x this book's 153 pages. Why would you ever bother reading this one?

The answer is, you wouldn't. At least, not as an engineer. Susan Fowler's "Production-Ready Microservices" isn't a book for engineers. Wolff's book is for engineers. "Production-Ready Microservices" is for managers. If your engineer team has found itself building microservices (or, as is increasingly common, told to build microservices by management because it's en vogue), but you need to do something to convince management that you need to put more time into this or that aspect of your microservice architecture to make it production-ready, hand your manager a copy of this book. It's only 153 pages, and it even contains checklists. You can point directly at the checklist and say "look, we're not doing this, that, or this - we're not ready for production yet" and it looks official enough because it's in a book. It's an effective tool in this regard, I think.

Otherwise, the book kind of feels like a consultant coming in and looking at your microservice architecure and poo-pooing it, just being judgemental about what you're building or you've built. "Nope, you're not doing these three things on my checklist, this isn't production ready." Oh, okay. So, do you have any concrete suggestions for how to fix this? "Look, that'd be an entirely different book okay? I don't have time to tell you that, I just want you to know that I know what you've built isn't good." Oh. Alright well, thanks for nothing.

The checklists are indeed super handy, I can easily see referencing them when discussing production readiness with co-workers. But aside from that, this is a book I'd give a manager to help them understand the architectural situation, but otherwise never really reference myself. For engineers, I'd definitely recommend Wolff's "Microservices" over this book.

[Sebastian Gebski · Rating 4 out of 5]

Frankly, I wasn't interested in reading this book at all. Another book on microservices? What for? Don't we already have absolutely awesome "Building microservices" by Sam Newman? I've decided to read it after the famous Internet drama - when book author's (Susan) has described her work experience in Uber (that shitty way she was treated & well, let's be honest - harassed). I didn't do it because of this story, no - simply I've learned this way that Susan is a real practitioner - someone who has played a real role in microservice transformation in large start-up. I was just curious what does she has to say.

Again - frankly - this book won't tell you anything really new if you've read Newman already. But what is really interesting is the perspective presented in this book. While Sam was more academic, very thoughful, trying to present a holistic perspective, Susan is very practical, strict & provides a "checklist-styled" description of what microservices should look alike. In the same time she's extremely platform-agnostic (she uses pure arch concepts without even providing any tech names, well maybe except Mesos), which makes the book more approachable, but in the same time - a bit high-level.

Honestly - I appreciate her perspective, but in some cases she provides VERY interesting insights but unfortunately without telling much regarding potential solutions. One of the best examples is versioning: Susan clearly discourages (2 or 3 times) from versioning the service at all, but she doesn't dig the consequences of this decision & how one can compensate / mitigate them.

What is more, this book is a little bit disappointing in terms of "kitchen secrets" - Susan doesn't write a lot about particular issues, warstories, how did Uber approached some particular problems, how did it work out, what were the lessons learned, etc. Her message feel more "post-processed" & generalized.

In the end - it doesn't mean it's a bad book - quite the contrary, I find it very useful, BUT if you're just to pick ONE & only one book about microservices, I'd rather advice you to go for Sam's one.

[Alex Ott · Rating 3 out of 5]

Too high-level, only common words, like, should, can, ... Lack any technical details...
People with practical experience may not find something new there

[Colin Jones · Rating 4 out of 5]

This book is a great counterbalance to the fashionability of "microservices." It gives a pretty wide-angle picture of the various architecture, performance, monitoring, and related processes at large tech companies like Uber. There are lots of checklists and probing questions to dig into projects' suitability for production, and the value definitely isn't limited to microservices.

Smaller companies are going to have a hard time adopting these practices wholesale, but to me, the unspoken implication is that maybe they shouldn't be adopting microservices either. I see this as a logical extension / elaboration on Martin Fowler's [no relation AFAIK] blog post "You must be this tall to use microservices." And I'm glad to have a place to point teams who think microservices are going to solve their development problems for free.

[Denis Capeto · Rating 4 out of 5]

I think it really worth it reading it. The book brings a clear path on what a microservice should have and also gives the question you should ask in order to check if your microservice is read for production. The chapters that I like the most is 5 fault-tolerance and DR , 6 monitoring and 7 documentation

[Max · Rating 4 out of 5]

Like a good microservice, PRM exceeds at doing one thing and doing it well: explaining the practical administration of a microservice ecosystem to reach high availability. The equivalent negative framing is that PRM is not a book about what functionality should be in a microservice, how to design distributed systems, or how to abstract away common patterns into different microservices. Fowler states as much in her book, arguing for standardization in microservice ecosystems with the primary goal of improving system availability. The advice is practical and actionable, with check lists to boot.

Fowler's insights into the blending of organizational and technical insights was the most unique part of the book. Though Fowler states that she avoids making the book a case study in how Uber implements microservices, it is clear that many of the principles of the book are driven by the needs of an engineering org that is "Uber-scale," with a multi-thousand engineering org and massive user / data scale. As a result, there are many insights from managing an engineering org at that large. The Inverse Conway's Law is a particularly useful nugget, which suggests that microservice design is coupled with the design of an engineering org itself. This idea has important implications about how to design services and who in an org should be involved in building services.

I found PRM lacking in terms of how small, resource-constrained engineering orgs should think about getting to production-readiness. PRM describes the idealized microservice ecosystem, where all microservices have gone through audits, where all boxes are ticked off. But how should a real-world, highly resource-constrained team think about tradeoffs with production readiness? What are the nice-to-haves and what are the must-haves? I am sure Fowler has learned a lot from her time building the microservices ecosystem at Uber and would be able to suggest appropriate tradeoffs, especially ones with long term implications.

PRM is the Checklist Manifesto of the modern software engineering org, the practical Roman administration to the Greek philosophizing, the standardization of sizes of nuts and bolts to the steam engine of the Industrial Revolution. Its practicality, straight-to-the-point style makes it quick to read and deploy in practice, and will surely become part of the modern software engineering cannon.

[David Sullins · Rating 4 out of 5]

I see a few reviews here complaining that the book is pretty light and high level. I agree with that characterization while disagreeing with the conclusion that it makes it poor book: This book is excellent as a small sharp tool to guide your thinking about how to get microservices ready for production.

This book does not explain how to write microservices. Instead, it asks the questions you should have the answers to in order to get your microservices ready for production. Each chapter contains checklists, explanations and justifications for the checklists, and questions to help you evaluate your microservice at the end of each chapter. Some are simple yes/no questions ("Does the microservice have a central repository where all code is stored?") but most require you to think more about the answer ("What information does this microservice need to log?")

The one head-scratcher for me was the advice not to version microservices. I really would have liked more justification and explanation for that choice, because I didn't feel I really understood the tradeoffs.

[Nishanth Vijayan · Rating 4 out of 5]

3.5. It's a little repetitive and wordy. I had already read Sam Newman's book Building Microservices and hence was familiar with a lot of the ideas presented in the book. Recommended if you / your organisation is new to Microservices.

[John Maguire · Rating 5 out of 5]

Essential reading for anyone looking to move to using microservices

[Long Nguyen · Rating 4 out of 5]

A bit wordy and repetitive in some chapters. Still a great book, overall.

[Ganesh Venkataraman · Rating 4 out of 5]

A good book for architects and engineers to build resilient applications. Many of the features required to build a resilient, fault tolerant application are typically deferred to latter stages of the development making the overall product barely production ready. The guidelines provided in this book could be used in general for any feature, application or product development. Key is in building and testing non functional requirements(NFRs), such as resiliency, scalability, availability etc iteratively and not just at the tail end of the development pipeline.

Cloud has also made it easier to automate coding and testing most of these resiliency features, increasing developer velocity as well as end-to-end accountability for engineering your eco-system.

The production readiness checklist is something you can use right away and the book is a quick read for a very weekend.

[The Architect · Rating 4 out of 5]

High overview of what your microservices should fulfill before you put them in production. You won't find here technology specific stuff, so this will feel a bit like half of a journey, letting you hunt for concrete technology stack and specific procedures... but if you are serious about it, you should know all this before you start with that hunt.

Susan structured material very well, in manner of the checklist - so when you are ready to put your microservices through audit, you can use her checklist to make sure you haven't forgot about something.

[Miguel · Rating 4 out of 5]

Really enjoyed this book. It was at the righr level of abstraction I was looking for and could tell by how thin it is.

If you're looking for a low level technical book, this is not for you. But if you're in charge or affecting the microservice revolution from a people manager or it policy maker of any kind this book needs to be in your library.

Good artists create, great artists copy. This is true for IT workers too!

[ziombel · Rating 3 out of 5]

Książka poświęcona jest budowie systemów mikrousługowych. Autorka nie skupia się na żadnej konkretnej technologii - zamiast tego omawia zagadnienia w sposób bardzo ogólny i mało techniczny.

Na początku książki autorka opisuje ogólnie czym są mikrousługi. Następnie w kolejnych rozdziałach opisuje co według niej świadczy o tym, że usługa jest gotowa do niezawodnego działania i w jaki sposób można to zapewnić. Przechodzi przez takie zagadnienia jak stabilność, niezawodność, skalowalność, odporność na awarie, monitorowanie oraz dokumentowanie.

Nie czytało mi się tej pozycji zbyt przyjemnie ze względu na dużą ilość powtórzeń. Polskie tłumaczenie zawiera też trochę dziwnych wyrażeń(jak fronton(front end)). Dziwi mnie też to, że tłumacz nie był pewien płci autorki, ponieważ część tekstu brzmi jakby wypowiadała się kobieta, a w część jak mężczyzna(np. zaczęłam a zaraz później stworzyłem).

Gdzieniegdzie w tekście są też dziwne i czasami niespójne sformułowania, z którymi jako programista nie mogę się zgodzić. Np. twierdzenia o tym, że mikrousługa może być wdrożona dopiero wtedy, kiedy nie zawiera żadnych błędów. Każdy kto ma przynajmniej podstawową wiedzę o oprogramowaniu wie, że nie jest to możliwe ze względu na złożoność aplikacji. Przetestowanie aplikacji pod każdym względem w każdych warunkach, jakie mogą tylko wystąpić jest zbyt kosztowne. Nawet po najlepszych testach nie wie się, gdzie są jeszcze jakieś błędy(bo na pewno jakieś są). Co nie szkodzi autorce później pisać o tym, że w mikrousługi cały czas się zmieniają i przez to normalnym jest, że jest w nich pełno błędów(co mocno przeczy stawianym przez nią wymaganiom przy wdrażaniu nowych wersji). Według mnie jest to niefortunne sformułowanie, bo gdyby napisała o tym, że nie powinno się wdrażać usługi gdy wiemy że zawiera poważne błędy, to nie miałbym z takim stwierdzeniem problemu. Niestety w książce jest wiele tego typu kategorycznych sformułowań, które według mnie nie były dobrze przemyślane, co kuło mnie co jakiś czas w oczy.

Wydaje mi się, że książka została napisana jako krótki przewodnik dla kadr zarządzających, które miałyby tworzyć własny system mikrousług i chciałyby wdrożyć odpowiednie procedury oraz przebudować w tym celu swoją organizację. Książka może zaciekawić też osoby, które chciałby poznać większy obraz pracy nad tego typu systemem.

[Ulina · Rating 4 out of 5]

I was excited about this book when it first was released. However, it took me 3 years to finish the book for several reasons. One of the majors reasons being that it was so dry. I understand that tech books are hard to make lively, but there was no personality or flavor to this book. I've read tech books that had some personality, which made reading the book like a book and not a reference book, much easier.

This books is a high level look at what to do in order to have production ready micro-services. It covers the "what" and not the "how". The book is good for new engineers and engineers that have never worked at a big company or on a distributed system before. This book will ramp them up on the different parts of a service, why most monoliths should be broken down into smaller services, how to deal with continuously building, outages, on-call ..etc. This book is also good for managers that need to understand how the full system fits together and the complexity involved when making changes to the systems.

I read tech book to learn something new, and while reading this, I didn't feel like I was learning something new. However, I had to remind myself that I have been working in this industry for more than a decade and that this should be familiar. So I decided to bump my original rating from 3 to 4.

[Leandro López · Rating 5 out of 5]

Excellent! The author did an awesome job writing this book: she didn't missed anything that is required when thinking about microservices. But don't be fooled: this isn't a "only for microservices" book: the lessons, checklists, and all the insights within this book apply to software development in general, and rest assured that following these ideas will make you project successful and yourself a better developer.

Five stars book, one of those you HAVE to have in paper format in your bookshelf.

[Bharath Kotha · Rating 4 out of 5]

Though the book starts out with a lot of jargon, there are definitely some points in the book that makes you say "gotcha". A lot of the content is repeated multiple times in the book in various chapters, but you'll probably learn a few things that you wouldn't have thought cause issues. It could stay as a good checklist if you're trying to implement at your organisation and facing stability and uptime issues. A very small read and you won't even feel that you're reading a technical book (well, it's about tech-ops mostly anyway)

[Alok · Rating 4 out of 5]

Fowler's book gives a great introduction to the practical considerations of running microservices in production. The full spectrum of work required to make a microservice production ready and to keep it production ready as part of an evolving ecosystem is daunting. The book focuses on operations, and does not give a lot of guidance into how to structure microservices. It is worth reading if you are considering having your business depend on a microservice.

[Matt · Rating 3 out of 5]

I think this book is best understood as a gigantic checklist to verify if your microservices in your organization are ready for a production environment. I'd suggest starting from the Appendix that lists all the questions that attempt to classify the readiness of a service. If you want to read the chapters, understand that their main function is to support why those particular questions are on the checklist.

[Rafael Coimbra · Rating 3 out of 5]

Bom para quem é principiante no assunto e tem algum conhecimento em tecnologia da informação. Não é indicado para quem deseja se aprofundar em como implementar microsserviços. Mesmo que o foco do livro seja em apontar o que é necessário um microsserviço ter para ser considerado pronto para produção, ainda assim há algumas pontos que não são tão bem descritos ou explicados. Exemplos práticos de aplicação dos conceitos seriam bem vindos.

[Hien Le · Rating 1 out of 5]

Felt like I was reading an introduction rephrased 100 different ways until the author forgot the point that was trying to be made. There's an upfront disclaimer that the book talks about general approaches and mindset rather than delving into technical specifics and does it ever stick to that promise.

[Abdurrachman · Rating 4 out of 5]

A very good book talking about microservice. Have been developing tools and test for developing microservice architecture it reflects my experience working in my company and in the industry. Many lessons you can learn from this book. I recommend this book for any software engineer who wants to be a thoughtful craftsman.

[Andres Raieste · Rating 5 out of 5]

Very good reference and guidance

I required to understand (from management position) how to get a major system utilizing microservices to production. Granted, I have tech background, but this book covered it from A to Z for me. Recommended reading both for tech leads and technical managers.

[Michel Fernandes · Rating 4 out of 5]

Concepts were clearly explained and covered all aspects of microservices ready for production.

Despite, sometimes it is very repetitive and lacks good examples from Uber about good practices and bad practices were not explored, maybe due to confidentiality.

Even though is a good reference for developing, keeping, and involving microservices, in general.

[Jared Moore · Rating 3 out of 5]

The first chapter was amazing and easy to read and got me excited to read the rest of the book. The rest of the book was just so dry and uninteresting it was really hard to stay focused. It’s like reading an instruction manual, it’s just facts like do this and also do that no stories or examples to break up the monotony and make it interesting

[Jacek · Rating 4 out of 5]

Very good book from a person responsible for readiness process.
You have a very good list of topics that you have to be aware before you ship your book on a production systems. Susan presented all her knowledge in a nice form, easy to read

[Stefan Ritter · Rating 5 out of 5]

This is a must read for every developer and product manager. The book is a practical how-to from an author who knows her craft. Great and valuable insights from running and developing real world micro services at scale.

[Lev Kurts · Rating 3 out of 5]

Good checklists - lacks depth

Good overview of micro-services ecosystem, challenges and ways to make it more stable. Would love to see more in depth and concrete examples and a little less repetition.

[Gonzalo Fernández-Victorio · Rating 5 out of 5]

The book helps thinking how to organise a microservice architecture.
It's a very short book and well worth reading. However, it's not so much a book withs stories to make you remember, but more prescriptive, with lots of checklists, and more focused in processes than specific practices.

[Paul · Rating 5 out of 5]

Refreshing overview of the complexities (both technological and organizational) that come with running microservices.

The book provides a great high level checklist of things you should do (as an organization) to be successful in this game. Just wish I had read it three years ago.