What is the Microservice Chassis pattern?
A chassis is a framework, or a set of libraries on top of one, that every service in a stack uses. It sets up structured logging, metrics, trace propagation, health endpoints, configuration loading, token verification and error responses in the agreed format. A team adds the chassis and gets all of these working the same way as in every other service. Each language needs its own chassis, built to the same contracts.
What problem does the Microservice Chassis pattern solve?
Every service needs the same plumbing, and solving it again in each one wastes time and produces services that log, trace and fail in different ways. That makes incidents slower to investigate, because nothing lines up across services. One chassis per stack builds the plumbing once and keeps it consistent.
How do you implement the Microservice Chassis pattern?
- Agree the contracts first: log format, trace headers, metric names, health endpoints and the error model.
- Build one chassis per blessed language, usually on top of an existing framework, that implements those contracts.
- Keep it thin and stable. Business logic and domain models never go into the chassis.
- Version it, release it with a changelog, and keep upgrades easy enough that teams do them.
- Ship it inside the service template, so new services start with it.
When should you use it?
- You have more than a handful of services in the same language.
- Incidents are slowed down because services log, trace or report errors in different ways.
When should you avoid it?
- Services are written in many languages and a service mesh can handle most network concerns outside the code.
- You have one or two services. A framework's defaults are enough.
What do you gain?
- Teams write business logic, not plumbing
- Logs, metrics and traces line up across services
- One place to fix a security issue in shared code
What does it cost?
- One chassis per language to build and maintain
- A bug in it affects every service
- Upgrades must be rolled out across all services
Who usually owns the Microservice Chassis pattern?
Platform team. A platform team builds and runs this once, as a self-service product that every product team uses without rebuilding it. See how teams map to layers and patterns.
What are common mistakes with the Microservice Chassis pattern?
- Shared domain models or business rules in the chassis, coupling every service to every change.
- A chassis that changes often, so teams fall several versions behind.
- Forcing the chassis on a stack it was not built for instead of building a second one to the same contracts.
Microservice Chassis in practice
Twitter needed a common way to build high-concurrency servers and clients on the JVM that speak several different protocols.
Twitter's infrastructure team maintains Finagle, an extensible RPC system for the JVM that it open-sourced. Finagle offers uniform client and server APIs across several protocols, and most of its code is protocol-agnostic. Its clients and servers expose statistics for monitoring and can be traced in the style of Google's Dapper, with Twitter's Zipkin collecting the traces.
Sources: Finagle (Twitter, GitHub Pages); Finagle User's Guide
Example decision record
- Context
- Services log, trace and report errors in different ways, which slows down every incident.
- Decision
- Build a thin chassis per blessed language that implements the agreed logging, tracing, metrics, health and error contracts.
- Consequences
- Telemetry lines up across services.
- Each chassis must be kept stable, versioned and free of business logic.
Test yourself on Microservice Chassis
During an incident, engineers find that 40 Java services log in five different formats and three of them do not pass trace headers on, so traces stop halfway. What fixes this for good?
3 questions involve this pattern. Practice all of them →
Saved in this browser only. See your progress →