Muutke küpsiste eelistusi

Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith [Pehme köide]

4.29/5 (1749 hinnangut Goodreads-ist)
  • Formaat: Paperback / softback, 150 pages
  • Ilmumisaeg: 22-Nov-2019
  • Kirjastus: O'Reilly Media
  • ISBN-10: 1492047848
  • ISBN-13: 9781492047841
Teised raamatud teemal:
  • Pehme köide
  • Hind: 54,01 €*
  • * hind on lõplik, st. muud allahindlused enam ei rakendu
  • Tavahind: 63,54 €
  • Säästad 15%
  • Raamatu kohalejõudmiseks kirjastusest kulub orienteeruvalt 2-4 nädalat
  • Kogus:
  • Lisa ostukorvi
  • Tasuta tarne
  • Tellimisaeg 2-4 nädalat
  • Lisa soovinimekirja
Monolith to Microservices: Evolutionary Patterns to Transform Your MonolithSuurem pilt
  • Formaat: Paperback / softback, 150 pages
  • Ilmumisaeg: 22-Nov-2019
  • Kirjastus: O'Reilly Media
  • ISBN-10: 1492047848
  • ISBN-13: 9781492047841
Teised raamatud teemal:
Püsilink: https://www.kriso.ee/db/9781492047841.html
Märksõnad:

How do you detangle a monolithic system and migrate it to a microservices architecture? How do you do it while maintaining business-as-usual? As a companion to Sam Newman&;s extremely popular Building Microservices, this new book details a proven method for transitioning an existing monolithic system to a microservice architecture.

With many illustrative examples, insightful migration patterns, and a bevy of practical advice to transition your monolith enterprise into a microservice operation, this practical guide covers multiple scenarios and strategies for a successful migration, from initial planning all the way through application and database decomposition. You&;ll learn several tried and tested patterns and techniques that you can use as you migrate your existing architecture.

  • Ideal for organizations looking to transition to microservices, rather than rebuild
  • Helps companies determine whether to migrate, when to migrate, and where to begin
  • Addresses communication, integration, and the migration of legacy systems
  • Discusses multiple migration patterns and where they apply
  • Provides database migration examples, along with synchronization strategies
  • Explores application decomposition, including several architectural refactoring patterns
  • Delves into details of database decomposition, including the impact of breaking referential and transactional integrity, new failure modes, and more
Preface ix
1 Just Enough Microservices
1(32)
What Are Microservices?
1(11)
Independent Deployability
2(1)
Modeled Around a Business Domain
2(3)
Own Their Own Data
5(1)
What Advantages Can Microservices Bring?
6(1)
What Problems Do They Create?
6(1)
User Interfaces
7(1)
Technology
8(1)
Size
8(2)
And Ownership
10(2)
The Monolith
12(4)
The Single Process Monolith
12(2)
The Distributed Monolith
14(1)
Third-Party Black-Box Systems
14(1)
Challenges of Monoliths
15(1)
Advantages of Monoliths
15(1)
On Coupling and Cohesion
16(12)
Cohesion
17(1)
Coupling
17(11)
Just Enough Domain-Driven Design
28(4)
Aggregate
29(2)
Bounded Context
31(1)
Mapping Aggregates and Bounded Contexts to Microservices
31(1)
Further Reading
32(1)
Summary
32(1)
2 Planning a Migration
33(42)
Understanding the Goal
33(2)
Three Key Questions
35(1)
Why Might You Choose Microservices?
35(7)
Improve Team Autonomy
35(2)
Reduce Time to Market
37(1)
Scale Cost-Effectively for Load
37(1)
Improve Robustness
38(2)
Scale the Number of Developers
40(1)
Embrace New Technology
41(1)
When Might Microservices Be a Bad Idea?
42(3)
Unclear Domain
43(1)
Startups
43(1)
Customer-Installed and Managed Software
44(1)
Not Having a Good Reason!
45(1)
Trade-Offs
45(2)
Taking People on the Journey
47(1)
Changing Organizations
47(6)
Establishing a Sense of Urgency
48(1)
Creating the Guiding Coalition
48(1)
Developing a Vision and Strategy
49(1)
Communicating the Change Vision
50(1)
Empowering Employees for Broad-Based Action
51(1)
Generating Short-Term Wins
51(1)
Consolidating Gains and Producing More Change
52(1)
Anchoring New Approaches in the Culture
52(1)
Importance of Incremental Migration
53(1)
It's Production That Counts
53(1)
Cost of Change
54(2)
Reversible and Irreversible Decisions
54(2)
Easier Places to Experiment
56(1)
So Where Do We Start?
56(1)
Domain-Driven Design
56(4)
How Far Do You Have to Go?
57(1)
Event Storming
58(1)
Using a Domain Model for Prioritization
58(2)
A Combined Model
60(2)
Reorganizing Teams
62(9)
Shifting Structures
62(1)
It's Not One Size Fits All
63(2)
Making a Change
65(3)
Changing Skills
68(3)
How Will You Know if the Transition Is Working?
71(3)
Having Regular Checkpoints
71(1)
Quantitative Measures
72(1)
Qualitative Measures
72(1)
Avoiding the Sunk Cost Fallacy
73(1)
Being Open to New Approaches
73(1)
Summary
74(1)
3 Splitting the Monolith
75(50)
To Change the Monolith, or Not?
76(2)
Cut, Copy, or Reimplement?
76(1)
Refactoring the Monolith
77(1)
Migration Patterns
78(1)
Pattern: Strangler Fig Application
79(18)
How It Works
79(2)
Where to Use It
81(2)
Example: HTTP Reverse Proxy
83(3)
Data?
86(1)
Proxy Options
86(4)
Changing Protocols
90(3)
Example: FTP
93(1)
Example: Message Interception
94(3)
Other Protocols
97(1)
Other Examples of the Strangler Fig Pattern
97(1)
Changing Behavior While Migrating Functionality
97(1)
Pattern: UI Composition
98(6)
Example: Page Composition
99(1)
Example: Widget Composition
99(4)
Example: Micro Frontends
103(1)
Where to Use It
104(1)
Pattern: Branch by Abstraction
104(9)
How It Works
105(6)
As a Fallback Mechanism
111(1)
Where to Use It
112(1)
Pattern: Parallel Run
113(5)
Example: Comparing Credit Derivative Pricing
113(2)
Example: Homegate Listings
115(1)
Verification Techniques
116(1)
Using Spies
116(1)
GitHub Scientist
117(1)
Dark Launching and Canary Releasing
118(1)
Where to Use It
118(1)
Pattern: Decorating Collaborator
118(2)
Example: Loyalty Program
119(1)
Where to Use It
120(1)
Pattern: Change Data Capture
120(4)
Example: Issuing Loyalty Cards
120(1)
Implementing Change Data Capture
121(3)
Where to Use It
124(1)
Summary
124(1)
4 Decomposing the Database
125(82)
Pattern: The Shared Database
125(2)
Coping Patterns
127(1)
Where to Use It
127(1)
But It Can't Be Done!
127(1)
Pattern: Database View
128(4)
The Database as a Public Contract
129(1)
Views to Present
130(1)
Limitations
131(1)
Ownership
131(1)
Where to Use It
132(1)
Pattern: Database Wrapping Service
132(3)
Where to Use It
134(1)
Pattern: Database-as-a-Service Interface
135(2)
Implementing a Mapping Engine
136(1)
Compared to Views
137(1)
Where to Use It
137(1)
Transferring Ownership
137(6)
Pattern: Aggregate Exposing Monolith
138(3)
Pattern: Change Data Ownership
141(2)
Data Synchronization
143(2)
Pattern: Synchronize Data in Application
145(4)
Step 1 Bulk Synchronize Data
145(1)
Step 2 Synchronize on Write, Read from Old Schema
146(1)
Step 3 Synchronize on Write, Read from New Schema
147(1)
Where to Use This Pattern
148(1)
Where to Use It
148(1)
Pattern: Tracer Write
149(9)
Data Synchronization
152(2)
Example: Orders at Square
154(4)
Where to Use It
158(1)
Splitting Apart the Database
158(2)
Physical Versus Logical Database Separation
158(2)
Splitting the Database First, or the Code?
160(11)
Split the Database First
161(4)
Split the Code First
165(5)
Split Database and Code Together
170(1)
So, Which Should I Split First?
170(1)
Schema Separation Examples
171(1)
Pattern: Split Table
171(2)
Where to Use It
173(1)
Pattern: Move Foreign-Key Relationship to Code
173(14)
Moving the Join
175(1)
Data Consistency
176(2)
Where to Use It
178(1)
Example: Shared Static Data
178(9)
Transactions
187(6)
ACID Transactions
187(1)
Still ACID, but Lacking Atomicity?
188(2)
Two-Phase Commits
190(3)
Distributed Transactions---Just Say No
193(1)
Sagas
193(13)
Saga Failure Modes
195(4)
Implementing Sagas
199(6)
Sagas Versus Distributed Transactions
205(1)
Summary
206(1)
5 Growing Pains
207(30)
More Services, More Pain
207(2)
Ownership at Scale
209(1)
How Can This Problem Show Itself?
209(1)
When Might This Problem Occur?
210(1)
Potential Solutions
210(1)
Breaking Changes
210(5)
How Can This Problem Show Itself?
211(1)
When Might This Problem Occur?
211(1)
Potential Solutions
212(3)
Reporting
215(2)
When Might This Problem Occur?
216(1)
Potential Solutions
216(1)
Monitoring and Troubleshooting
217(5)
When Might These Problems Occur?
218(1)
How Can These Problems Occur?
218(1)
Potential Solutions
218(4)
Local Developer Experience
222(2)
How Can This Problem Show Itself?
223(1)
When Might This Occur?
223(1)
Potential Solutions
223(1)
Running Too Many Things
224(2)
How Might This Problem Show Itself?
224(1)
When Might This Problem Occur?
224(1)
Potential Solutions
224(2)
End-to-End Testing
226(3)
How Can This Problem Show Itself?
226(1)
When Might This Problem Occur?
226(1)
Potential Solutions
227(2)
Global Versus Local Optimization
229(3)
How Can This Problem Show Itself?
229(1)
When Might This Problem Occur?
229(1)
Potential Solutions
230(2)
Robustness and Resiliency
232(1)
How Can This Problem Show Itself?
232(1)
When Might This Problem Occur?
232(1)
Potential Solutions
232(1)
Orphaned Services
233(3)
How Can This Problem Show Itself?
233(1)
When Might This Problem Occur?
234(1)
Potential Solutions
234(2)
Summary
236(1)
6 Closing Words
237(2)
A Bibliography 239(4)
B Pattern Index 243(2)
Index 245
After spending time at multiple startups and 12 years at ThoughtWorks, Sam Newman is now an independent consultant. Specializing in microservices, cloud, and continuous delivery, Sam helps clients around the world deliver software faster and more reliably through training and consulting.

Sam is an experienced speaker who has spoken at conferences across the world, and is the author of Building Microservices from O'Reilly Media.