Cross-cutting concerns for microservices

Pattern · Chapter 9

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

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

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

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