Sự đồng nhất không phải là một mục tiêu để bạn đạt được. Đó là một khoản phí thuê bao mà bạn phải trả. Mọi tổ chức kỹ thuật cuối cùng đều nhận ra điều này, thường là vào thời điểm nhóm thứ hai hoặc thứ ba bắt đầu commit vào cùng một repository. Dù bạn đang vận hành một monolith React duy nhất hay một chùm các frontend có thể triển khai độc lập, bạn không phải đang tối ưu hóa để đạt mức chi phí bằng không. Bạn chỉ đơn giản là đang chọn xem hóa đơn nào sẽ xuất hiện vào mỗi quý.

Thuế điều phối của các kiến trúc Monolith

Trong một kiến trúc monolithic, hóa đơn được tính bằng giờ công của con người. Các nhóm dành cả ngày để thống nhất về mã nguồn, style và lịch trình phát hành dùng chung. Một lập trình viên muốn đẩy một bản sửa lỗi thanh toán nhỏ có thể cần phải nâng cấp một dependency dùng chung mà nửa tá nhóm khác đang sử dụng, sau đó phải chờ toàn bộ bộ kiểm thử hồi quy (regression suite) hoàn tất. Chi phí này tích tụ một cách âm thầm. Nó không bao giờ xuất hiện dưới dạng một hạng mục trên hóa đơn đám mây. Nó ẩn mình trong tốc độ phát triển bị giảm sút, trong việc các kỹ sư phải chuyển đổi ngữ cảnh (context-switching) giữa các luồng Slack về phong cách viết code, và trong sự ma sát chậm chạp của một kiến trúc CSS mà không ai sở hữu nhưng tất cả mọi người đều chạm vào.

Khi đội ngũ của bạn lớn mạnh, khoản thuế này cũng tăng theo. Các nút thắt cổ chai trong việc review code chuyển từ các vấn đề kỹ thuật sang các vấn đề về con người. Một repository duy nhất với hai trăm người đóng góp không mở rộng theo cấp số tuyến tính; nó mở rộng theo cấp số tổ hợp. Các hàng đợi merge bị ùn tắc. Các đợt phát hành (release trains) kéo dài qua nhiều ngày. Hệ thống thiết kế (design system) trở thành một thực thể chính trị đòi hỏi một hội đồng quản trị phải phê duyệt một biến thể nút bấm mới. Kiến trúc monolith không kháng cự sự thay đổi vì ác ý. Nó kháng cự vì mọi bề mặt đều được dùng chung, và mọi thay đổi đều đòi hỏi sự đồng thuận.

Thiết lập ranh giới

Microfrontends chuyển các chi phí điều phối vào các ranh giới cụ thể. Thay vì họp hàng tuần về quản lý state dùng chung, bạn vạch ra một ranh giới. Nhóm A sở hữu danh mục sản phẩm. Nhóm B sở hữu giỏ hàng. Họ thống nhất với nhau về một bản hợp đồng (contract), thường là một ranh giới định tuyến (routing boundary) hoặc một schema sự kiện hẹp, và sau

Không có mô hình nào là miễn phí cả. Một startup mười lăm người không cần một đội ngũ platform. Chi phí vận hành (overhead) của module federation, các pipeline triển khai độc lập và kiểm thử hợp đồng phân tán (distributed contract testing) sẽ ngốn sạch tốc độ phát triển (velocity) của họ. Họ nên trả giá bằng sự phối hợp vì sự phối hợp đó rất rẻ. Họ có thể thống nhất về một pattern quản lý trạng thái (state management pattern) chỉ trong mười phút trò chuyện và triển khai nó ngay trong buổi chiều hôm đó.

Một doanh nghiệp năm trăm người với hàng chục đơn vị kinh doanh hoạt động theo các chu kỳ quý khác nhau lại đối mặt với vấn đề ngược lại. "Thuế phối hợp" (coordination tax) đã trở nên theo cấp số nhân. Các đợt phát hành (release trains) mất hàng tuần. Định biên nhân sự cho platform engineering đã là một thực tế trong ngân sách, vì vậy việc thêm hạ tầng microfrontend chỉ là một chi phí biên (marginal cost), chứ không phải là một khoản mục mới. Đối với họ, việc đổi các cuộc họp thống nhất (alignment meetings) lấy các biểu đồ triển khai (deployment graphs) là một phép tính hợp lý.

Câu hỏi thực sự là hóa đơn nào sẽ mở rộng (scale) tốt hơn cho đội ngũ của bạn. Monolith đánh thuế bạn ở giới hạn của sự phối hợp giữa con người. Microfrontend đánh thuế bạn ở nền tảng của platform engineering.

Chọn loại "tiền tệ" của bạn

Nếu bạn chọn microfrontends, hãy xác định rõ ràng những gì bạn đang mua. Bạn đang mua sự tự chủ của đội ngũ và khả năng triển khai độc lập. Hãy sẵn sàng chi trả cho những điều sau:

  • Một runtime shell xử lý việc kết hợp (composition), định tuyến (routing) và các ranh giới lỗi (error boundaries) giữa các mảnh (fragments).
  • Một chính sách phụ thuộc dùng chung (shared dependency policy) tập trung vào chiến lược loại bỏ trùng lặp (deduplication strategy), chứ không phải logic triển khai dùng chung.
  • Kiểm thử hợp đồng liên đội ngũ (cross-team contract testing) cho mọi bề mặt tích hợp.
  • Khả năng quan sát thống nhất (unified observability) có thể liên kết một cú nhấp chuột của người dùng qua các bundle phân tán.
  • Một mô hình quản trị hiệu năng (performance governance model), vì không có đội ngũ đơn lẻ nào sở hữu payload cuối cùng mà trình duyệt tải xuống.

Nếu bạn chọn monolith, hãy thành thật về hóa đơn. Bạn đang mua sự đơn giản để đổi lấy sự đồng bộ. Hãy chuẩn bị trả giá cho:

  • Quyền sở hữu mã nguồn dùng chung và các nghi thức quản trị cần thiết để giữ cho nó nhất quán.
  • Nhịp độ phát hành (release cadence) bị quyết định bởi bài kiểm tra tích hợp chậm nhất trong pipeline.
  • Phạm vi ảnh hưởng (blast radius) rộng khi nâng cấp thư viện.
  • Thực tế dần hiện hữu rằng những kỹ sư nhanh nhất của bạn sẽ phải di chuyển theo tốc độ của những người thận trọng nhất.

Bài học thực sự

Không có kiến trúc nào giúp loại bỏ chi phí. Chỉ có sự lựa chọn về loại tiền tệ. Các tổ chức thông minh sẽ ngừng tìm kiếm lựa chọn miễn phí và bắt đầu kiểm tra xem họ thực sự có khả năng chi trả cho loại chi phí nào. Bạn phải quyết định xem mình muốn trả giá bằng sự phối hợp giữa con người hay bằng chi phí vận hành nền tảng (platform overhead). Sự đồng nhất, trong cả hai trường hợp, vẫn là một khoản phí đăng ký (subscription). Câu hỏi duy nhất là ai sẽ là người ký séc.