Building Microservices: Designing Fine-Grained Systems by Sam Newman Summary

1. Model microservices around business domains not technical boundaries for clarity.
2. Architects act as town planners focusing on service integration over internal details.
3. Prioritize independent deployability to enable rapid iteration and reduce system downtime.
4. Choose eventual consistency over distributed transactions for scalable data management.
5. Align cross-functional teams with business capabilities to enhance ownership and agility.
6. Embrace polyglot persistence by allowing each service to manage its own database.
7. Implement consumer-driven contracts to maintain stable service interfaces during evolution.
8. Balance standardization with innovation through evolutionary architecture principles.
9. Split monoliths incrementally using strangler pattern while maintaining system functionality.
10. Design for failure with circuit breakers and bulkheads in distributed systems.
11. Prefer asynchronous event-driven communication for resilient service interactions.
12. Shift testing left using contracts and chaos engineering for reliability.

À propos de l'auteur de Building Microservices

Sam Newman is the author of Building Microservices and a leading authority on cloud-native architecture and continuous delivery. A seasoned independent consultant with over two decades in software development, Newman specializes in designing scalable microservice systems, evolution strategies for legacy applications, and developer-centric workflows.

His seminal work, Building Microservices, provides a foundational guide to distributed systems design, emphasizing practical patterns for decomposition, testing, and deployment in DevOps environments.

Newman’s expertise stems from 12 years at Thoughtworks, where he contributed to early agile methodologies and co-created tools like the Lego XP Game for teaching Agile principles. His follow-up book, Monolith to Microservices, explores migration tactics like the strangler fig pattern and parallel run deployments.

A frequent speaker at tech conferences, Newman advocates for FaaS (Function-as-a-Service) adoption and modular runtime environments. His writings and talks are widely referenced in software engineering circles, with his O’Reilly-published books serving as essential resources for architects and developers navigating cloud-native transformations.

FAQ sur Building Microservices

What is Building Microservices by Sam Newman about?

Building Microservices provides a comprehensive guide to designing, managing, and scaling distributed systems using microservices. It covers splitting monolithic applications, data management, deployment strategies, communication styles, and monitoring. Sam Newman emphasizes principles like domain-driven design, independent service deployment, and team autonomy, offering practical advice for architects, developers, and IT operators navigating modern software architecture challenges.

Who should read Building Microservices?

This book is essential for software architects, developers, DevOps engineers, and tech leads involved in designing or transitioning to microservices. It’s also valuable for IT operators and testers seeking to understand deployment, monitoring, and resiliency in distributed systems. Newman’s clear examples make it accessible for both newcomers and experienced practitioners.

Is Building Microservices worth reading?

Yes, the 2nd edition is widely regarded as a definitive resource for microservices. It blends theoretical concepts with real-world case studies, updated for cloud-native technologies and modern practices like containerization. Readers praise its holistic approach to technical and organizational challenges, making it indispensable for anyone working with distributed systems.

What are the key principles of microservices according to Sam Newman?

Newman highlights three core principles:

• Independently deployable services (no orchestrated deployments).
• Domain-driven design to align services with business capabilities.
• Encapsulated data ownership, treating services as abstractions over private state.

These principles enable scalability, team autonomy, and faster iteration.

How does Building Microservices address data management in distributed systems?

The book advocates treating services as data abstractions, emphasizing strategies like:

• Decentralized data ownership to avoid shared databases.
• Event sourcing and sagas for consistency.
• Aggregated reporting solutions.

Newman warns against tight data coupling and provides patterns to manage transactions across services.

What deployment strategies are recommended in Building Microservices?

Newman stresses continuous integration, containerization, and automated deployment pipelines to enable independent releases. He also covers monitoring, logging, and resiliency techniques like circuit breakers. The book critiques centralized orchestration, arguing it undermines microservices’ autonomy benefits.

How does Conway’s Law relate to microservices in the book?

Newman dedicates a chapter to Conway’s Law, explaining how organizational structure impacts system design. He advises aligning team boundaries with service boundaries to reduce friction, advocating for small, cross-functional teams that own full service lifecycles.

What are the criticisms of microservices discussed in the book?

While promoting microservices’ benefits, Newman acknowledges trade-offs:

• Increased complexity in debugging and monitoring.
• Organizational challenges in team coordination.
• Potential over-engineering for smaller systems.

He advises evaluating microservices against monoliths for each use case.

How does the 2nd edition differ from the first edition of Building Microservices?

The 2nd edition adds content on cloud-native technologies, security, and resiliency patterns. It refines definitions (e.g., “independently releasable services”) and includes newer case studies. Newman also expands discussions on communication styles, deployment principles, and team dynamics.

What communication styles are covered in Building Microservices?

The book compares synchronous (REST, gRPC) and asynchronous (message queues, event-driven) communication. Newman advises favoring event-driven collaboration for loose coupling and scalability, while warning against over-reliance on synchronous APIs that create brittle dependencies.

How does the book guide splitting a monolithic application?

Newman outlines incremental decomposition strategies:

• Identify bounded contexts using domain-driven design.
• Prioritize splitting modules with divergent scalability or volatility needs.
• Use the Strangler Fig Pattern to gradually replace monolith components.

He also details techniques to manage shared databases during transitions.

Why is team autonomy important in microservices according to Newman?

Autonomy allows teams to deploy services independently, accelerating delivery cycles. Newman argues that centralized governance or deployment coordination negates microservices’ core advantages, advocating for decentralized decision-making aligned with service ownership.