Evolutionary Architect — Vai trò kiến trúc sư thời microservices | Blog

Mở đầu

Mười lăm chương trước, cuốn sách gần như toàn nói về pattern kỹ thuật: giao tiếp, deploy, testing, resiliency... Đến chương 15, Sam Newman bất ngờ chuyển sang chuyện tổ chức, và chương 16 tiếp tục mạch đó nhưng thu về một vai trò cụ thể: người kiến trúc sư. Câu hỏi đặt ra nghe đơn giản mà trả lời không hề dễ — trong một hệ thống hàng chục service, mỗi service do một team khác làm chủ, thì ai là người giữ cho cả hệ thống đi đúng hướng? Ai nhìn thấy bức tranh lớn khi mỗi team chỉ thấy mảnh ghép của mình?

Câu trả lời của Sam Newman có thể làm nhiều người theo trường phái "kiến trúc sư quyền lực" giật mình: kiến trúc sư thời microservices không còn là người ngồi vẽ blueprint rồi giao xuống cho team thi công. Vai trò này giống người quy hoạch đô thị hơn — người đặt luật chơi, chỉ hướng phát triển, nhưng không tự tay xây từng toà nhà.

Ảnh: Blackcurrant Great — Pexels

Kiến trúc sư thời microservices — không còn vẽ blueprint

Với monolith, kiến trúc thường được quyết định một lần lúc khởi động dự án: vẽ xong tổng thể, team làm theo, rồi đóng băng. Nhưng microservices là một hệ thống sống — service mới ra đời hằng tháng, team mới được thành lập, công nghệ mới được thử nghiệm. Một bản vẽ tĩnh không bao giờ theo kịp hiện thực, và cứ bám vào nó thì kiến trúc sư chỉ tạo thêm friction cho team.

Sam Newman dùng hình ảnh người quy hoạch đô thị để mô tả vai trò mới. Người quy hoạch đô thị không xây toà nhà nào, nhưng quyết định khu nào là khu dân cư, khu nào là khu công nghiệp, đâu là trục đường chính. Các toà nhà vẫn mọc lên theo cách riêng của chủ đầu tư, nhưng nhờ luật chơi chung mà thành phố không trở thành mớ hỗn độn. Kiến trúc sư microservices cũng vậy: đặt ra khuôn khổ, để các team tự do phát triển bên trong nó.

Ông liệt kê năm phẩm chất cốt lõi: tầm nhìn (vision) — biết hệ thống nên đi về đâu; thấu cảm (empathy) — hiểu áp lực và khó khăn của team; hợp tác (collaboration) — làm việc cùng team chứ không áp đặt từ trên xuống; thích nghi (adaptability) — sẵn sàng đổi quyết định khi có thông tin mới; và trao quyền tự chủ (autonomy) — để team tự quyết định trong khuôn khổ đã định. Đáng chú ý là danh sách này không có chữ nào về quyền lực hay kiểm soát — đó chính là tinh thần của cả chương.

Principles — chưng cất tầm nhìn thành nguyên tắc

Tầm nhìn chỉ nằm trong đầu kiến trúc sư thì không điều khiển được quyết định nào. Bước tiếp theo là chưng cất nó thành principles — những nguyên tắc ngắn gọn, dễ hiểu, bất kỳ ai trong tổ chức cũng đọc được và áp dụng được. Ví dụ: "ưu tiên giao tiếp bất đồng bộ giữa các service", "mọi service phải có khả năng deploy độc lập", "không chia sẻ database giữa các service".

Điều quan trọng là mỗi nguyên tắc phải bắt nguồn từ một mục tiêu kinh doanh cụ thể, không phải từ sở thích cá nhân của kiến trúc sư. Và số lượng phải ít — một bộ nguyên tắc dài ba trang thì khác gì không có nguyên tắc, vì không ai nhớ nổi. Principles nên được treo ở nơi mọi người thấy hằng ngày, và bản thân kiến trúc sư cũng phải là người tuân thủ đầu tiên.

Lợi ích lớn nhất của principles là tạo ra ngôn ngữ chung cho mọi tranh luận kỹ thuật. Khi một team đề xuất giải pháp đi ngược nguyên tắc, cuộc thảo luận không còn là "tôi không thấy hợp lý" mà thành "giải pháp này vi phạm nguyên tắc số 3 — nếu muốn làm, cần đưa ra lý do chính đáng". Quyết định kiến trúc vì thế khách quan hơn hẳn, và team hiểu rõ ranh giới của mình thay vì đoán mò ý của sếp.

Governance & fitness functions — kiểm soát bằng code

Có principles rồi, việc tiếp theo là đảm bảo chúng được tuân thủ — đó là governance. Cách truyền thống là họp review kiến trúc định kỳ: kiến trúc sư ngồi duyệt từng thiết kế, từng quyết định rồi cho ý kiến. Cách này vừa chậm vừa tốn thời gian của cả hai phía, và dễ biến kiến trúc sư thành nút thắt cổ chai — thứ mà một tổ chức microservices trơn tru không thể chấp nhận.

Sam Newman đề xuất một hướng hiện đại hơn nhiều: fitness functions. Ý tưởng vay từ evolutionary computing, nơi một hàm số liên tục đánh giá một giải pháp có "khoẻ" (fit) hay không. Áp dụng vào kiến trúc: viết các đoạn kiểm tra tự động chạy liên tục, xác minh hệ thống có còn tuân thủ principles hay không. Ví dụ — một script kiểm tra mọi service có log về hệ thống tập trung; một bài test đảm bảo không service nào kết nối thẳng vào database của service khác; một metric chặn thời gian phản hồi trung bình vượt ngưỡng.

Điểm mạnh của cách này là governance chuyển từ "con người duyệt" sang "máy kiểm tra liên tục". Kiến trúc sư không còn là người gác cổng, mà là người xây hệ thống tự giám sát. Team có nhiều tự do hơn, nhưng sự tự do nằm trong ranh giới đã được mã hoá thành kiểm tra tự động — sai lệch bị phát hiện ngay lúc nó xảy ra, không phải ba tháng sau trong một buổi họp review.

Ảnh: Yan Krukau — Pexels

Paved road — con đường trải nhựa

Governance mới giải quyết nửa câu chuyện: ngăn team đi sai. Nửa còn lại — và quan trọng hơn — là làm sao để team dễ dàng đi đúng. Đây là lúc khái niệm paved road xuất hiện, một trong những ý tưởng được nhắc đến nhiều nhất của cuốn sách.

Paved road nghĩa là tổ chức chủ động xây một con đường đã trải nhựa sẵn: một tập công nghệ, pattern và tooling được chọn lọc, được hỗ trợ đầy đủ. Ví dụ — một service template chuẩn kèm sẵn logging, health check, metrics và CI/CD pipeline; một thư viện client chuẩn cho giao tiếp giữa các service; một quy trình deploy ai cũng dùng được. Team chỉ việc bước lên đường và đi.

Team vẫn hoàn toàn có quyền rẽ khỏi con đường để thử thứ khác — nhưng khi đó họ tự chịu trách nhiệm: tự bảo trì, tự vá lỗi bảo mật, tự lo nâng cấp phiên bản. Nhờ vậy paved road không tước quyền tự chủ, mà làm cho lựa chọn đúng trở thành lựa chọn dễ nhất — the right thing is the easy thing. Một điểm tinh tế nữa: paved road không được phép đóng băng. Nó phải được cập nhật liên tục từ phản hồi của chính các team đang dùng; nếu ai cũng né một công cụ nào đó, có lẽ công cụ đó không xứng đáng ở trên đường.

Ảnh: Tom Shamberger — Pexels

Tech debt — món nợ kiến trúc âm thầm

Chương khép lại với một chủ đề không ai xa lạ: tech debt. Trong thế giới microservices, tech debt có một đặc điểm nguy hiểm — nó bị phân tán. Mỗi service nợ một chút: một thư viện đã cũ, một đoạn code chưa refactor, một test bị bỏ qua. Nhưng không ai nhìn thấy tổng số nợ, vì không có một nơi nào để nhìn. Cộng dồn lại, đây có thể là thứ đắt nhất mà một hệ thống phân tán phải trả.

Sam Newman phân biệt hai loại nợ. Code-level debt nằm trong phạm vi một service — dễ phát hiện, dễ trả, và team sở hữu service tự xử lý được. Nguy hiểm hơn là architectural debt — những quyết định sai ở tầm hệ thống: chuẩn giao tiếp đã lỗi thời, pattern bảo mật cũ, thứ mà đổi một chỗ là vỡ nhiều chỗ. Loại nợ này không thuộc về bất kỳ team nào, nên tự nhiên không ai thấy mình có trách nhiệm trả.

Giải pháp của ông là làm cho tech debt hiện hình: đưa vào backlog, gắn nhãn rõ ràng, định kỳ đánh giá. Với architectural debt, cần có chủ sở hữu rõ ràng — có thể chính kiến trúc sư đứng ra điều phối như một dự án bình thường, thay vì để mỗi team tự trả nợ trong cô lập. Vay nợ kỹ thuật đôi khi là quyết định đúng để kịp deadline, nhưng vay mà không theo dõi thì khác gì đang chờ ngày vỡ nợ.

Key Takeaways

Kiến trúc sư microservices giống người quy hoạch đô thị hơn là người vẽ blueprint: đặt luật chơi, không thi công từng toà nhà; năm phẩm chất cốt lõi là vision, empathy, collaboration, adaptability, autonomy.
Principles là cách chưng cất tầm nhìn thành thứ team hành động được — ít, rõ, gắn với mục tiêu kinh doanh, và tạo ngôn ngữ chung cho mọi tranh luận kỹ thuật.
Fitness functions biến governance từ "người duyệt" thành "kiểm tra tự động liên tục" — team tự do hơn nhưng sai lệch bị phát hiện ngay lập tức.
Paved road làm cho lựa chọn đúng trở thành lựa chọn dễ nhất; team có thể rẽ khỏi đường nhưng phải tự chịu chi phí — và bản thân con đường phải được cập nhật liên tục.
Tech debt trong microservices bị phân tán nên dễ vô hình; cần làm nó hiện hình, phân biệt code-level debt với architectural debt, và giao architectural debt cho một chủ sở hữu rõ ràng.

📋 Phụ lục thuật ngữ

Evolutionary architect	Kiến trúc sư theo hướng tiến hoá: vai trò thích nghi liên tục với hệ thống đang phát triển, không áp đặt blueprint tĩnh.
Principles	Nguyên tắc kiến trúc ngắn gọn, xuất phát từ mục tiêu kinh doanh, dùng làm kim chỉ nam cho quyết định của team.
Governance	Hoạt động đảm bảo hệ thống tuân thủ các nguyên tắc đã đặt ra.
Fitness function	Kiểm tra tự động đánh giá hệ thống có còn "khoẻ" theo một tiêu chí kiến trúc cụ thể hay không.
Paved road	Tập công nghệ/tooling được hỗ trợ đầy đủ, làm cho lựa chọn mặc định trở thành lựa chọn đúng.
Tech debt	Nợ kỹ thuật — chi phí phát sinh do chọn giải pháp nhanh thay vì giải pháp bền vững.
Architectural debt	Nợ kỹ thuật ở tầm hệ thống, phân tán khắp các service, không thuộc về riêng team nào.
Code-level debt	Nợ trong phạm vi một service, dễ phát hiện và dễ trả.

Kết

Chương 16 khép lại phần nói về con người và quy trình của cuốn sách bằng một thông điệp rất thực dụng: microservices không chỉ là chuyện tách service, mà là chuyện một tổ chức biết cách giữ cho hệ thống phân tán của mình đi đúng hướng qua nhiều năm. Kiến trúc sư đóng vai trò then chốt — nhưng là vai trò của người tạo điều kiện, không phải người ra lệnh: principles để định hướng, fitness functions để giám sát, paved road để hỗ trợ, và một cách nhìn thẳng thắn về tech debt để không bao giờ bị vỡ nợ. Còn một chương nữa là hết cuốn sách — bài cuối của series sẽ là lúc nhìn lại toàn bộ hành trình từ câu hỏi "microservices là gì" cho đến đây.