The Tao of Microservices
Richard Rodger
  • MEAP began February 2016
  • Publication in November 2017 (estimated)
  • ISBN 9781617293146
  • 275 pages (estimated)
  • printed in black & white

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 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.

"Very engaging and thought-provoking."

~ Lukasz Sowa

"The book is excellent on the explaining the concepts from a different angle."

~ anonymous reviewer

"The author has practical experience as well as great understanding of the concepts - a rare combination!"

~ Sujith Pillai

Table of Contents detailed table of contents

Part 1: Microservices as Software Engineering

1. Brave New World

1.1. The technical debt crisis

1.2. Case Study: a microblogging startup

1.2.1. Iteration 0: Posting entries

1.2.2. Iteration 1: A search index

1.2.3. Iteration 2: Simple composition

1.2.4. Iteration 3: Timelines

1.2.5. Iteration 4: Scaling

1.3. How the monolith betrays the promise of components

1.4. The microservice idea

1.4.1. The core technical principles

1.5. Practical implications

1.5.1. Specification

1.5.2. Deployment

1.5.3. Security

1.5.4. People

1.6. What you get for your money

1.7. Summary

2. Services

2.1. Defining microservices

2.2. Study: the digital edition of a newspaper

2.2.1. The business goals

2.2.2. The informal requirements

2.2.3. A functional breakdown

2.2.4. Microservice architectures

2.2.5. The mini-web servers architecture

2.2.6. Diagrams for microservices

2.2.7. The microservice dependency tree

2.2.8. The aysnchronous message architecture

2.3. Monolithic projects versus microservice projects

2.3.1. How microservices change project management

2.3.2. Uniformity makes estimation easier

2.3.3. Disposable code makes for friendlier teams

2.3.4. Homogeneous components allow for heterogeneous configuration

2.3.5. There are different types of code

2.4. The unit of software

2.5. Study: requirements to messages to services

2.5.1. The messages of the newspaper site

2.6. Microservice architecture diagrams

2.6.1. Diagramming message flows

2.6.2. The four basic cases

2.7. Software components

2.7.1. Encapsulated

2.7.2. Reusable

2.7.3. Well-defined interfaces

2.7.4. Composable

2.7.5. Microservices in practice as components

2.8. The internal structure of a microservice

2.9. Summary

3. Messages

3.1. Messages are first class citizens

3.1.1. Synchronous and Asynchronous

3.1.2. When to go synchronous

3.1.3. When to go asynchronous

3.1.4. Think distributed from day one

3.1.5. Tactics to limit failure

3.2. Study: Sales tax rules

3.2.1. The wider context

3.3. Pattern matching

3.3.1. Sales tax: starting simple

3.3.2. Sales tax: handling categories

3.3.3. Sales tax: going global

3.3.4. Business requirements change, by definition

3.3.5. Pattern-matching lowers the cost of refactoring

3.4. Transport independence

3.4.1. A useful fiction: the omnipotent observer

3.5. Message patterns

3.5.1. Core patterns: 1 message / 2 services

3.5.2. Core patterns: 2 messages / 2 services

3.5.3. Core patterns: 1 message / n services

3.5.4. Core patterns: m messages / n services

3.5.5. m/n: chain

3.5.6. m/n: tree

3.5.7. Scaling messages

3.6. When messages go bad…​

3.6.1. The common failure scenarios, and what to do about them

3.6.2. Failures dominating the request/response interaction

3.6.3. Failures dominating the sidewinder interaction

3.6.4. Failures dominating the winner-take-all interaction

3.6.5. Failures dominating the fire-and-forget interaction

3.7. Summary

4. Data

4.1. Data does not mean what you think it means

4.1.1. Data is heterogeneous, not homogeneous

4.1.2. Data can be private

4.1.3. Data can be local

4.1.4. Data can be disposable

4.1.5. Data does not have to be accurate

4.2. Data strategies for microservices

4.2.1. Use messages to expose data

4.2.2. Use composition to manipulate data

4.2.3. Use system configuration to control data

4.2.4. Use weaker constraints to distribute data

4.3. The tyranny of the database

4.4. Rethinking traditional data patterns

4.4.1. Primary keys

4.4.2. Foreign keys

4.4.3. TODO

4.4.4. Transactions aren't as good as you think they are

4.4.5. Schemas draw down technical debt

4.4.6. A practical decision guide for microservice data

4.5. Study: the data of the digital newspaper

4.5.1. User resolution

4.5.2. Article resolution

4.6. Summary

5. Deployment

5.1. Things fall apart

5.2. Learning from history

5.2.1. Three Mile Island

5.2.2. A model for failure in software systems

5.2.3. Redundancy doesn't do what you think it does

5.2.4. Change is scary

5.3. The centre cannot hold

5.3.1. The cost of perfect software

5.4. Anarchy works

5.5. Microservices and Redundancy

5.6. Continuous Delivery

5.6.1. Pipeline

5.6.2. Process

5.6.3. Protection

5.7. Running a microservice system

5.7.1. Immutability

5.7.2. Automation

5.7.3. Resilience

5.7.4. Validation

5.7.5. Discovery

5.7.6. Configuration

5.7.7. Security

5.7.8. Staging

5.7.9. Development

5.8. Summary

Part 2: Microservices as Computer Science

6. Measurement

6.1. The limits of traditional monitoring

6.1.1. Classical configurations

6.1.2. The problem with averages

6.1.3. Using percentiles

6.1.4. Microservice configurations

6.1.5. The power of scatter plots

6.1.6. Building a dashboard

6.2. Measurements for microservices

6.2.1. The business layer

6.2.2. The message layer

6.2.3. The service layer

6.3. The power of invariants

6.3.1. Finding invariants from the business logic

6.3.2. Finding invariants from the system architecture

6.3.3. Visualizing invariants

6.3.4. System discovery

6.3.5. Synthetic validation

6.4. Summary

7. Migration

7.1. Leaving the monolith behind

7.1.1. A classic ecommerce example

7.1.2. Changing the goal posts

7.1.3. Starting the journey

7.2. The strategy of refinement

7.2.1. Moving from the general to the specific

7.3. Summary

8. People

8.1. Dealing with institutional politics

8.1.1. Accepting hard constraints

8.1.2. Finding sponsors

8.1.3. Building alliances

8.1.4. Value-focused delivery

8.1.5. Acceptable error rates

8.1.6. Dropping features

8.1.7. Stop abstracting

8.1.8. De-programming

8.1.9. External validation

8.1.10. Team solidarity

8.1.11. Respect the organization

8.2. The politics of microservices

8.2.1. Who owns what?

8.2.2. Who's on-call?

8.2.3. Who decides what to code?

8.3. Summary

9. Case study:

9.1. Design

9.1.1. What are the business requirements?

9.1.2. What are the messages?

9.1.3. What are the services?

9.2. Deliver

9.2.1. Iteration 1: local development

9.2.2. Iteration 2: Testing, staging and risk measurement

9.2.3. Iteration 3: The path to production

9.2.4. Iteration 4: Enhancing and adapting

9.2.5. Iteration 5: Monitoring and debugging

9.2.6. Iteration 6: Scaling and performance

9.3. Brave New World

About the Technology

Microservices are small, but they offer big value. A microservice is a very small piece of a larger system that can be coded by one developer within one iteration. Microservices can be added and removed individually, new developers can be immediately productive, and legacy code is easily replaced. Developers are no longer hampered by the communication and coordination overhead caused by monolithic systems. Savvy businesses are discovering that software development productivity can be greatly enhanced with the right engineering approach that enables even junior developers to double their productivity, while reducing delivery risk.

What's inside

  • Key principles of the microservice architecture
  • Applying these principles to real-world projects
  • Implementing large-scale systems
  • Detailed case study

About the reader

This book is for developers, architects, or managers who want to deliver faster, meet changing business requirements, and build scalable and robust systems.

About the author

Richard Rodger is the the co-founder and CTO of a leading global Node.js consultancy and has experience building microservice-based systems for major companies. He regularly speaks and writes on Node.js and microservices.

Manning Early Access Program (MEAP) Read chapters as they are written, get the finished eBook as soon as it’s ready, and receive the pBook long before it's in bookstores.
MEAP combo $49.99 pBook + eBook + liveBook
MEAP eBook $39.99 pdf + ePub + kindle + liveBook

FREE domestic shipping on three or more pBooks