Trong các cuộc khảo sát của tôi về các doanh nghiệp, con số lo lắng về sự khóa cửa của nhà cung cấp đã dao động khoảng 90% trong 30 năm. Khi bạn hỏi các doanh nghiệp làm thế nào để họ tránh được điều đó, họ trả lời “giao diện tiêu chuẩn” hoặc “mã nguồn mở”. Ngay cả ngày nay, tỷ lệ bao gồm “quản lý API” trong danh sách các biện pháp tránh khóa trong mức nhiễu thống kê, nhưng API có lẽ là vấn đề khóa phát triển nhanh nhất hiện nay và chúng chắc chắn sẽ trở thành vấn đề lớn trong tương lai.
API là viết tắt của “giao diện lập trình ứng dụng”, nhưng thuật ngữ này được sử dụng rộng rãi trong phần mềm ngày nay để mô tả các giao diện giữa tất cả các thành phần phần mềm được sử dụng trong một ứng dụng, đám mây hoặc thậm chí là mạng. API cho phép các phần mềm trò chuyện với nhau và chúng rất cần thiết trong mọi tình huống khi các thành phần phần mềm chứ không phải thiết bị phần cứng được kết nối. Điều tạo ra thách thức trong việc khóa API ngày nay là thực tế là mạng đang chuyển nhiều hơn sang phần mềm, có nghĩa là nó đang chuyển sang một mô hình mà API cũng quan trọng như các giao diện tiêu chuẩn đó và các doanh nghiệp không theo dõi sự thay đổi quan trọng đó.
Bên trong một thiết bị mạng, bạn có thể tìm thấy bốn lớp phần mềm. Ở phía dưới, có người lái xe cung cấp một cách chung để liên kết những thứ như chip giao diện Ethernet với phần còn lại của phần mềm. Trên đó, có một hệ điều hành mạng (NOS) cung cấp khả năng lưu trữ chung và trên đó là “phần mềm trung gian” xử lý các tính năng mạng cụ thể cần thiết. Trên hết là các ứng dụng phụ thuộc vào mạng, bao gồm các tính năng quản lý và dịch vụ như truyền thông hợp nhất hoặc giảm thiểu từ chối dịch vụ. Mỗi lớp này hiển thị các API cho các lớp khác.
Chúng ta đã quen với các giao diện phần cứng khác nhau, Ethernet hoặc mạng quang thụ động hoặc thậm chí là không dây và mọi người đều hiểu rằng bạn không thể cắm một thiết bị đầu vào nhầm lẫn hơn là bạn có thể cắm cáp Ethernet vào Cổng USB. Điều làm cho các API trở nên khác biệt là không có trình kết nối vật lý nào ngăn bạn thử. Một API đại diện cho một đặc tả trao đổi tin nhắn. Mọi khía cạnh của định dạng thông báo, cấu trúc dữ liệu, đồng bộ hóa yêu cầu / phản hồi, v.v., đều được quy định trong thông số kỹ thuật API và tất cả chúng phải khớp nhau nếu không phần mềm sử dụng API sẽ không giao tiếp chính xác. Nói cách khác, các API không khớp sẽ phá vỡ phần mềm, bao gồm cả phần mềm bên trong thiết bị và trung tâm quản lý mạng.
Các nhà cung cấp biết điều này và nhiều người (đặc biệt là trong không gian quản lý mạng) cấp phép cho các API của họ. Điều đó có nghĩa là doanh nghiệp chỉ có thể sử dụng các API dựa trên các điều khoản cấp phép. Có thể không thể đính kèm phần mềm từ một nhà cung cấp khác vào một API được cấp phép, ngay cả khi bạn phát triển phần mềm bộ điều hợp để làm điều đó mà không vi phạm các điều khoản cấp phép. Nếu bạn xây dựng phần mềm theo API được cấp phép và sau đó thay đổi phần mềm, bạn có thể mất quyền sử dụng API. Tôi đã thấy vấn đề cụ thể này xảy ra tại một công ty dịch vụ tài chính và họ đã mất hàng tháng để giải quyết vấn đề này.
Ngay cả khi các nhà cung cấp không sử dụng API cụ thể để khóa bạn, các API có thể tạo ra sự khóa không cố ý. Bạn có nhớ bốn lớp phần mềm đó không? Có thể mọi lớp đều sử dụng các API NOS. Hầu hết các NOS sẽ sử dụng API trình điều khiển và phần mềm trung gian có thể sẽ sử dụng cả API NOS và API của các gói phần mềm trung gian khác. Tất cả điều này tạo ra một mạng lưới kết nối với nhau, phải không? Bây giờ, giả sử rằng nhà cung cấp NOS của bạn thay đổi API của họ. Nhà cung cấp phần mềm trung gian chính của bạn tiếp nhận thay đổi và hỗ trợ nó, nhưng một hoặc nhiều nhà cung cấp phần mềm trung gian khác thì không. Nếu bạn cài đặt NOS mới, bạn sẽ phá vỡ tất cả phần mềm trung gian không hỗ trợ thay đổi API. Nếu không, bạn sẽ mất các tính năng NOS mới và bất kỳ tính năng mới nào của nhà cung cấp phần mềm trung gian duy nhất hỗ trợ API NOS mới.
Ngay cả phần mềm nguồn mở cũng có vấn đề về API. Hầu hết các giấy phép nguồn mở không cấm tùy chỉnh, họ chỉ yêu cầu mã nguồn phải được cung cấp. Nhà cung cấp NOS nguồn mở hoặc phần mềm trung gian, hoặc công cụ phần mềm quản lý mạng, có thể tùy chỉnh một số API, phát hành mã nguồn và tương thích với các điều khoản cấp phép nguồn mở. Nhưng các phần mềm khác, vẫn mong đợi các API tiêu chuẩn cho phần mềm, sẽ không hoạt động với nó nữa.
Tôi đã gặp sự cố này với Linux, có một số bản phân phối bao gồm Linux và các thành phần phần mềm trung gian khác nhau. Ví dụ: bạn có thể có một ứng dụng bạn muốn chạy trên Linux sử dụng Python. Distro “A” có thể bao gồm một phiên bản Python và Distro “B” có thể bao gồm một phiên bản khác. Nếu bạn có một ứng dụng / công cụ sử dụng Python và nếu các API Python thay đổi giữa các phiên bản, có thể không có cách nào để viết phần mềm có thể di động trên nhiều bản phân phối.
Bạn kết nối phần cứng với các giao diện vật lý. Bạn kết nối phần mềm với các API. Nếu mạng, cả ở cấp độ hoạt động mạng và trong các thiết bị được phân tách, đang tách phần mềm khỏi phần cứng và xây dựng chức năng bằng cách kết hợp các gói phần mềm, thì bạn cần phải chú ý nhiều đến các API như bạn làm đối với các giao diện vật lý, thậm chí có thể nhiều hơn.
Làm sao?
Bước đầu tiên là yêu cầu tất cả các sản phẩm phần mềm bao gồm mô tả đầy đủ về tất cả các API mà chúng tiếp xúc và sử dụng. Mô tả đó phải bao gồm tham chiếu đến bất kỳ tiêu chuẩn nào mà họ yêu cầu hỗ trợ và mô tả đầy đủ về bất kỳ cải tiến hoặc tiện ích mở rộng nào. Nó cũng phải bao gồm các điều khoản cấp phép, nếu có, được liên kết với từng API và bạn nên yêu cầu mã mẫu sử dụng API để xác nhận cách hoạt động của nó. Rõ ràng, nếu bạn định kết nối Gói A và Gói B thông qua một API, thì mô tả API của chúng phải khớp hoàn toàn hoặc bạn phải tránh các tình huống (như các tính năng hoặc lệnh cụ thể) sẽ gọi một tiện ích mở rộng mà cả hai gói đều không t hỗ trợ.
Bước thứ hai là lấy lịch sử phiên bản trên phần mềm khi có bất kỳ thay đổi API nào. Những gì bạn đang tìm kiếm là lịch trình về cách các thay đổi thấm qua nhiều gói phần mềm. Nếu nhà cung cấp Gói A hỗ trợ rất nhanh các API mới và nhà cung cấp Gói A cạnh tranh thì chậm, thì bạn có thể mong đợi các vấn đề phát sinh nếu thay đổi API được thực hiện và bạn chọn nhà cung cấp phản hồi chậm. Bạn không thể cập nhật phần mềm của mình mà không làm đứt một số kết nối API cho đến khi tất cả các nhà cung cấp sử dụng API đều ở trên cùng một trang.
Bước cuối cùng là hợp đồng hóa các giả định của bạn. Ngay cả nghiên cứu tốt nhất cũng có thể bỏ sót những thay đổi trong chính sách hoặc hướng đi và nếu nhà cung cấp phần mềm thay đổi API, kết quả có thể phá vỡ ứng dụng hoặc mạng. Nhận những lời hứa được viết thành một điều khoản hợp đồng.
Một thiết bị mạng hoặc ứng dụng là một ví dụ về định nghĩa cổ điển về “hộp đen”, một vật thể mờ đục và do đó không thể kiểm tra chi tiết cấu trúc của nó. Hộp đen được định nghĩa, vì vậy câu nói này đi, bởi mối quan hệ giữa đầu vào và đầu ra của chúng. Phần mềm thực sự được xác định bởi mối quan hệ giữa các API đó, những API mà mọi người không chú ý nhiều như họ nên làm. Nếu bạn muốn tránh bị nhà cung cấp khóa, cố ý hoặc tình cờ, thì bạn cần phải xem xét nghiêm túc các API.
Bản quyền © 2021 IDG Communications, Inc.
