Đội bạn có 12 kỹ sư và 23 service. Mỗi lần thêm một field vào order, bạn sửa 3 repo, chờ 3 pipeline, deploy theo đúng thứ tự, rồi mở Jaeger truy vết vì staging trả 500 ở một service không ai nhớ là của ai. Hóa đơn AWS tháng này lại tăng, phần lớn không phải do traffic — mà do control plane, sidecar, và cái cluster observability để nhìn thấy chính hệ thống của mình.
Nếu cảnh đó quen thuộc, bạn không cô đơn. Khảo sát CNCF 2025 ghi nhận 42% tổ chức từng dùng microservices đang gộp chúng lại thành đơn vị deploy lớn hơn. Service mesh — biểu tượng của làn sóng phân tán — rơi từ 18% adoption xuống 8% chỉ trong hai năm (Q3/2023 → Q3/2025). Đây không phải trào lưu "monolith is back" trên Twitter. Đây là kết quả của việc CFO nhìn thấy hóa đơn.
Chi phí thật: không nằm ở compute
Con số hay bị bỏ qua: một hệ microservices tương đương về chức năng đắt gấp 3,75-6 lần monolith — khoảng $40-65k/tháng so với ~$15k/tháng. Chênh lệch đó không đến từ EC2. Nó đến từ những thứ ít khi xuất hiện trong slide thuyết trình kiến trúc:
| Khoản chi | Monolith | Microservices |
|---|---|---|
| Compute + network | Cơ bản | Cơ bản + inter-service traffic, NAT, load balancer nhân N |
| Observability | 1 app, log tập trung | Distributed tracing, metrics per service, log aggregation |
| Platform team | Gần như không cần | 2-4 người chỉ để vận hành nền tảng |
| Coordination | Trong một PR | Contract testing, versioning API, deploy orchestration |
Có case được ghi nhận giảm chi phí AWS từ $18k xuống $2,4k/tháng — giảm 87% — chỉ bằng cách gộp lại. Không tối ưu code, không đổi cloud. Chỉ bỏ đi phần "tax" của sự phân tán.
Với đội 10-50 kỹ sư ở Việt Nam, phép tính còn khắc nghiệt hơn: 2-4 người làm platform team là 15-30% quân số. Đó là 15-30% năng lực không tạo ra feature nào, chỉ để giữ cho hệ thống... tồn tại.
Lý do mới của 2026: AI agent đọc code
Có một biến số không tồn tại khi ta chọn microservices năm 2019: giờ đây phần lớn code được viết cùng AI agent. Và agent làm việc trên modular monolith hiệu quả hơn hẳn hệ phân tán, vì một lý do rất trần trụi — context.
Với monolith, toàn bộ luồng nghiệp vụ nằm trong một repo, một process. Agent grep, đọc, sửa, chạy test — xong. Với 23 service, cùng luồng đó rải qua N repo, N contract, N config deploy. Agent (và cả người) phải tái dựng bức tranh từ những mảnh rời, mà không mảnh nào chứa đủ sự thật. Khi Thoughtworks Radar vol.34 lấy "cognitive debt" làm chủ đề chính, kiến trúc phân tán chính là máy sản xuất loại nợ đó: mỗi ranh giới service là một chỗ để hiểu biết rơi rớt.
Nói cách khác: microservices từng được bán như cách để đội người scale. Năm 2026, câu hỏi thêm vào là kiến trúc nào để đội người-cộng-agent scale. Và câu trả lời đang nghiêng về phía ít process hơn, ít ranh giới mạng hơn.
Modular monolith đúng nghĩa — không phải big ball of mud
Gộp lại không có nghĩa là quay về mớ code 500 nghìn dòng ai đụng vào cũng run tay. Modular monolith là một deploy unit nhưng ranh giới module tường minh, và ranh giới đó phải được enforce bằng máy, không phải bằng convention trong tài liệu Confluence không ai đọc.
Fitness function trong CI là công cụ chính. Ví dụ với ArchUnit:
@ArchTest
static final ArchRule modules_khong_duoc_xuyen_thau =
slices().matching("com.company.app.(*)..")
.should().notDependOnEachOtherExcept(
dependency("orders", "shared"),
dependency("billing", "shared"));
Vi phạm boundary → build đỏ. Không họp, không tranh cãi. Đây cũng là hướng O'Reilly gọi là "governance by rule" thay vì "governance by inspection" — và là guardrail để AI agent không tự tiện kéo dependency chéo module khi generate code.
Điểm quan trọng: module boundary tốt chính là đường tách service sau này. Nếu module payments một ngày thật sự cần scale độc lập, tách nó ra là chuyện tuần, không phải quý. Modular monolith không đóng cửa microservices — nó hoãn quyết định đắt đỏ đến khi có bằng chứng.
Checklist quyết định
Tín hiệu nên gộp lại:
- Số service nhiều hơn số kỹ sư. Đây là red flag rõ nhất — mỗi service là một đứa con cần nuôi.
- Phần lớn thay đổi nghiệp vụ đụng ≥2 service cùng lúc. Nghĩa là boundary đã sai; bạn có distributed monolith, chịu mọi chi phí phân tán mà không hưởng lợi ích nào.
- Chi phí mesh + observability + platform team vượt giá trị nó bảo vệ. Nếu bạn trả $20k/tháng để tránh downtime trị giá $5k/tháng, phép tính tự nói.
- Onboarding một kỹ sư mới (hoặc một AI agent) mất hàng tuần chỉ để hiểu topology.
Tín hiệu microservices vẫn thắng:
- Scale độc lập thật sự: một phần hệ thống cần 50 instance khi phần còn lại cần 2, hoặc khác biệt hẳn về runtime (GPU inference vs CRUD).
- Ranh giới tổ chức thật: các team khác nhau, release cadence khác nhau, thậm chí compliance khác nhau (vd module thanh toán cần PCI-DSS).
- Fault isolation là yêu cầu kinh doanh, không phải sở thích kỹ thuật.
Chú ý thứ tự: đây là những điều kiện đã xảy ra và đo được, không phải "sau này có thể cần". Kiến trúc phân tán mua bằng tiền thật hôm nay để phòng một tương lai chưa chắc đến.
Kết
Microservices chưa bao giờ sai. Cái sai là mặc định chọn nó ở quy mô mà nó chưa trả lãi — và suốt gần một thập kỷ, ngành này đã coi chi phí phân tán là "chi phí của sự chuyên nghiệp". Năm 2026, với hóa đơn cloud minh bạch hơn và AI agent làm việc trong codebase mỗi ngày, cái giá của mỗi ranh giới mạng hiện ra bằng số. Kiến trúc tốt không phải kiến trúc trông giống Netflix. Kiến trúc tốt là kiến trúc mà đội của bạn — 12 con người và vài chục agent — hiểu được, trả tiền nổi, và còn đường tiến hóa khi bằng chứng xuất hiện.
