Các đội ngũ phần mềm liên tục mắc cùng một sai lầm về phân loại khi xem xét Fabric Workload Dev Kit. Họ thấy một quy trình phát hành (publishing pipeline), một danh sách kiểm tra chứng nhận (certification checklist) và một cổng thông tin đối tác (partner portal). Nói cách khác, họ thấy một chợ ứng dụng (marketplace). Họ hình dung về một tiện ích bổ sung (add-in) mà khách hàng có thể khám phá, tải xuống và chạy song song với hệ sinh thái Microsoft của họ.

Đó là một góc nhìn sai lầm. Một Fabric workload không phải là một phụ kiện. Nó là một bề mặt bản địa (native surface). Sau khi triển khai, ứng dụng của bạn sẽ tồn tại bên trong cùng một lớp vỏ (shell) với Lakehouse, Power BI và Notebook. Nó có loại mục (item type) riêng trong không gian làm việc (workspace). Nó xuất hiện khi người dùng nhấp vào "New". Giao diện người dùng (UI) của bạn được hiển thị ngay trong khung (chrome) của Fabric, chứ không phải trong một tab bật ra. Các tính năng của bạn nằm chính xác tại nơi các đội ngũ dữ liệu vốn đã dành hàng giờ làm việc. Đây không phải là một thanh công cụ phân phối phụ trợ. Đây là một cam kết mang tính cấu trúc đối với hệ điều hành dữ liệu của Microsoft. Nếu bạn đánh giá nó như một danh mục niêm yết, bạn có thể thấy mình bị mắc kẹt trong một nền tảng mà bạn không có quyền kiểm soát.

Lợi thế Bản địa

Khi bạn xây dựng cho Fabric, bạn thừa hưởng sự tin cậy và ngữ cảnh của môi trường máy chủ. Workload của bạn nhận được quyền đọc và ghi vào OneLake, điều này có nghĩa là ứng dụng của bạn có thể truy vấn trực tiếp các Delta tables mà không cần sao chép dữ liệu qua hàng tá quy trình ETL. Luồng xác thực thông qua Microsoft Entra ID, vì vậy ứng dụng của bạn hoạt động như chính người dùng đã đăng nhập. Không cần quản lý kho lưu trữ thông tin xác thực riêng biệt, không cần duy trì cầu nối SSO, và không có các yêu cầu mật khẩu dễ bị tấn công phishing khiến đội ngũ bảo mật phải lo lắng.

Trọng lực vận hành (operational gravity) cũng quan trọng không kém các kết nối kỹ thuật. Vì dữ liệu của khách hàng vẫn nằm trong tenant của chính họ, bạn có thể tránh được các thủ tục mua sắm rườm rà (procurement theater) vốn thường làm hỏng hầu hết các thương vụ SaaS doanh nghiệp. Một CISO không cần phải tranh luận về nơi lưu trữ dữ liệu (data residency). Một nhân viên thu mua không cần phải tính toán chi phí truyền dữ liệu ra ngoài (egress charges). Phần mềm của bạn đơn giản là hoạt động trong phạm vi các rào cản mà họ đã sở hữu. Đối với các nhà cung cấp bán hàng vào các ngành được quản lý chặt chẽ—mạng lưới y tế, dịch vụ tài chính, cơ quan chính phủ—đặc tính duy nhất này có thể rút ngắn một quy trình đánh giá bảo mật kéo dài mười hai tuần xuống còn một cuộc thảo luận chỉ trong vài ngày.

Những cạm bẫy tiềm ẩn

Trạng thái bản địa đi kèm với các phụ thuộc bản địa, và chúng có thể trở thành những rào cản thắt chặt hoạt động của bạn.

Thứ nhất, đó là bài toán về năng lực tính toán (compute math). Biên lợi nhuận của bạn giờ đây phụ thuộc vào Microsoft Capacity Units. Mọi hoạt động mà workload của bạn thực hiện đều tiêu tốn cùng một nhóm CU vốn đang cung cấp năng lượng cho các tác vụ Spark, các mô hình Semantic và các lượt làm mới Power BI của khách hàng. Nếu Microsoft điều chỉnh giá, thay đổi hệ số tiêu thụ (burn multipliers) hoặc giới thiệu các cấp độ năng lực mới, kinh tế học đơn vị (unit economics) của bạn sẽ thay đổi mà không có sự đồng ý của bạn. Bạn không kiểm soát lớp hạ tầng, điều đó có nghĩa là bạn không thể tối ưu hóa nó. Bạn chỉ có thể mô hình hóa và hy vọng.

Thứ hai, rủi ro về lộ trình (roadmap risk) là có thật. Microsoft có một tiền lệ đã được ghi nhận rõ ràng là quan sát các tính năng chuyên biệt (vertical features) hữu ích, sau đó tích hợp các tính năng tương đương mang tính nền tảng (horizontal equivalents) vào nền tảng cốt lõi. Nếu đề xuất giá trị của bạn chỉ là một lớp vỏ UI mỏng manh bao quanh các tác vụ dữ liệu thông thường, bạn đang xây dựng trên vùng đất mà Redmond có thể sẽ thâu tóm trong tương lai. Cách phòng vệ duy nhất là chiều sâu và tính đặc thù của lĩnh vực. Các công cụ làm sạch dữ liệu chung chung hoặc các công cụ trực quan hóa đơn giản sẽ phải đối mặt với một chiếc đồng hồ đang đếm ngược. Các mô hình học máy độc quyền, các tính toán đặc thù của ngành, hoặc logic quan sát (observability logic) có khả năng suy luận trên các lược đồ telemetry tùy chỉnh sẽ có cơ hội lớn hơn để duy trì sự không thể thay thế.

Thứ ba, nỗ lực kỹ thuật thường bị đánh giá thấp. Các hướng dẫn bắt đầu nhanh (quickstart tutorials) và các kho lưu trữ mẫu khiến bạn có cảm giác như có thể thiết lập một workload chỉ trong một buổi chiều. Bạn có thể làm được, nếu mục tiêu của bạn chỉ là một bản demo. Nhưng môi trường vận hành thực tế (production) thì khác. Bạn phải triển khai đầy đủ các hợp đồng backend (backend contract), xử lý các sự kiện vòng đời của mục (item lifecycle events), quản lý việc đồng bộ hóa trạng thái giữa control plane của bạn và của Fabric, và khôi phục một cách mượt mà khi năng lực tính toán tạm dừng hoặc kết nối lại. Bề mặt mà người dùng chạm vào có thể đơn giản, nhưng các quy tắc (contract) bên dưới thì không.

Nên Xây dựng hay Bỏ qua?

Quyết định nên dựa trên việc giá trị của bạn bắt nguồn từ đâu, chứ không phải dựa trên sự nhiệt huyết của bạn đối với hệ sinh thái của Microsoft.

Xây dựng nếu sản phẩm của bạn trở nên giá trị hơn khi nó càng nằm gần dữ liệu của khách hàng hơn. Các nền tảng quan sát (observability platforms), các công cụ phân tích đặc thù ngành và các công cụ quản trị (governance tools) đều phù hợp ở đây. Hãy xây dựng nếu người mua của bạn đã sử dụng sâu trong hệ sinh thái Microsoft và muốn hợp nhất chi tiêu thay vì tích hợp thêm một nhà cung cấp khác. Hãy xây dựng nếu sở hữu trí tuệ (IP) của bạn nằm trên lớp lưu trữ—như logic nghiệp vụ độc quyền, suy luận ML tùy chỉnh hoặc các quy trình làm giàu dữ liệu (enrichment pipelines) độc đáo—bởi vì những IP đó rất khó để Microsoft có thể sao chép một cách đại trà.

Hãy bỏ qua nếu giá trị của bạn không liên quan gì đến tính cục bộ của dữ liệu (data locality). Một bộ công cụ quản lý dự án hoặc một API gateway đa năng không cần phải nằm bên trong một workspace. Hãy bỏ qua nếu khách hàng mục tiêu của bạn luôn tự hào về việc trung lập với đa đám mây; yêu cầu họ triển khai bên trong Fabric sẽ làm tổn hại đến sự độc lập về kiến trúc của họ. Hãy bỏ qua nếu bạn cần kiểm soát chi tiết chi phí hạ tầng để bảo vệ biên lợi nhuận. Việc thuê nhóm tài nguyên tính toán không minh bạch của Microsoft là không tương thích với kỹ thuật chi phí (cost engineering).

Kiểm chứng thực tế trong 90 ngày

Đừng cam kết một lộ trình đầy đủ cho đến khi bạn thực hiện thử nghiệm ba giai đoạn này.

Ngày 1 đến 30: Xây dựng bản mẫu cho phần khó nhất. Hãy xây dựng một lát cắt dọc mỏng (thin vertical slice), nhưng hãy làm nó một cách thô sơ và trung thực. Chọn một loại mục duy nhất, triển khai chức năng tạo và xóa