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.

Создание микросервисов

Проектирование мелкозернистых систем

Сэм Ньюмен

4.22(5129 Reviews)

Обзор книги Создание микросервисов

Книга Сэма Ньюмена «Создание микросервисов» произвела революцию в архитектуре программного обеспечения, изменив то, как технологические гиганты, такие как Netflix и Amazon, строят свои системы. Эта «библия индустрии» спровоцировала архитектурный переход от монолитов к микросервисам — секретному оружию самых масштабируемых и отказоустойчивых цифровых платформ современности.

Выберите способ повествования

Одна книга. Множество способов её услышать.

Те же идеи из Создание микросервисов. Выберите подходящие вам голос, глубину и темп. Меняйте в любое время.

Глава 1

The Revolution of Microservices: Breaking Down the Monolith

When Sam Newman's "Building Microservices" first hit the shelves in 2015, it quickly became the bible of modern software architecture. What makes this book particularly fascinating is its timing-published right as companies like Netflix, Amazon, and Spotify were proving that breaking applications into smaller, independently deployable services could dramatically accelerate innovation. The book has influenced countless tech transformations, with executives at companies like IBM and Microsoft citing it as instrumental in their architectural thinking. Even Jeff Bezos reportedly keeps a copy in his office, a testament to how microservices have underpinned Amazon's ability to scale at unprecedented rates. Beyond tech circles, the book has seeped into business schools, where it's studied as a case of how technical architecture can create competitive advantage in the digital economy.

Глава 2

What Are Microservices? The Small Pieces That Build Mighty Systems

Microservices are independently releasable services modeled around business domains. Think of them as black boxes that hide their internal workings while exposing functionality through network endpoints like REST APIs or message queues. The key is information hiding-services can change their internal implementation without affecting consumers, creating systems with looser coupling and stronger cohesion. The most important characteristic of microservices isn't their size but their independent deployability. This means you can make changes to one service, deploy it, and release it to users without touching any other part of the system. This isn't just theoretical-it's a discipline that guides how you establish service boundaries and design interfaces. By structuring services around business domains rather than technical layers, microservices make implementing new functionality easier. Traditional architectures often require changes across multiple layers for a single feature, while microservices create end-to-end slices of business functionality. Consider an e-commerce platform: rather than having separate database, business logic, and UI layers that all need modification to add a new product feature, you might have a self-contained "Product" microservice that handles everything related to products. Microservices should own their state-they shouldn't share databases. If one service needs data from another, it should request it directly. This creates clear boundaries between services and allows each to control what's shared versus hidden. It's like the difference between asking a colleague for information versus rummaging through their desk drawers without permission. The "micro" in microservices is actually misleading. Size is one of the least interesting aspects of this architecture. Instead of obsessing over lines of code, focus on having small interfaces that hide implementation details. A better question than "How big should a microservice be?" is "How many services can you effectively manage?" and "How should you define boundaries to prevent coupling?"

Следите за каждым словом во время прослушивания

Читайте вместе с аудио: каждое слово из Создание микросервисов подсвечивается в реальном времени.

Глава 3

The Monolith: Understanding What We're Moving From

Before diving deeper into microservices, we need to understand what we're moving away from. Monoliths are primarily defined as units of deployment where all functionality must be deployed together. This architectural pattern has been the backbone of software development for decades, offering simplicity and straightforward deployment processes. The most common type is the single-process monolith, where all code deploys as one process. While you might have multiple instances for robustness or scaling, fundamentally all code packages into one unit. These aren't necessarily bad-many successful systems are monoliths, including major platforms like Etsy's early architecture and Basecamp. The single-process approach offers advantages in debugging, monitoring, and maintaining consistency across the entire application. Development teams can easily trace execution paths, share common libraries, and maintain a unified deployment strategy. A modular monolith divides a single process into separate modules that can be worked on independently but must be combined for deployment. Companies like Shopify have successfully used this approach instead of microservices, demonstrating that well-structured monoliths can scale effectively. This architecture enables teams to work independently within their modules while maintaining the simplicity of single-deployment units. One significant challenge is that databases often lack the same decomposition as the code, creating difficulties if you later want to break apart the monolith. Teams frequently struggle with database boundaries, shared tables, and maintaining data consistency across modules. The distributed monolith is the worst of both worlds-multiple services that must be deployed together as a single unit. These systems combine the disadvantages of distributed systems (network latency, complex debugging, potential failures) with those of monoliths (tight coupling, all-or-nothing deployments), without enough benefits of either approach. They typically emerge when insufficient focus is placed on information hiding and cohesion, often resulting from premature or poorly planned service decomposition. Common symptoms include shared databases, synchronized deployments, and brittle integration tests. As more people work in the same codebase, delivery contention increases-developers want to change the same code, teams want to deploy at different times, and ownership becomes confused. This challenge becomes particularly acute in large organizations where multiple teams need to coordinate releases. While monoliths don't guarantee this problem and microservices don't eliminate it, microservice architecture provides clearer boundaries around which ownership lines can be drawn. These boundaries help teams establish clear responsibilities, independent deployment schedules, and autonomous decision-making within their service domains. Despite negative connotations, monolithic architecture should be considered a valid default choice, especially for new projects or smaller teams. Single-process and modular monoliths offer significant advantages through their simpler deployment topology, avoiding many distributed system pitfalls. They enable simpler developer workflows and streamline monitoring, troubleshooting, and end-to-end testing. Organizations should carefully evaluate their specific needs, team structure, and scaling requirements before moving away from a monolithic architecture, as the added complexity of distributed systems might not justify the benefits in many cases.

Глава 4

The Technology Enablers Behind Microservice Success

While adopting microservices doesn't necessarily require new technology initially, understanding the available tools is crucial for success. The increasing distribution of systems blurs the line between logical and physical architecture, creating new challenges that modern tooling helps address. Organizations must carefully evaluate their technology stack to ensure it supports their microservice journey effectively. Log aggregation systems are essential prerequisites for microservice adoption, collecting logs across services for centralized analysis. Imagine trying to troubleshoot an issue across dozens of services without being able to see their logs in one place-it would be nearly impossible. Tools like ELK Stack (Elasticsearch, Logstash, Kibana) and Splunk provide powerful search capabilities and visualization tools to make sense of distributed logs. Distributed tracing tools like Jaeger and Zipkin take this further by tracking requests as they flow through multiple services, helping identify bottlenecks and understand system behavior. These tools can reveal critical timing information and dependency patterns that would otherwise remain hidden. Containers provide lightweight isolation for microservice instances, ensuring issues in one service don't affect others. They enable faster spin-up times than traditional virtualization and make it possible to run many more services on the same hardware. Docker has become the standard container runtime, offering a consistent environment from development to production. As container usage grows, orchestration platforms like Kubernetes become necessary to manage distribution across machines. Kubernetes handles complex tasks like service discovery, load balancing, and automatic scaling, while tools like Istio add sophisticated service mesh capabilities for managing service-to-service communication. Streaming technologies like Apache Kafka facilitate necessary data sharing between services. As organizations move from monolithic databases toward real-time operations, Kafka's ability to handle large-scale data movement becomes invaluable. It offers message permanence, compaction, and high-volume scalability, making it the de facto choice for microservice environments. Event-driven architectures built on Kafka enable loose coupling between services and support patterns like Command Query Responsibility Segregation (CQRS) and Event Sourcing. Alternative messaging systems like RabbitMQ and Apache Pulsar offer different trade-offs for specific use cases. Public cloud providers offer managed services that can offload operational work as microservice architectures grow. AWS, Google Cloud, and Azure provide specialized tools for container orchestration, API management, and monitoring. Serverless products are particularly valuable as they abstract away underlying infrastructure. Function as a Service (FaaS) platforms like AWS Lambda and Azure Functions simplify deployment by handling on-demand instance provisioning automatically, eliminating concerns about server management. These platforms often integrate with other cloud services for authentication, storage, and monitoring, creating a comprehensive ecosystem for microservice deployment. Modern CI/CD pipelines are also crucial for managing microservice complexity. Tools like Jenkins, GitLab CI, and GitHub Actions enable automated testing and deployment of individual services. Infrastructure as Code (IaC) tools such as Terraform and Pulumi help manage the growing infrastructure needs of microservice architectures in a repeatable, version-controlled manner.

Получите больше от Создание микросервисов

Получайте новые идеи каждый день из более чем 100 000 уроков
Слова подсвечиваются синхронно с аудио
Ваша библиотека сохранена на всех устройствах

Глава 5

Why Choose Microservices? The Compelling Advantages

Microservices offer numerous benefits that make them attractive for many organizations, particularly those operating at scale or needing to evolve rapidly. Technology heterogeneity becomes possible with microservices. Different services can use different technology stacks, allowing teams to select the right tool for each specific job. Imagine being able to use Node.js for a user interface service where its asynchronous capabilities shine, while using Java for a complex calculation engine that benefits from its mature ecosystem. This flexibility permits optimizing performance-critical components and choosing data storage solutions that match specific data characteristics. Robustness improves as microservices create natural bulkheads that prevent failures from cascading throughout the system. Unlike monoliths where a single failure can bring down the entire application, microservice systems can handle component failures while continuing to function with degraded capabilities. Think of it like a ship with multiple compartments-damage to one section doesn't sink the entire vessel. Scaling becomes more precise and cost-effective. With microservices, you can target scaling exactly at the components that need it, rather than scaling an entire monolithic application. Companies like Gilt adopted microservices specifically for this benefit, evolving from a monolithic Rails application to over 450 microservices to handle traffic spikes. This approach allows running less demanding services on smaller hardware while dedicating resources to performance-constrained services. Deployment becomes easier and less risky. Microservices enable independent deployment of small changes without affecting the entire system. When problems occur, they can be quickly isolated to specific services, making rollback straightforward. This capability to rapidly deliver new functionality is a primary motivation for companies like Amazon and Netflix adopting microservice architectures. Organizational alignment improves as microservices allow better matching between architecture and team structure. They enable changing ownership of services as the organization changes, maintaining alignment between architecture and organization over time. This helps hit the sweet spot of team size and productivity-small enough to communicate effectively but large enough to get meaningful work done.

Глава 6

The Real Challenges of Microservice Adoption

Despite their benefits, microservices introduce significant complexity that must be understood and managed. Most pain points stem from the challenges of distributed systems. Developer experience suffers as services multiply. Resource-intensive runtimes like the JVM limit how many microservices can run on a single developer machine. Rather than "developing in the cloud," which slows feedback cycles, limiting which parts of the system a developer needs to work on is often more practical. Technology overload is a real risk. While microservices give you options for using different languages, runtimes, and databases for each service, these are options, not requirements. It's crucial to balance technology diversity against its costs, introducing new tools gradually as needed rather than all at once. Reporting becomes more complex. With monoliths, stakeholders can run reports directly against a single database schema. Microservices break up this schema, scattering data across multiple logically isolated schemas while reporting needs remain. Solutions include streaming for real-time reporting or publishing data from microservices into central reporting databases. Monitoring and troubleshooting grow more challenging. Unlike monoliths with binary up/down states, microservice architectures require understanding the impact of single service instances failing or resource constraints. With tens or hundreds of processes, traditional monitoring approaches become inadequate. Security considerations change as more information flows over networks between services rather than within a single process. This increases vulnerability to observation in transit and man-in-the-middle attacks, requiring greater care in protecting data. Testing becomes more complex. The scope of end-to-end tests becomes extremely large with microservices, requiring tests across multiple deployed and configured services. Environmental issues like service failures or network timeouts create false negatives. As microservice architectures grow, end-to-end testing provides diminishing returns. Data consistency challenges emerge when moving from a monolithic database to distributed state management. Database transactions can't easily provide the same safety in distributed systems, and distributed transactions are highly problematic. Concepts like sagas and eventual consistency become necessary, requiring fundamental changes in how you think about data.

Следите за каждым словом во время прослушивания

Читайте вместе с аудио: каждое слово из Создание микросервисов подсвечивается в реальном времени.

Глава 7

Drawing Effective Service Boundaries

The fundamental goal of microservices is enabling independent change, deployment, and release of functionality. To achieve this, we need principles for defining appropriate boundaries. Information hiding involves concealing as many details as possible behind a service boundary. This delivers three key benefits: improved development time through parallel work, better comprehensibility of isolated components, and increased flexibility for independent changes. By minimizing assumptions between services, we reduce connections between them, making it easier to change one without impacting others. Cohesion can be summarized as "the code that changes together, stays together." For microservices, this means grouping functionality so changes can be made in as few places as possible. If we must change behavior in multiple places, we'll need to release multiple services simultaneously-a slower, riskier process. Strong cohesion means related functionality is consolidated; weak cohesion means it's scattered throughout the system. Coupling describes how much services depend on each other. Loosely coupled services can change without requiring changes to other services-a fundamental microservice principle. Tight coupling often results from integration styles that bind services together, forcing consumer changes when internal service details change. A loosely coupled service knows minimal information about its collaborators. Domain-driven design provides valuable tools for creating service boundaries. The concept of bounded contexts helps identify natural boundaries in your business domain. A bounded context represents an organizational boundary with explicit responsibilities-like the warehouse managing shipping and inventory, while finance handles payroll and payments. Aggregates represent real domain concepts with identity, state, and lifecycle-like an Order, Invoice, or Stock Item. A single microservice should manage one or more aggregates, controlling their lifecycle and data storage. When starting out, target services that encompass entire bounded contexts to reduce complexity. Event Storming is a collaborative technique to surface domain models by bringing technical and non-technical stakeholders together. The process identifies domain events (important facts like "Order Placed"), commands that trigger events, aggregates around which events cluster, and bounded contexts that group related aggregates.

Глава 8

Communication Patterns Between Microservices

Inter-process communication between microservices differs fundamentally from in-process calls. Network calls introduce significant performance overhead, requiring data serialization, deserialization, and network latency management. They also face more complex error handling scenarios including timeouts, partial failures, and network partitions. Understanding different communication styles is crucial before selecting specific technologies, as each pattern brings its own tradeoffs in terms of reliability, scalability, and complexity. Synchronous blocking calls occur when a microservice sends a request to another service and waits until receiving a response before continuing execution. This pattern mirrors traditional function calls, making it familiar to developers and conceptually simple to implement and debug. Common examples include REST API calls, gRPC requests, and direct HTTP interactions. While familiar, this approach creates temporal coupling-the downstream service must be available for the call to succeed. The main disadvantage is vulnerability to cascading failures, as delays or outages in downstream services directly impact upstream callers. For instance, if a product service depends synchronously on an inventory service, any inventory service degradation immediately affects product functionality. Asynchronous non-blocking communication allows microservices to continue processing after making calls without waiting for responses. This pattern comes in several forms: Communication Through Common Data (sharing information via databases, caches, or message queues), Request-Response (requesting operations but not blocking, using callbacks or future/promise patterns), and Event-Driven Interaction (broadcasting events that others can consume). The key advantage is temporal decoupling-services don't need to be simultaneously available. For example, an order processing service can continue accepting orders even if the notification service is temporarily down. Event-driven communication represents a paradigm shift from request-response: instead of explicitly asking another service to do something, a microservice simply emits events that may or may not be received by others. Events might include "OrderCreated," "PaymentProcessed," or "InventoryUpdated." This inherently asynchronous approach means the event emitter has no knowledge of-or interest in-how others might use the event. This inverts responsibility compared to request-response models, pushing decision-making into the receiving services and creating looser coupling. For instance, a payment service might emit a "PaymentReceived" event, leaving it up to order, shipping, and notification services to react appropriately. When designing events, a key decision is how much information to include in the event payload. Including comprehensive information (like full order details in an OrderCreated event) allows consumers to operate independently without additional service calls. This reduces coupling and provides an audit trail of entity changes, enabling event sourcing patterns and reliable system reconstruction. While message size can be a concern, modern message brokers like Apache Kafka, RabbitMQ, or AWS SNS/SQS handle messages up to 1MB or more, providing ample capacity for most use cases. Some systems use a hybrid approach, including essential data in events while providing links to fetch additional details if needed. Security considerations also influence communication patterns. Synchronous calls typically use point-to-point security measures like mutual TLS, while asynchronous patterns might require message-level encryption or digital signatures. Teams must balance security requirements with performance and complexity when choosing communication patterns.

Получите больше от Создание микросервисов

Получайте новые идеи каждый день из более чем 100 000 уроков
Слова подсвечиваются синхронно с аудио
Ваша библиотека сохранена на всех устройствах

Глава 9

Implementing Workflows Across Multiple Services

When making multiple changes as part of a single operation across services, we need mechanisms to ensure all changes complete successfully or none at all. Traditional database transactions handle this elegantly in monolithic systems through ACID properties, but microservices present new challenges for maintaining data consistency across service boundaries. For example, an e-commerce order might involve updating inventory, charging payment, and creating shipping labels across different services. Two-phase commits attempt to provide transactional guarantees in distributed systems through a voting phase and commit phase. During the voting phase, all participants must indicate readiness to commit, while the commit phase finalizes the changes. However, this approach loses isolation guarantees as changes may occur at different times across services, and coordinating distributed locks introduces significant complexity and potential deadlock scenarios. Consider a scenario where Service A holds a lock waiting for Service B, while Service B is simultaneously waiting for Service A - creating a deadlock. Performance also suffers as services must maintain locks throughout the entire coordination process. For these reasons, distributed transactions should generally be avoided in microservice architectures. Sagas provide a better alternative by coordinating multiple state changes without locking resources for long periods. They break down business processes into discrete, independently executable activities, each with its own compensating action to undo changes if needed. For instance, in an airline booking saga, reserving a seat, charging payment, and scheduling crew would be separate steps, each with corresponding compensation actions like releasing the seat or refunding payment. Unlike distributed transactions, sagas don't provide ACID atomicity-each subtransaction may be atomic, but the saga itself isn't. This means we need explicit mechanisms to track saga state, typically through event logging or state machines. When implementing sagas, we can choose between two styles: orchestrated sagas use centralized coordination and tracking, while choreographed sagas use a more loosely coupled model without central coordination. Orchestrated sagas employ a central coordinator that defines execution order and triggers compensating actions when needed. This approach provides clear visibility into process state but can create a bottleneck. Choreographed sagas distribute responsibility among multiple collaborating services using a trust-but-verify architecture where services react to events broadcast in the system. While more flexible, this approach can make it harder to track overall process state and debug issues. Explicitly modeling business processes as sagas avoids many distributed transaction challenges while making implicit processes more explicit and obvious to developers. Making core business processes first-class concepts brings numerous benefits to the system, including better visibility into process state, clearer failure handling through compensation actions, and improved ability to monitor and manage long-running operations. Teams can also more easily modify and extend processes when they're explicitly modeled rather than buried in service implementations. Best practices for saga implementation include maintaining idempotency for all operations, designing clear compensation actions, implementing robust error handling, and providing visibility into saga state through monitoring and logging. Teams should also consider saga patterns like routing slips or process managers to help manage complex workflows effectively.

Глава 10

Deployment Strategies for Microservice Success

Deploying microservices presents unique challenges compared to monolithic applications. Several core principles should guide your approach regardless of specific technology choices: isolated execution, focus on automation, infrastructure as code, zero-downtime deployment, and desired state management. Isolated execution means running microservice instances in isolation to maintain independent deployability. Each microservice should have its own isolated environment with ring-fenced resources. This prevents services from impacting each other through resource contention and simplifies monitoring and troubleshooting. Automation becomes essential as microservices multiply. Without it, operational complexity increases dramatically, requiring more and more people to manage services manually. Companies like RealEstate.com.au and Gilt demonstrate the power of automation-after initial investment in tooling, they experienced exponential growth in microservice deployment. Zero-downtime deployment is critical for truly independent deployability. Without this capability, microservice owners must coordinate releases with upstream consumers, undermining independence. Techniques like rolling upgrades, blue-green deployments, and canary releases make this possible. The deployment landscape offers numerous options, from physical machines to serverless functions. Containers have become the dominant choice for microservice architectures, offering a lightweight alternative to virtual machines for running isolated services. Kubernetes has emerged as the dominant container orchestration platform, handling how and where container workloads run across multiple machines. Function as a Service (FaaS) or "serverless" approaches are gaining popularity, especially for specific use cases. With FaaS, dormant code only runs when triggered by events, and the platform handles scaling and concurrency. This makes FaaS excellent for low or unpredictable workloads while providing implicit high availability. Progressive Delivery techniques allow controlled, phased rollouts rather than big-bang deployments. By separating deployment (installing software) from release (making it available to users), we can ensure software works in production without exposing users to failures. Techniques like feature toggles, canary releases, and parallel runs help minimize the "blast radius" of new deployments.

★★★★★

Вы дочитали Создание микросервисов до конца

Любимо более чем 1 млн учащихся

“Прошло 23 дня, и я пользуюсь приложением каждый день. Теперь оно стало частью моей повседневной жизни.”

jayallen

Ключевые темы в Создание микросервисов

distributed systems architecture
service decomposition
independent deployability
domain driven design
monolith migration

Цитаты из Создание микросервисов

The distributed monolith is the worst of both worlds.
Monolithic architecture should be considered a valid default choice.
The most important characteristic of microservices isn't their size but their independent deployability.
Size is one of the least interesting aspects of this architecture.

Персонажи в Создание микросервисов

Sam NewmanAuthor and expert on microservices architecture

Об авторе

Сэм Ньюмен — автор книги «Создание микросервисов» (Building Microservices) и ведущий эксперт в области облачной архитектуры и непрерывной доставки. Опытный независимый консультант с более чем двадцатилетним стажем в разработке программного обеспечения, Ньюмен специализируется на проектировании масштабируемых микросервисных систем, стратегиях эволюции устаревших приложений и рабочих процессах, ориентированных на разработчиков.

Его основополагающий труд, «Создание микросервисов», представляет собой базовое руководство по проектированию распределенных систем, в котором особое внимание уделяется практическим паттернам декомпозиции, тестирования и развертывания в средах DevOps.

Экспертиза Ньюмена сформировалась за 12 лет работы в Thoughtworks, где он внес вклад в ранние гибкие методологии и стал соавтором таких инструментов, как Lego XP Game для обучения принципам Agile. Его следующая книга, «От монолита к микросервисам» (Monolith to Microservices), исследует тактики миграции, такие как паттерн «душителя» (strangler fig) и параллельное развертывание.

Частый спикер на технологических конференциях, Ньюмен выступает за внедрение FaaS (Function-as-a-Service) и модульных сред выполнения. Его статьи и выступления широко цитируются в кругах инженеров программного обеспечения, а его книги, изданные O’Reilly, служат незаменимыми ресурсами для архитекторов и разработчиков, осуществляющих переход к облачным технологиям.

Скачать резюме книги «Создание микросервисов»

Получите резюме книги «Создание микросервисов» в формате PDF или EPUB бесплатно. Распечатайте или читайте офлайн в любое время.

Пользователям также понравилось

Production-Ready Microservices

Susan J. Fowler

Architecting for Scale

Lee Atchison

Clean Architecture

Robert C. Martin

Обложка книги System Design Evolution: From Monoliths to Microservices

14 sources

System Design Evolution: From Monoliths to Microservices

This is service design thinking

Marc Stickdorn and Jakob Schneider

Designing Data-Intensive Applications

Martin Kleppmann

The SaaS Playbook

Rob Walling

Getting Real: The smarter, faster, easier way to build a successful web application

Jason Fried and David Heinemeier Hansson

Часто задаваемые вопросы об этой книге

Узнать больше

ПЛАН ОБУЧЕНИЯ

Digital Transformation: Systems Over Software

This plan is essential for leaders and entrepreneurs who feel stuck in reactive cycles and want to build scalable operations. It bridges the gap between simply using digital tools and architecting a business that improves itself through systems thinking.

2 h•4 Разделы

ПЛАН ОБУЧЕНИЯ

The Diagnostic for Tool Enshittification

As software platforms increasingly prioritize monetization over utility, developers must learn to identify predatory technical patterns. This guide is essential for software architects and engineers who want to build resilient stacks and avoid becoming locked into decaying ecosystems.

1 h 30 m•3 Разделы

ПЛАН ОБУЧЕНИЯ

Fluxer: Deconstructing a Distributed Discord Clone

This plan is essential for developers looking to understand the mechanics of high-scale, real-time communication platforms. It benefits system architects and backend engineers eager to master polyglot microservices and media streaming infrastructure.

2 h•4 Разделы

ПЛАН ОБУЧЕНИЯ

aws lambda

As cloud computing shifts toward serverless models, mastering AWS Lambda is essential for modern backend developers. This plan is ideal for software engineers and architects looking to build scalable, cost-effective applications without managing infrastructure.

2 h 1 m•4 Разделы

ПЛАН ОБУЧЕНИЯ

Build Atomic JSON:API in .NET

This plan is essential for .NET developers building high-performance, standardized APIs that require complex data handling. It benefits backend engineers looking to implement the JSON:API spec and its powerful atomic operations extension for transactional consistency.

1 h 15 m•3 Разделы

ПЛАН ОБУЧЕНИЯ

Build Cross-Platform Library for Mobile & Web

Modern software requires seamless performance across diverse environments. This plan is essential for senior developers and architects looking to build unified codebases that serve mobile and web users simultaneously.

5 h 46 m•4 Разделы

ПЛАН ОБУЧЕНИЯ

Claude Code: Zero to Agentic Builder

This plan is essential for developers looking to move beyond simple chat interfaces into autonomous AI engineering. It benefits software engineers and tech leads who want to leverage agentic workflows to automate repetitive coding tasks and system integrations.

1 h 12 m•3 Разделы

ПЛАН ОБУЧЕНИЯ

How to build habits.

In an era of constant distraction, mastering behavior architecture is the ultimate competitive advantage. This plan is designed for professionals and individuals seeking to replace friction with flow by leveraging neuroscience and systematic design.

4 h 57 m•4 Разделы

Создано выпускниками Колумбийского университета в Сан-Франциско

LOVED BY

1,000,000+ curious minds.

4.7

avg rating

1M+ learners

"Instead of endless scrolling, I just hit play on BeFreed. It saves me so much time."

@Moemenn

"I never knew where to start with nonfiction—BeFreed’s book lists turned into podcasts gave me a clear path."

@Chloe, Solo founder, LA

117

"Perfect balance between learning and entertainment. Finished ‘Thinking, Fast and Slow’ on my commute this week."

@Raaaaaachelw

"Crazy how much I learned while walking the dog. BeFreed = small habits → big gains."

@Matt, YC alum

108

"Reading used to feel like a chore. Now it’s just part of my lifestyle."

@Erin, Investment Banking Associate , NYC

254

"Feels effortless compared to reading. I’ve finished 6 books this month already."

@djmikemoore

"BeFreed turned my guilty doomscrolling into something that feels productive and inspiring."

@Pitiful

4.5K

"BeFreed turned my commute into learning time. 20-min podcasts are perfect for finishing books I never had time for."

@SofiaP

"BeFreed replaced my podcast queue. Imagine Spotify for books — that’s it. 🙌"

@Jaded_Falcon

201

"It is great for me to learn something from the book without reading it."

@OojasSalunke

"The themed book list podcasts help me connect ideas across authors—like a guided audio journey."

@Leo, Law Student, UPenn

483

"Makes me feel smarter every time before going to work"

@Cashflowbubu

Узнайте больше о том, как обсуждают BeFreed в интернете

Создано выпускниками Колумбийского университета в Сан-Франциско

LOVED BY

1,000,000+ curious minds.

4.7

avg rating

1M+ learners

"Instead of endless scrolling, I just hit play on BeFreed. It saves me so much time."

@Moemenn

"I never knew where to start with nonfiction—BeFreed’s book lists turned into podcasts gave me a clear path."

@Chloe, Solo founder, LA

117

"Perfect balance between learning and entertainment. Finished ‘Thinking, Fast and Slow’ on my commute this week."

@Raaaaaachelw

"Crazy how much I learned while walking the dog. BeFreed = small habits → big gains."

@Matt, YC alum

108

"Reading used to feel like a chore. Now it’s just part of my lifestyle."

@Erin, Investment Banking Associate , NYC

254

"Feels effortless compared to reading. I’ve finished 6 books this month already."

@djmikemoore

"BeFreed turned my guilty doomscrolling into something that feels productive and inspiring."

@Pitiful

4.5K

"BeFreed turned my commute into learning time. 20-min podcasts are perfect for finishing books I never had time for."

@SofiaP

"BeFreed replaced my podcast queue. Imagine Spotify for books — that’s it. 🙌"

@Jaded_Falcon

201

"It is great for me to learn something from the book without reading it."

@OojasSalunke

"The themed book list podcasts help me connect ideas across authors—like a guided audio journey."

@Leo, Law Student, UPenn

483

"Makes me feel smarter every time before going to work"

@Cashflowbubu

"Instead of endless scrolling, I just hit play on BeFreed. It saves me so much time."

@Moemenn

"I never knew where to start with nonfiction—BeFreed’s book lists turned into podcasts gave me a clear path."

@Chloe, Solo founder, LA

117

"Perfect balance between learning and entertainment. Finished ‘Thinking, Fast and Slow’ on my commute this week."

@Raaaaaachelw

"Crazy how much I learned while walking the dog. BeFreed = small habits → big gains."

@Matt, YC alum

108

"Reading used to feel like a chore. Now it’s just part of my lifestyle."

@Erin, Investment Banking Associate , NYC

254

"Feels effortless compared to reading. I’ve finished 6 books this month already."

@djmikemoore

"BeFreed turned my guilty doomscrolling into something that feels productive and inspiring."

@Pitiful

4.5K

"BeFreed turned my commute into learning time. 20-min podcasts are perfect for finishing books I never had time for."

@SofiaP

"BeFreed replaced my podcast queue. Imagine Spotify for books — that’s it. 🙌"

@Jaded_Falcon

201

"It is great for me to learn something from the book without reading it."

@OojasSalunke

"The themed book list podcasts help me connect ideas across authors—like a guided audio journey."

@Leo, Law Student, UPenn

483

"Makes me feel smarter every time before going to work"

@Cashflowbubu

"Instead of endless scrolling, I just hit play on BeFreed. It saves me so much time."

@Moemenn

"I never knew where to start with nonfiction—BeFreed’s book lists turned into podcasts gave me a clear path."

@Chloe, Solo founder, LA

117

"Perfect balance between learning and entertainment. Finished ‘Thinking, Fast and Slow’ on my commute this week."

@Raaaaaachelw

"Crazy how much I learned while walking the dog. BeFreed = small habits → big gains."

@Matt, YC alum

108

"Reading used to feel like a chore. Now it’s just part of my lifestyle."

@Erin, Investment Banking Associate , NYC

254

"Feels effortless compared to reading. I’ve finished 6 books this month already."

@djmikemoore

"BeFreed turned my guilty doomscrolling into something that feels productive and inspiring."

@Pitiful

4.5K

"BeFreed turned my commute into learning time. 20-min podcasts are perfect for finishing books I never had time for."

@SofiaP

"BeFreed replaced my podcast queue. Imagine Spotify for books — that’s it. 🙌"

@Jaded_Falcon

201

"It is great for me to learn something from the book without reading it."

@OojasSalunke

"The themed book list podcasts help me connect ideas across authors—like a guided audio journey."

@Leo, Law Student, UPenn

483

"Makes me feel smarter every time before going to work"

@Cashflowbubu

Узнайте больше о том, как обсуждают BeFreed в интернете

Начните своё обучение прямо сейчас

Глава 8

Создание микросервисов

ОбзорОбзор книги Создание микросервисов

Одна книга. Множество способов её услышать.

The Revolution of Microservices: Breaking Down the Monolith

What Are Microservices? The Small Pieces That Build Mighty Systems

Следите за каждым словом во время прослушивания

The Monolith: Understanding What We're Moving From

The Technology Enablers Behind Microservice Success

Получите больше от Создание микросервисов

Why Choose Microservices? The Compelling Advantages

The Real Challenges of Microservice Adoption

Следите за каждым словом во время прослушивания

Drawing Effective Service Boundaries

Communication Patterns Between Microservices

Получите больше от Создание микросервисов

Implementing Workflows Across Multiple Services

Deployment Strategies for Microservice Success

Вы дочитали Создание микросервисов до конца

Ключевые темы в Создание микросервисов

Цитаты из Создание микросервисов

Персонажи в Создание микросервисов

Об авторе

Скачать резюме книги «Создание микросервисов»

Пользователям также понравилось

Часто задаваемые вопросы об этой книге

What is Building Microservices by Sam Newman about?

Who should read Building Microservices?

Is Building Microservices worth reading?

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

Узнать больше

1,000,000+ curious minds.

1,000,000+ curious minds.

Одна книга. Множество способов её услышать.

The Revolution of Microservices: Breaking Down the Monolith

What Are Microservices? The Small Pieces That Build Mighty Systems

Следите за каждым словом во время прослушивания

The Monolith: Understanding What We're Moving From

The Technology Enablers Behind Microservice Success

Получите больше от Создание микросервисов

Why Choose Microservices? The Compelling Advantages

The Real Challenges of Microservice Adoption

Следите за каждым словом во время прослушивания

Drawing Effective Service Boundaries

Communication Patterns Between Microservices

Получите больше от Создание микросервисов

Implementing Workflows Across Multiple Services

Deployment Strategies for Microservice Success

Вы дочитали Создание микросервисов до конца

Пользователям также понравилось

Узнать больше

Обзор книги Создание микросервисов