The Tao of Microservices
Richard Rodger
  • MEAP began February 2016
  • Publication in Summer 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 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.
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. How the monolith betrays the promise of components

1.3. The microservice idea

1.3.1. The core technical principles

1.4. Practical implications

1.4.1. Specification

1.4.2. Deployment

1.4.3. Security

1.4.4. People

1.5. Study: a microblogging startup

1.5.1. Iteration 0: Posting entries

1.5.2. Iteration 1: A search index

1.5.3. Iteration 2: Simple composition

1.5.4. Iteration 3: Timelines

1.5.5. Iteration 4: Scaling

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. One database to rule them all

4.2. The tyranny of the database

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

4.2.2. Schemas draw down technical debt

4.3. Data does not mean what you think it means

4.3.1. Data is heterogeneous, not homogeneous

4.3.2. Data can be private

4.3.3. Data can be local

4.3.4. Data can be disposable

4.3.5. Data does not have to be accurate

4.4. Data strategies for microservices

4.4.1. Use messages to expose data

4.4.2. Use composition to manipulate data

4.4.3. Use system configuration to control data

4.4.4. Use weaker constraints to distribute data

4.5. Rethinking traditional data patterns

4.5.1. Primary keys

4.5.2. Foreign keys

4.5.3. A practical decision guide for microservice data

4.6. Study: the data of the digital newspaper

4.6.1. User resolution

4.6.2. Article resolution

4.7. 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. Current State of Microservices

7. People

7.1. Moving to microservices

7.1.1. Leaving the monolith behind

7.1.2. A classic ecommerce example

7.1.3. Changing the goal posts

7.1.4. Starting the journey

7.2. The strategy of refinement

7.2.1. Moving from the general to the specific

7.3. Dealing with institutional politics

7.3.1. Accepting hard constraints

7.3.2. Finding sponsors

7.3.3. Building alliances

7.3.4. Value-focused delivery

7.3.5. Acceptable error rates

7.3.6. Dropping features

7.3.7. Stop abstracting

7.3.8. De-programming

7.3.9. External validation

7.3.10. Team solidarity

7.3.11. Respect the organization

7.4. The politics of microservices

7.4.1. Who owns what?

7.4.2. Who's on-call?

7.4.3. Who decides what to code?

7.5. Summary

8. Measurement

9. Specification

10. Case Study: Nodezoo

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.
Buy
MEAP combo $49.99 pBook + eBook
MEAP eBook $39.99 pdf + ePub + kindle

FREE domestic shipping on three or more pBooks