Summary of "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

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.
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.
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.
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).
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.
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.
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.
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.