Chương 2 là chương ít kỹ thuật nhất của cuốn sách và, theo mình, là chương giá trị nhất. Trước bất kỳ proxy hay saga nào, Newman hỏi bạn có nên migrate hay không, bạn thực sự muốn đạt được gì, và làm sao biết mình đang đi đúng hướng. Phần lớn nội dung xoay quanh con người: thuyết phục đồng nghiệp, thay đổi trách nhiệm của các team, và dám thừa nhận khi kế hoạch không hiệu quả.

Nếu chỉ có thời gian đọc một chương trước buổi kickoff migration, hãy đọc chương này.

Ứng với chương 2 trong sách.

Ý chính

Microservices không phải là mục tiêu

Chương mở đầu bằng một khẳng định thẳng thắn: không ai thắng chỉ vì có microservices. Áp dụng chúng phải là một quyết định có chủ đích, nhắm tới một kết quả mà kiến trúc hiện tại không đạt được. Không có kết quả rõ ràng thì bạn không ưu tiên được, sa vào analysis paralysis (tê liệt vì phân tích quá nhiều), hoặc bắt chước một công ty nổi tiếng chỉ vì cách đó hợp với họ.

Ba câu hỏi của Newman là công cụ cốt lõi, và chúng dùng được như checklist cho bất kỳ thay đổi kỹ thuật lớn nào:

1. What are you hoping to achieve?
   An outcome the business cares about, described as a benefit to users.
2. Have you considered alternatives?
   Cheaper, more boring options that might get the same result.
3. How will you know if the transition is working?
   Measures and checkpoints agreed before you start.

Ông kể rằng chỉ riêng việc đặt ra ba câu hỏi này đã đủ khiến một số tổ chức cân nhắc lại.

Lý do nào cũng có một lựa chọn rẻ hơn để thử trước

Chương này đi qua các lý do phổ biến để áp dụng microservices và, với mỗi lý do, những cách khác để có cùng lợi ích. Đây là phần mình sẽ đặt trước mặt bất kỳ team nào đã quyết định sẵn câu trả lời:

Lý do được đưa ra Lựa chọn thay thế sách gợi ý thử
Team autonomy (sự tự chủ của team) Giao quyền sở hữu từng phần codebase, hạ tầng self-service, modular monolith
Time to market nhanh hơn Vẽ toàn bộ đường tới production trước; điểm nghẽn thường nằm ngoài khâu development
Scale tiết kiệm chi phí Máy to hơn, chạy nhiều bản monolith sau load balancer
Robustness Instance dự phòng trên nhiều vùng lỗi, bớt quy trình thủ công
Thêm developer Modular monolith với module do từng team sở hữu, chấp nhận phối hợp khi release
Công nghệ mới Ngôn ngữ khác trên cùng runtime, hoặc thay dần stack

Reuse được đối xử riêng. Newman cho rằng đó là mục tiêu kém vì nó chỉ là phương tiện cho thứ khác, thường là tốc độ, và tối ưu cho reuse có thể làm bạn chậm đi khi thứ có thể tái sử dụng thuộc về team khác. Hãy đo kết quả bạn muốn, đừng đo reuse.

Ông cũng tách robustness (độ vững) khỏi resilience (khả năng thích nghi): robustness là xử lý được những lỗi đã lường trước, resilience là khả năng của tổ chức thích nghi với những lỗi chưa từng nghĩ tới. Tách hệ thống thành nhiều process cho bạn thêm lựa chọn để tăng robustness, nhưng cũng mở rộng bề mặt có thể hỏng.

Khi nào microservices là ý tồi

Có bốn tình huống được cảnh báo rõ:

  • Domain chưa rõ. Ranh giới sai rất tốn kém khi phải dời qua nhiều service. Team SnapCI ở ThoughtWorks tách quá sớm, gộp tất cả lại thành một ứng dụng, và chỉ tách lại khi domain đã ổn định.
  • Startup. Trước khi tìm được product/market fit, domain thay đổi liên tục. Microservices giải quyết những vấn đề bạn gặp sau khi đã thành công bước đầu, và tách một hệ thống brownfield đang chạy dễ hơn nhiều so với đoán ranh giới từ đầu.
  • Phần mềm khách hàng tự cài đặt. Bạn đẩy độ phức tạp vận hành sang khách hàng, những người không thể được kỳ vọng sẽ chạy nhiều process hay cả một cluster.
  • Không có lý do chính đáng. Làm vì ai cũng làm là dấu hiệu cảnh báo lớn nhất.

Khi có nhiều mục tiêu cùng lúc, Newman gợi ý xếp hạng chúng một cách tường minh, ví dụ bằng các thanh trượt mà nâng mức ưu tiên của cái này thì buộc phải hạ cái khác, để những mong muốn phụ như thử một ngôn ngữ mới không lấn át mục tiêu chính.

Đưa mọi người đi cùng

Phần lớn chương điều chỉnh mô hình thay đổi tám bước của Kotter cho một cuộc migration kiến trúc. Mình thấy các bước đầu hữu ích nhất ở quy mô team: tạo cảm giác cấp bách quanh vấn đề chứ không quanh microservices, tìm một nhóm dẫn dắt có cả người ngoài engineering (vì những trade-off như dữ liệu cache bị cũ ảnh hưởng tới người dùng), và thống nhất một tầm nhìn tham vọng nhưng đáng tin. Các bước sau là gỡ chướng ngại, tạo những chiến thắng nhanh, xây tiếp trên đó, và biến cách làm mới thành bình thường, đồng thời chừa chỗ cho ý tưởng tốt hơn kế tiếp.

Về team, Newman cảnh báo việc sao chép cấu trúc của công ty khác (cái gọi là Spotify model, mà chính Spotify cũng không còn dùng) và việc tuyên bố từ giờ developer phải vận hành mọi thứ suốt ngày đêm. Cách ông đề xuất rất thực tế: liệt kê mọi trách nhiệm trong quá trình delivery, vẽ ai đang làm chúng hôm nay, vẽ trạng thái mong muốn trong sáu tới mười hai tháng tới, và chuyển từng trách nhiệm một kèm đào tạo và hỗ trợ. Về kỹ năng, ông khuyên tự đánh giá riêng tư rồi gộp thành một bức tranh ẩn danh cho cả team.

Bắt đầu nhỏ, giữ quyết định đảo ngược được, và chọn bằng hai trục

Trái tim chiến lược của chương là migration từng bước. Tách một hoặc hai service, đưa chúng lên production và được dùng thật, rút kinh nghiệm, rồi mới quyết định bước tiếp theo. Việc tách một service chưa xong cho tới khi nó chạy thật, vì phần lớn bài học (tracing, latency, các kiểu lỗi) chỉ lộ ra trên production.

Newman mượn ý tưởng quyết định đảo ngược được và không đảo ngược được, và coi chúng là hai đầu của một dải. Phần lớn quyết định trong migration nằm gần đầu đảo ngược được và có thể được đưa ra nhanh bởi những người gần vấn đề nhất. Những quyết định đắt đỏ, như tách database hay đổi một API được dùng rộng rãi, đáng được cân nhắc kỹ hơn. Nơi rẻ nhất để mắc sai lầm là bảng trắng: cho các use case thật đi qua ranh giới bạn đề xuất và tìm những lời gọi quá nhiều qua lại hoặc vòng tròn.

Để chọn chỗ bắt đầu, hãy dựng một domain model sơ bộ (Event Storming là bài tập ông khuyên dùng), rồi chấm các ứng viên trên hai trục: khó tách tới đâu, đánh giá một phần qua số phụ thuộc chiều vào, và việc tách mang lại bao nhiêu giá trị cho mục tiêu. Đây là hình dạng của bài tập đó với ví dụ của mình:

                    easy to extract
                          ^
        Certificates      |      Invoicing
        (rarely changes)  |      (changes weekly, few callers)
                          |
  low value <-------------+-------------> high value
                          |
        Admin reports     |      Notifications
                          |      (many callers, hard to cut)
                          v
                    hard to extract

Bắt đầu ở góc vừa dễ vừa có giá trị, và vẽ lại bức tranh khi học thêm, vì một số thứ tưởng dễ hoá ra khó và ngược lại.

Biết migration có đang hiệu quả không

Newman khuyên có các checkpoint định kỳ gồm bốn việc: nhắc lại mục tiêu và dừng lại nếu doanh nghiệp đã đổi hướng, xem lại số liệu, hỏi mọi người cảm thấy thế nào, và quyết định sẽ thay đổi gì. Thước đo định lượng nên đi theo mục tiêu (cycle time và deployment frequency cho tốc độ, load test cho khả năng scale), kèm cảnh báo rằng metric có thể bị "chơi" và một số sẽ tệ đi trước khi tốt lên. Phản hồi định tính cũng quan trọng không kém. Bước nhỏ còn là cách bảo vệ tốt nhất trước sunk cost fallacy, vì đổi hướng sau một ván cược nhỏ thì rẻ.

Đọc lại ở năm 2026

  • Sự hoài nghi đã thành dòng chính. Nhiều team giờ mặc định chọn một modular monolith có cấu trúc tốt và chỉ tách service ở nơi có một áp lực cụ thể (scale, sự độc lập của team, runtime khác) biện minh cho nó. Cách Newman coi microservices là phương tiện, với lựa chọn rẻ hơn cho mọi mục tiêu, về cơ bản chính là quan điểm đó.
  • Đo lường delivery. Nghiên cứu State of DevOps mà Newman nhắc tới tiếp tục dưới tên DORA, với bộ metric về hiệu năng software delivery là điểm khởi đầu quen thuộc cho phần định lượng trong các checkpoint của ông. Hãy dùng kèm những câu hỏi định tính ông liệt kê; chỉ nhìn metric sẽ bỏ sót việc team đang xoay xở ra sao.
  • Platform engineering. Lời khuyên gỡ chướng ngại bằng provisioning self-service của ông đã lớn thành một chuyên ngành. Platforms working group của CNCF công bố white paper vào tháng 4/2023, định nghĩa internal platform và các team xây chúng như sản phẩm dành cho developer.
  • Thiết kế team. Team Topologies, cuốn ông giới thiệu, vẫn là bộ từ vựng chung cho stream-aligned team và platform team. Lời cảnh báo của ông về việc sao chép cấu trúc của một tổ chức nổi tiếng cũng áp dụng cho chính nó.
  • Khám phá domain. Event Storming vẫn được dùng rộng rãi. Domain Storytelling và các workshop context mapping là những lựa chọn khác để tạo ra mô hình sơ bộ ông mô tả.

Áp dụng vào dự án

  1. Viết ba câu hỏi lên đầu đề xuất migration và trả lời mỗi câu trong một đoạn trước mọi thứ khác.
  2. Với mục tiêu chính, thử ít nhất một lựa chọn thay thế trong bảng trên và ghi lại kết quả.
  3. Xếp hạng mục tiêu tường minh và gọi tên mục tiêu chính; gác lại các mục tiêu phụ cạnh tranh với nó.
  4. Tổ chức một buổi domain modeling hai tiếng có người ngoài engineering và đặt mọi ứng viên service lên hai trục dễ tách và giá trị.
  5. Thống nhất hai con số và hai câu hỏi cho checkpoint hằng tháng, và quyết định trước kết quả nào sẽ khiến bạn dừng lại.
  6. Vẽ bản đồ trách nhiệm delivery hiện tại theo từng team trước khi công bố bất kỳ thay đổi nào về việc ai deploy hay hỗ trợ cái gì.

Tự kiểm tra

  1. Ba câu hỏi then chốt của Newman là gì? Bạn muốn đạt được gì, bạn đã cân nhắc các lựa chọn thay thế chưa, và làm sao biết quá trình chuyển đổi đang hiệu quả?

  2. Vì sao ông coi reuse là mục tiêu kém? Reuse chỉ là phương tiện cho những kết quả như tốc độ hay chi phí, và chạy theo nó có thể làm bạn chậm đi khi code dùng chung thuộc về team khác.

  3. Vì sao startup thường không phải ứng viên tốt? Domain của họ thay đổi liên tục trước khi tìm được product/market fit, nên ranh giới vẽ sớm nhiều khả năng sẽ sai.

  4. Ông dùng hai trục nào để chọn chỗ bắt đầu? Độ dễ khi tách và giá trị mà việc tách mang lại cho mục tiêu.

  5. Khi nào việc tách một service mới được coi là xong? Chỉ khi service mới đã chạy trên production và thực sự được sử dụng.

Đọc thêm