Production-Ready microservices - Book review and my personal notes

Last updated Oct 30, 2022 Published Oct 26, 2020

The content here is under the Attribution 4.0 International (CC BY 4.0) license

Microservices are a trend that is growing even more [1], recently I read the book “Production-Ready microservices” from Susan J. Fowler and it gave me insights on how to prepare or at least to have a guide to go through when developing in a microservices oriented architecture. Susan says in the book that this is a guide that she wish she had when she started to standardize the microservices at Uber, in this sense the collection is tested in a “production” like environment and in a “big” size company.

Besides that, a few chapters can be taken and applied to any kind of architecture. For example, the reliability section, which elaborates on processes and how to document them for other developers, people on call or other teams - Any team in regardless of the architecture style will need something similar to that. Meaning that Susan’s work agree on what Martin Fowler said (and Edson Yanaga used as a quote as well [2]) around microservices:

Almost all the cases I’ve heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.

Here I summarize what I found interesting and what makes sense in my context as a developer.


The splitting of a monolithic application into microservices is driven by scalability and efficiency concerns, but microservices introduce challenges of their own. [3] reported an case study on the open source project Istio, which migrated from microservices to a monolith architecture - quite an interesting case.

A successful, scalable microservice ecosystem requires that a stable and sophisticated infrastructure be in place. In addition, the organizational structure of a company adopting microservices must be radically changed to support microservice architecture, and the team structures that spring from this can lead to siloing and sprawl [4].

[5] also argues that microservices brings challenges different challenges and more complex if compared to the monolith, he also mentions that taking the decision to go with microservices should be taken carefully. As the nature of distribution of microservices scales the complexity required for teams to delivery working software.

She goes into the first chapter of the book, discussing the monolith approach of building an application, using a layered architecture (in this case a three tier with the frontend, backend and the database) and the possible strategies to scale this application due an event of an increasing demand.


On the other hand, [4] rises the point, that the largest challenges that microservices bring is the need for standardization of the architecture. In the context of the book, it is understandable, as she was creating the process for uber and they already had a few hundreds of services running.

To say that a service is production ready, she defined eight principles that if met, the service is considered production ready. This section dives into those criteria based on the book definition.


  • Stable development life cycle
  • A stable deployment process
  • Stable introduction and deprecation procedures


  • A reliable deployment process
  • Planning mitigating, and protecting against failures of dependencies
  • Reliable routing and discovery


  • Well-defined quantitative and qualitative growth scales
  • Identification of resource bottlenecks and requirements
  • Careful, accurate capacity planning
  • Scalable handling of traffic
  • The scaling of dependencies
  • Scalable data storage

Fault Tolerance and Catastrophe-Preparedness

  • Potential catastrophes and failure scenarios are identified and planned for.
  • Single points of failure are identified and resolved.
  • Failure detection and remediation strategies are in place.
  • It is tested for resiliency through code testing, load testing, and chaos testing.
  • Traffic is managed carefully in preparation for failure.
  • Incidents and outages are handled appropriately and productive.


  • Appropriate service-level agreements (SLAs) for availability.
  • Proper task handling and processing.
  • Efficient utilization of resources.


  • Proper logging and tracing throughout the stack.
  • Well-designed dashboards that are easy to understand and accurately reflect the health of the service.
  • Effective, actionable alerting accompanied by run books.
  • Implementing and maintaining an on-call rotation.


Documentation is the biggest challenge while developing software, at least in the projects I got involved with. There are at least three reasons for that, the first being the constant change of a feature, the second is due the lack of awareness of the team that documentation is important to keep everyone on the team on the same page, and lastly but not least it is the excuse: “it doesn’t matter”.

[4] defined the following bullet list to keep an eye for building documentation.

  • Thorough, updated, and centralized documentation containing all of the relevant and essential information about the microservice.
  • Organizational understanding at the developer, team, and ecosystem levels.

Edit: Oct 10, 2021

Added reference to Istio case study in the microservices section.

Edit: Nov 07, 2021

Another book that is related to microservices and touches in databases for microservices is the book from Edson Yanaga, which I think would be a extension from Susan.


  1. [1]P. Jamshidi, C. Pahl, N. C. Mendonça, J. Lewis, and S. Tilkov, “Microservices: The journey so far and challenges ahead,” IEEE Software, vol. 35, no. 3, pp. 24–35, 2018.
  2. [2]E. Yanaga, Migrating to Microservice Databases: From Relational Monolith to Distributed Data. O’Reilly Media, 2017.
  3. [3]N. C. Mendonça, C. Box, C. Manolache, and L. Ryan, “The Monolith Strikes Back: Why Istio Migrated From Microservices to a Monolithic Architecture,” 2021 [Online]. Available at: [Accessed: 10-Oct-2021]
  4. [4]S. Fowler, Production-Ready Microservices: Building Standardized Systems Across an Engineering Organization. O’Reilly Media, 2016.
  5. [5]S. Newman, Monolith to Microservices: Sustaining Productivity While Detangling the System. O’Reilly Media, 2019.