Microservices không phải lựa chọn mặc định (Building Microservices)

Mở đầu

Sau 16 chương đi sâu vào từng ngóc ngách kỹ thuật — từ giao tiếp giữa các service, deploy, testing, security cho tới scale — Afterword của Building Microservices bất ngờ quay lại câu hỏi gốc rễ nhất: vậy khi nào thì thật sự nên dùng microservices? Câu trả lời của Sam Newman có thể làm nhiều người bất ngờ: không thường xuyên như mọi người vẫn nghĩ. Chương cuối này như một lời nhắc tỉnh táo cho những ai vừa đọc xong một cuốn sách dày đặc về microservices — đừng vội kết luận rằng hệ thống nào cũng nên tách nhỏ.

Ảnh: Pixabay — Pexels

Microservices không phải lựa chọn mặc định

Điều đầu tiên tác giả làm trong Afterword là hạ nhiệt cơn sốt microservices. Xuyên suốt cuốn sách, ông chưa bao giờ nói monolith là xấu — ngược lại, monolith là điểm khởi đầu hợp lý cho rất nhiều hệ thống. Vấn đề không nằm ở kích thước codebase mà nằm ở cách tổ chức nó: một monolith được chia module rõ ràng (modular monolith) vẫn dễ bảo trì hơn một mớ service tách theo cảm hứng.

Microservices mang lại lợi ích thật: khả năng deploy độc lập, team tự chủ, scale từng phần. Nhưng đi kèm là chi phí vận hành đáng kể — hạ tầng phức tạp hơn, debugging khó hơn, cần CI/CD và observability trưởng thành. Nếu lợi ích không lớn hơn chi phí, việc tách nhỏ chỉ tạo thêm đau đầu cho cả team.

Khi nào không nên dùng microservices

Sam Newman liệt kê các tình huống điển hình mà microservices là lựa chọn sai. Đầu tiên là team nhỏ, ít người — chi phí vận hành một hệ thống phân tán vượt xa lợi ích mà nó mang lại. Thứ hai là hệ thống mới, domain chưa rõ — chia ranh giới service sai ngay từ đầu thì càng tách càng nợ, và việc vẽ ranh giới khi chưa hiểu nghiệp vụ gần như chắc chắn sẽ sai.

Thứ ba là tổ chức chưa sẵn sàng về mặt vận hành: chưa có CI/CD tự động, chưa có monitoring tốt, deploy còn thủ công. Microservices sẽ phơi bày mọi điểm yếu này. Cuối cùng là lý do tệ nhất: "đi theo trend" — cái gọi là microservices envy, thấy hệ thống khác tách nhỏ rồi cũng muốn làm theo cho giống, mà không trả lời được câu hỏi mình cần gì.

Ảnh: Han-Chieh Lee — Pexels

Khi nào nên dùng microservices

Ngược lại, có những dấu hiệu rõ ràng cho thấy đã đến lúc tách. Nhu cầu deploy độc lập thật sự là dấu hiệu quan trọng nhất — một phần hệ thống thay đổi thường xuyên hơn hẳn phần còn lại, và việc deploy chung bắt đầu kìm hãm nhịp phát hành. Khi đó một service riêng cho phép phần "nóng" của hệ thống đi nhanh mà không kéo theo phần còn lại.

Tiếp theo là quy mô tổ chức: nhiều team cùng phát triển một hệ thống, và ranh giới team cần trùng với ranh giới service (Conway's law). Nhu cầu scale không đồng đều cũng là lý do chính đáng — một phần cần scale ngang gấp nhiều lần phần khác. Và quan trọng không kém: năng lực vận hành đã trưởng thành, đội ngũ tự tin vận hành nhiều service với CI/CD tự động và observability đầy đủ.

Key Takeaways

• Microservices không phải lựa chọn mặc định — monolith vẫn là điểm khởi đầu đúng cho hầu hết hệ thống.
• Lợi ích cốt lõi của microservices là independent deployability — nếu không cần nó, đừng tách.
• Tách nhỏ quá sớm dễ tạo ra distributed monolith — thứ tệ nhất của cả hai thế giới.
• Yếu tố quyết định nằm ở tổ chức và năng lực vận hành, không phải công nghệ.
• Khởi đầu bằng modular monolith, tách dần khi có nhu cầu thật — kiến trúc tiến hoá theo thời gian.

Ảnh: RDNE Stock project — Pexels

📋 Phụ lục thuật ngữ

Microservices envy	Tâm lý muốn dùng microservices chỉ vì thấy tổ chức khác dùng, không xuất phát từ nhu cầu thật.
Independent deployability	Khả năng deploy một service riêng lẻ mà không ảnh hưởng các service khác.
Distributed monolith	Tách service nhưng vẫn phụ thuộc chặt, deploy phải cùng lúc — mất lợi ích của cả hai mô hình.
Modular monolith	Monolith được tổ chức thành các module rõ ràng, dễ tách thành service độc lập sau này.
Conway's law	Tổ chức tạo ra hệ thống phản ánh cấu trúc giao tiếp của chính nó.
Observability	Năng lực quan sát hệ thống qua log, metric, trace để hiểu trạng thái và chẩn đoán lỗi.

Kết

Afterword khép lại cuốn sách bằng một thông điệp rất thực dụng: microservices là phương tiện, không phải đích đến. Toàn bộ 16 chương trước đó chỉ có ý nghĩa khi bạn trả lời được câu hỏi "có cần hay không" trước khi hỏi "làm thế nào". Đây cũng là bài cuối của series Building Microservices trên blog — từ khái niệm cơ bản, modeling với DDD, tách monolith, giao tiếp giữa các service, CI/CD, deploy, testing, security, resiliency, scale, team topology cho tới chương này. Mong rằng series đã cho bạn một bức tranh đủ đầy để tự tin quyết định — và nếu quyết định cuối cùng là "không dùng microservices", thì đó cũng là một quyết định đúng.