Một giao diện duy nhất cho mọi giao thức: OpenBindings giải quyết bài toán phân mảnh hạ tầng

Một giao diện duy nhất cho mọi giao thức: OpenBindings giải quyết bài toán phân mảnh hạ tầng

Vào đầu tháng này, một bài đăng của nhà phát triển Dax Raad (@thdxr) đã gây tiếng vang lớn trong cộng đồng kỹ thuật: "Tôi không biết mọi người quản lý hạ tầng như thế nào nữa. Mỗi dịch vụ đều có một CLI hoặc file cấu hình riêng biệt và họ không còn hỗ trợ Terraform tốt nữa. Hệ thống của bạn không bao giờ chỉ dùng một nhà cung cấp, vậy mọi người có đang gộp tất cả những thứ lộn xộn này vào với nhau không?"

Chỉ trong một ngày, hơn năm mươi nghìn người đã xem bài đăng này. Các câu trả lời ồ ạt đổ về với đủ các cái tên như SST, Pulumi, Ansible, hay những lời khuyên cay nghiệt như "Hãy cứ ở lại AWS" hoặc "Hạ tầng ngày nay giống như một chiếc băng dính được dán lên bảng điều khiển". Mọi người đều nhận ra vấn đề, nhưng các giải pháp đưa ra đều là các công cụ, không phải là một nền tảng căn bản.

Sự phân mảnh là căn bệnh, không phải vendor lock-in

Sự thất vọng này rất quen thuộc. Bạn xây dựng trên một nhà cung cấp, họ thay đổi giá, loại bỏ API, hoặc đơn giản là không còn công cụ phù hợp nữa, và việc di chuyển trở nên cực kỳ gian khổ. Không phải vì các khái niệm khó hiểu, mà vì mỗi nhà cung cấp "nói" một ngôn ngữ khác nhau.

Câu trả lời hiển nhiên dường như là sự trừu tượng hóa (abstraction). Xây dựng một lớp ở trên cùng. Đó là những gì Terraform, SST và hàng chục công cụ khác đã cố gắng làm. Tuy nhiên, các lớp trừu tượng này thực chất không giải quyết vấn đề, chúng chỉ chuyển dịch nó. Bạn vẫn phụ thuộc vào người khác để bắt kịp mọi nhà cung cấp, vẫn chờ đợi plugin được viết, và vẫn chỉ một thay đổi giấy phép là bạn quay lại vạch xuất phát.

Các tiêu chuẩn cạnh tranh

Nguyên nhân gốc rễ nằm ở chỗ không có sự tương thích giữa các nhà cung cấp hạ tầng và nền tảng để cung cấp bất cứ thứ gì. Không có cách nào để có một triển khai duy nhất hoạt động xuyên suốt GCP, AWS, Azure hay OCI. Nhưng tôi sẽ định nghĩa nguyên nhân gốc rễ một cách khác: Không có một cách chuẩn để một dịch vụ mô tả chính nó.

Bài học từ ngôn ngữ lập trình

Sau đó, tôi có một suy nghĩ đã thay đổi hoàn toàn cách nhìn nhận vấn đề này. Thực tế đây là một bài toán đã được giải quyết trong phần mềm. Swift có Protocols, Go có Interfaces, Haskell có typeclasses. Bạn viết mã nói rằng: "Tôi không quan tâm cái này là gì, miễn là nó có thể làm những việc này". Bạn code dựa trên hình dạng (shape), không phải dựa trên cách triển khai (implementation). Thay đổi kiểu dữ liệu nền tảng và mã của bạn vẫn biên dịch được.

Nếu nó đi như một con vịt và kêu như một con vịt, hãy đối xử với nó như một con vịt. Chìa khóa ở đây là nó đảo ngược sự phụ thuộc. Thay vì mã của bạn phụ thuộc vào một triển khai cụ thể, các triển khai sẽ phụ thuộc vào việc thỏa mãn một hình dạng chia sẻ. Các nhà cung cấp mới có thể xuất hiện mà không cần thay đổi gì ở thượng nguồn. Các ngôn ngữ lập trình đã có thứ này từ hàng thập kỷ nay, nhưng web chưa bao giờ có một tương đương được chấp nhận rộng rãi ở biên giới mạng.

OpenBindings: Interface cho biên giới mạng

Đó chính là lý do OpenBindings ra đời. Một thông số kỹ thuật mở để mô tả những gì một dịch vụ có thể làm, có thể di chuyển qua các giao thức và môi trường. Cốt lõi của nó là một tài liệu gọi là OBI (OpenBindings Interface).

Kiến trúc các lớp của OBI

Operations định nghĩa những gì dịch vụ có thể làm, với lược đồ đầu vào và đầu ra. Sources trỏ đến các hiện vật đặc tả kỹ thuật hiện có như tài liệu OpenAPI, file proto, máy chủ MCP, v.v. Bindings ánh xạ các operations đến các điểm nhập cụ thể trong các nguồn đó. Mục đích toàn bộ là tách biệt ý nghĩa (meaning) khỏi cách truy cập (access). Operation được định nghĩa một lần, sau đó được ràng buộc với bất kỳ giao thức nào mà nhà cung cấp thực sự sử dụng.

Hai nhà cung cấp có thể triển khai cùng một giao diện và một công cụ có thể xác minh tính tương thích của họ mà không cần chạy một yêu cầu nào. Giống như Go interfaces, nhưng ở biên giới mạng.

Tại sao lại là bây giờ?

Các đặc tả như OpenAPI, AsyncAPI, gRPC và MCP đã làm phần việc khó khăn là mô tả cấp giao thức. Không cái nào trong số chúng cần được thay thế. Điều còn thiếu là một lớp ở trên chúng kết nối các mô tả lại với nhau và nói rằng "đây là cùng một khả năng".

Tôi biết điều này nghe thế nào. Có lẽ bạn đang nghĩ đến truyện tranh XKCD về 15 tiêu chuẩn cạnh tranh. Nhưng OpenBindings về mặt cấu trúc không thể thay thế OpenAPI, gRPC hay MCP. Một OBI không có sources và bindings trỏ đến các đặc tả đó chỉ là một hợp đồng chưa được ràng buộc, không phải là một giao diện có thể hành động được. Sự phụ thuộc chỉ chạy một chiều. Những đặc tả đó là đầu vào, không phải đối thủ.

Và đúng là điều này đã được thử trước đây. WSDL, UDDI, CORBA đều thất bại, nhưng vì những lý do không hoàn toàn áp dụng ở đây. WSDL được xây dựng cho kỷ nguyên SOAP và không bao giờ thoát khỏi nó. UDDI yêu cầu đăng ký thủ công vào một registry trung tâm. CORBA cần hạ tầng thời gian chạy ở cả hai đầu. OBI chỉ là một file JSON. Sự khác biệt khác là thời điểm. Trong kỷ nguyên WSDL, hầu hết các dịch vụ chỉ nói một giao thức. Ngày nay, một dịch vụ đơn lập thường xuyên lộ REST, gRPC, MCP và GraphQL cùng một lúc. Thực tế đa giao thức này là mới, và đó là vấn đề cụ thể mà OpenBindings được thiết kế để giải quyết.

Giá trị thực tế ngay hôm nay

Bạn không cần hệ sinh thái chấp nhận để có giá trị từ điều này. Nếu bạn có một đặc tả hiện có, CLI ob sẽ tạo ra một OBI từ nó:

$ ob create openapi.json

Điều này cũng tương tự cho máy chủ gRPC, điểm cuối MCP hoặc file proto. Một lệnh duy nhất và dịch vụ của bạn có một tài liệu giao diện di động. Khi đặc tả nguồn thay đổi, bạn chỉ cần tạo lại. Đó là một bước xây dựng, không phải là một ánh xạ thủ công.

OBI duy nhất mang lại cho bạn những điều cụ thể ngay lập tức:

• Thực thi thống nhất qua các giao thức: Một tên operation, một lược đồ đầu vào. Trình thực thi binding cho mỗi định dạng xử lý các chi tiết giao thức. Các công cụ của bạn không bao giờ chứa mã giao thức.
• Khả năng khám phá: Công bố tại /.well-known/openbindings và bất kỳ công cụ nào có thể tìm thấy các operations, lược đồ và phương thức truy cập của bạn mà không cần đọc tài liệu hay đoán các điểm cuối.
• Cấu trúc có thể đọc được bằng máy cho AI: Một LLM khám phá OBI của bạn sẽ nhận được các operations được định kiểu và bindings thay vì phải phân tích cú pháp tài liệu. Nó có thể gọi dịch vụ của bạn đúng ngay từ lần thử đầu tiên.

Thử nghiệm ngay

Bạn có thể cài đặt CLI và chạy bản demo tích hợp để xem điều này hoạt động trong chưa đầy một phút:

brew install openbindings/tap/ob ob demo # starts a coffee shop service on six protocols ob op exec http://localhost:8080 getMenu # calls it via REST ob op exec http://localhost:8080 getMenu --binding getMenu.grpcServer # same operation, gRPC

CLI đã tìm nạp OBI từ localhost:8080/.well-known/openbindings, tìm thấy operation, chọn một binding và thực hiện cuộc gọi. Không cần cấu hình, không cần kiến thức trước về dịch vụ, không cần mã giao thức.

Đặc tả là mở. CLI ob xử lý việc tạo, xác thực và thực thi các tài liệu OBI. Các SDK có sẵn cho Go và TypeScript, với các trình thực thi binding cho OpenAPI, gRPC, MCP, GraphQL, Connect và AsyncAPI.