Skip to content
Architect's Handbook Wiki

Cross-cutting concerns for microservices

Pattern ¡ Chapter 9

Cross-cutting concerns for microservices

Section titled “Cross-cutting concerns for microservices”

In a monolith, a cross-cutting concern is built once and reused everywhere. In a microservice architecture, each service is independently deployable and self-contained, so a naive approach re-implements every concern in every service — prohibitively expensive when a system has hundreds of services and new ones are created constantly. Two patterns address this.

Microservice chassis

Section titled “Microservice chassis”

A framework that provides cross-cutting concerns for all microservices, so creating a new service stays fast and the team can focus on core concerns.

  • Common concerns a chassis handles: logging, externalized configuration, metric reporting/instrumentation, service registration and discovery, health checks, tracing.
  • Examples: Spring Cloud, Microdot, Gizmo, Go kit, Dropwizard.
  • Doesn’t have to be open-source/third-party — an in-house framework tailored to your stack works too. The point is a reusable framework so concerns aren’t implemented repeatedly.

Sidecar pattern

Section titled “Sidecar pattern”

Microservices allow polyglot development (multiple languages, runtimes, frameworks, datastores). That makes maintaining a cross-cutting library per language a duplication and maintainability problem. The sidecar pattern solves it.

  • Cross-cutting logic runs in its own process/container (a sidecar / sidekick container) attached to the primary application and running alongside it — like a motorcycle sidecar.
  • The sidecar’s language/framework can differ from the primary app’s, so you don’t re-implement each concern per language in a heterogeneous environment.
  • Primary and sidecar share the same resources (e.g. a health-monitoring sidecar can watch the primary’s system resources).
  • Useful when the sidecar is owned by another team/organization — you can still use it without controlling its implementation.
  • IPC between the two should use a language- and framework-agnostic mechanism. Communication is fast (same host) but carries overhead vs. in-process calls; a chatty, fine-grained interface where performance is critical makes the sidecar a poor fit.

Citations

Section titled “Citations”
  • Software Architect’s Handbook (Packt, 2018), Ch.9 “Cross-cutting concerns for microservices”, pp. 727-731.