Phân tích xu hướng Composable Architecture: kiến trúc linh hoạt

Composable Architecture (kiến trúc có thể lắp ghép) là cách xây dựng hệ thống doanh nghiệp từ các thành phần nghiệp vụ độc lập, mỗi thành phần đảm nhận một năng lực (giỏ hàng, thanh toán, tìm kiếm, quản lý nội dung, khuyến mãi) và giao tiếp qua API, để có thể thay thế hoặc bổ sung từng phần mà không phải làm lại cả hệ thống. Xu hướng này được thúc đẩy bởi nhu cầu thay đổi nhanh theo thị trường, nhưng nó cũng đi kèm chi phí tích hợp và vận hành không nhỏ. Bài viết phân tích khi nào composable thực sự đáng giá và khi nào một hệ thống nguyên khối được tổ chức tốt vẫn là lựa chọn khôn ngoan hơn.

Nguồn gốc và các khái niệm liên quan

Thuật ngữ "composable business" được hãng nghiên cứu Gartner phổ biến từ khoảng năm 2020, nhấn mạnh tổ chức và công nghệ có khả năng lắp ghép lại các năng lực nghiệp vụ. Trong thực tế triển khai, nó gắn với nhiều khái niệm:

• Packaged Business Capabilities (PBC): các khối năng lực nghiệp vụ đóng gói, có dữ liệu và API riêng.
• MACH: Microservices, API-first, Cloud-native SaaS, Headless. MACH Alliance là tổ chức các nhà cung cấp thúc đẩy cách tiếp cận này, phổ biến trong thương mại điện tử.
• Headless: tách giao diện khỏi phần xử lý, ví dụ CMS headless, commerce headless.
• Microservices: cách chia nhỏ hệ thống phần mềm thành các dịch vụ triển khai độc lập; composable là khái niệm rộng hơn, có thể ghép từ dịch vụ tự xây lẫn SaaS mua ngoài.

So sánh với kiến trúc nguyên khối

Lợi ích thực sự

• Chọn thành phần tốt nhất cho từng nhu cầu: tìm kiếm dùng dịch vụ chuyên dụng, nội dung dùng CMS headless, thanh toán dùng cổng phù hợp thị trường.
• Thay đổi từng phần: đổi nhà cung cấp tìm kiếm không cần đụng tới giỏ hàng.
• Thử nghiệm nhanh: thêm kênh bán mới (ứng dụng, mạng xã hội, kiosk) bằng cách xây giao diện mới trên cùng API.
• Mở rộng theo nhu cầu: thành phần chịu tải cao (giỏ hàng mùa khuyến mãi) mở rộng riêng.

Ví dụ, việc tách tìm kiếm thành một thành phần riêng được phân tích trong bài so sánh Elasticsearch, Algolia và Meilisearch, còn lựa chọn CMS headless có trong bài so sánh nền tảng CMS cho doanh nghiệp.

Chi phí ẩn và rủi ro

• Tích hợp là sản phẩm: dữ liệu khách hàng, sản phẩm, đơn hàng phải nhất quán giữa nhiều thành phần. Cần lớp điều phối, đồng bộ sự kiện, xử lý lỗi, và một đội sở hữu nó.
• Vận hành phân tán: sự cố có thể nằm ở bất kỳ thành phần nào hoặc ở giữa chúng; cần giám sát, truy vết đầu cuối.
• Nhiều nhà cung cấp: nhiều hợp đồng, nhiều chính sách giá, nhiều đầu mối hỗ trợ; khi có sự cố dễ đùn đẩy trách nhiệm.
• Tổng chi phí có thể cao hơn: cộng phí các SaaS chuyên dụng, hạ tầng tích hợp và nhân sự kỹ thuật thường vượt một bộ giải pháp trọn gói ở quy mô nhỏ.
• Bảo mật: nhiều API, nhiều khóa bí mật, nhiều nơi lưu dữ liệu khách hàng làm tăng bề mặt tấn công.

Khi nào nên đi theo hướng composable

Phù hợp khi:

• Doanh nghiệp bán hàng đa kênh, trải nghiệm số là lợi thế cạnh tranh chính.
• Hệ thống hiện tại đã chạm giới hạn, mỗi thay đổi nhỏ tốn nhiều tháng.
• Có đội kỹ thuật đủ mạnh về kiến trúc, tích hợp và vận hành, hoặc đối tác đáng tin cậy.
• Có nhu cầu khác biệt hóa ở một số năng lực mà giải pháp trọn gói không đáp ứng.

Chưa nên khi doanh nghiệp nhỏ, quy trình chuẩn, đội kỹ thuật mỏng; khi đó giải pháp trọn gói hoặc hệ thống nguyên khối module hóa tốt mang lại hiệu quả hơn.

Nguyên tắc thiết kế khi áp dụng

1. Xác định ranh giới theo năng lực nghiệp vụ, không theo lớp kỹ thuật. Mỗi thành phần sở hữu dữ liệu của mình.
2. API-first: hợp đồng API được thiết kế, tài liệu hóa và quản lý phiên bản trước khi cài đặt.
3. Giao tiếp bằng sự kiện cho các thay đổi cần lan truyền (đơn đã tạo, giá đã đổi) để giảm phụ thuộc trực tiếp.
4. Một nguồn chuẩn cho mỗi loại dữ liệu: xác định rõ hệ thống nào là nguồn chuẩn cho sản phẩm, giá, tồn kho, khách hàng.
5. Lớp trải nghiệm riêng (frontend, BFF) để kênh mới không phải gọi trực tiếp hàng chục API.
6. Nền tảng nội bộ dùng chung cho deploy, giám sát, quản lý bí mật; bài phân tích xu hướng Platform Engineering mô tả cách xây nền này.

Lộ trình chuyển đổi dần

Không nên đập bỏ hệ thống cũ để thay toàn bộ. Mô hình "cây đa bóp nghẹt" (strangler fig) phù hợp hơn:

1. Đặt một lớp API hoặc gateway phía trước hệ thống hiện tại.
2. Chọn một năng lực có giá trị và rủi ro vừa phải để tách trước, thường là nội dung hoặc tìm kiếm.
3. Chuyển dần lưu lượng sang thành phần mới, giữ khả năng quay lại.
4. Đo kết quả (tốc độ ra tính năng, hiệu năng, chi phí), rồi quyết định tách thành phần tiếp theo.

Sau vài vòng, doanh nghiệp có thể dừng ở trạng thái lai: lõi nguyên khối cho phần ổn định và các thành phần composable ở nơi cần linh hoạt. Đó thường là điểm cân bằng hợp lý nhất.