Principles Of Microservices by Sam Newman

High-level summary

Speaker: Sam Newman (ThoughtWorks), author of Building Microservices.

Talk focus: practical principles, patterns and pitfalls for designing, operating and evolving microservice architectures. Emphasis on trade-offs: the benefits of autonomy and faster evolution versus the extra complexity introduced by distribution.

Eight core principles

1. Model services around the business domain

   • Prefer vertical slicing (bounded contexts, subdomains) over horizontal technical layers.
   • Domain-driven design helps identify service boundaries that yield more stable APIs and domain-expert teams.
   • Avoid “presentation/service/data” horizontal splits that cause cross-cutting changes.
   • Be careful what you share across bounded contexts (for example, “customer” can mean different things); avoid leaking internal models.

2. Embrace a culture of automation

   • Infrastructure as code, easy provisioning of isolated environments, and CI/CD treating every check-in as a release candidate.
   • Organizations must invest upfront in platform and tooling to reduce the transaction costs of many services (examples: REA, Gilt).
   • Automation enables scaling the number of deployable units safely.

3. Hide implementation details

   • Never let other services read your database schema directly — expose APIs or messages instead.
   • Make API boundaries explicit so each service can evolve internals safely.

4. Decentralize (teams and architecture)

   • Push decision-making and self-service to teams: provisioning, deployments, ownership.
   • Use light-weight collective governance (communities of practice), not a central gatekeeper.
   • Keep middleware dumb: message brokers and API gateways should be pipes, not domain-aware brains (avoid recreating an ESB).

5. Deploy independently (the golden rule)

   • Aim to change and deploy a service without changing others.
   • Prefer one service per isolated host/container for simplicity (helps avoid noisy neighbors).
   • Validation techniques: consumer-driven contracts (Pact + Pact Broker) — consumers publish expectations; providers validate them in CI to avoid breaking consumers.
   • Versioning strategies for breaking changes: coexist endpoints (v1/v2) or run multiple service versions; retire old versions once unused.

6. Consumer-first (APIs are UIs)

   • Design APIs with consumers in mind: good docs, examples, discoverability.
   • Use Swagger/OpenAPI and interactive UIs so consumers can explore and test endpoints.
   • Provide a “humane registry” (wiki + runtime info) for developers: who to contact, where it runs, runtime stats.

7. Isolate failure (resilience patterns)

   • Distribution increases the failure surface area; systems must explicitly handle network/timeouts/partial failures.
   • Key patterns:
     • Short, sensible timeouts (avoid long waits).
     • Bulkheads: isolate resources per downstream dependency (e.g., thread pool per downstream).
     • Circuit breakers: fail fast and allow downstream recovery; useful for near-zero downtime deployments.
     • Strangler pattern for gradual migrations (proxying to old/new implementations).
   • Recommended reading: Release It! by Mike Nygard.

8. Make systems highly observable

   • Aggregate logs (ELK, Splunk, Papertrail, Sumo Logic) and metrics (Graphite/Prometheus, New Relic) centrally.
   • Use correlation IDs / distributed tracing (Zipkin, custom correlation in logs) so a single request’s path can be reconstructed.
   • Visualize service interactions dynamically (draw maps from correlation IDs) for human-friendly understanding.

Tools, patterns and concrete recommendations

• API documentation: Swagger / OpenAPI (use Swagger UI for exploring).
• Contract testing: Pact and Pact Broker (consumer-driven contracts).
• Tracing / correlation: Zipkin, correlation ID conventions.
• Logging / aggregation: Splunk, ELK stack, Papertrail, Sumo Logic.
• Metrics / time-series: Graphite, Prometheus, New Relic, AppDynamics.
• Circuit breaker libraries: Hystrix-style libraries for Java; Polly and Brighter for .NET.
• Containers: Docker (lowers cost of isolated OS environments; one-service-per-container fits the one-service-per-host model).
• Design patterns: Strangler, bulkhead, circuit breaker, backends-for-frontends (BFF) for differing UI needs (web vs mobile); expand-contract/versioning/coexist endpoints.
• Books & references: Building Microservices (Sam Newman); Release It! (Mike Nygard); Martin Fowler on bounded contexts; Heroku 12-factor app.

Operational and organizational notes

• Microservices buy you options; this requires principles to avoid fragmentation and inconsistency.
• Governance should align with company goals — principles change slowly; practices change frequently.
• Real-world growth patterns: initial slow service count until platform investment spikes the number of services — plan platform work early.
• UI integration approaches:
  • Server-side web pages: services serve page fragments with a thin aggregator.
  • SPA / mobile: SPAs may call services directly; mobile clients are better served by BFFs to consolidate calls and reduce latency/bandwidth/battery costs.

Where to learn more / resources

• Sam Newman — Building Microservices (book and website: BuildingMicroservices.com).
• Mike Nygard — Release It!
• Tools and projects referenced above: Pact, Pact Broker, Zipkin, ELK, Prometheus, Swagger/OpenAPI, etc.
• Heroku 12-factor app for operational/deployment principles.
• Sam Newman on Twitter: @samnewman.

Main speaker and sources referenced

• Main speaker: Sam Newman (ThoughtWorks), author of Building Microservices.
• Other referenced people/works: James Lewis, Evan Butcher, Martin Fowler, Mike Nygard (Release It!), Heroku 12-factor.
• Companies cited as examples: REA (Australia), Gilt.
• General references: Docker, API gateway trends.