5

Để thu thập thông tin chi tiết về tình trạng quản lý API hiện tại và tương lai, chúng tôi đã yêu cầu các chuyên gia CNTT từ 18 công ty chia sẻ suy nghĩ của họ. Chúng tôi hỏi họ, "Bạn có bất kỳ mối quan tâm nào về tình trạng quản lý API hiện tại không?" Đây là những gì họ nói với chúng tôi:

Thiết kế đầu tiên

  • Rất nhiều công cụ tuyệt vời đã có sẵn để xây dựng và triển khai các API. Tuy nhiên, thiết kế ưu tiên đã không được áp dụng rộng rãi như người ta có thể hy vọng. Nhiều lần, các nhà phát triển được yêu cầu cung cấp một API và họ chỉ làm điều đó. Người đưa ra yêu cầu đối với API có thể có nhu cầu rất hẹp và nhà phát triển có thể dễ dàng kết hợp một thứ gì đó lại với nhau để đáp ứng nhu cầu đó, nhưng sau đó, những người dùng bổ sung sau đó truy cập vào API và nó xuất hiện theo một cách nào đó. 
  • Một vấn đề có thể phát sinh là làm chậm các ứng dụng. Trong một số trường hợp như tạo tài khoản, không có gì lạ khi phải giao tiếp với nhiều API để thông báo hành động. Ví dụ: gửi một yêu cầu tới API phân tích, một yêu cầu khác tới bộ xử lý thanh toán để thêm người dùng mới, một yêu cầu thêm người dùng mới này vào dịch vụ trò chuyện & hỗ trợ và cuối cùng, một yêu cầu gửi email chào mừng.

    Nếu những yêu cầu này được thực hiện khi tạo tài khoản, điều này có thể tổng hợp thành các yêu cầu ban đầu có thể nhanh chóng mất vài giây để hoàn thành và có thể gây ra sự cố. (Điều gì sẽ xảy ra nếu hai yêu cầu đầu tiên thành công, nhưng không phải là yêu cầu cuối cùng? Làm thế nào chúng ta có thể thử lại chúng? Ưu tiên yêu cầu nào?). Đó là lý do tại sao việc triển khai một số lệnh gọi không đồng bộ tới các API bên ngoài bất cứ khi nào có thể, với các cơ chế thử lại và hệ thống cảnh báo là một cách tuyệt vời để giảm thiểu những vấn đề này. 
  • Mối quan tâm hàng đầu là thị trường đã chín muồi để củng cố. Các giải pháp chỉ mới 5-10 năm tuổi đã có kiến ​​trúc “kế thừa” không thể bắt kịp với các mẫu kiến ​​trúc mới như microservices. Khách hàng cần phải cẩn thận, họ không xây dựng các khả năng API của mình xung quanh một giải pháp sẽ cần được loại bỏ và thay thế chỉ trong vài năm.

Quản lý phiên bản

  • Xử lý các hợp đồng API và đặc tả API mở cho bạn biết API có thể làm gì. Quản lý phiên bản hoặc thay đổi phiên bản đối với API vẫn là một thách thức. Các cách giao tiếp phát triển theo cấp số nhân không phải là một cách tuyệt vời để xử lý. Di chuyển quá nhanh với các tính năng mà người tiêu dùng phải hỗ trợ nhiều phiên bản cùng một lúc.

Thiếu các phương pháp hay nhất

  • Rất nhiều tiến bộ đã được thực hiện trong vài năm qua. Các nhà cung cấp đám mây lớn đang làm nhiều hơn thế. Vẫn còn một đường cong học tập lớn cho các nhà phát triển mới. Có rất nhiều API ngoài kia không sử dụng các phương pháp hay nhất. Đối với sự phát triển của các hệ thống mới, việc tích hợp các API vẫn là một mối quan tâm lớn. 
  • Vì vậy, phần lớn việc quản lý API vẫn tập trung vào bên ngoài khi có giá trị to lớn trong các trường hợp sử dụng nội bộ. Tập trung vào việc xây dựng một chương trình nội bộ tập trung vào các nhà phát triển nội bộ của bạn. Cung cấp cho các nhà phát triển nội bộ thông tin họ cần để tận dụng các dịch vụ và tránh xa. Giúp các nhà phát triển của bạn hoàn thành công việc của họ. Nếu bạn tạo cổng thông tin đó cho khán giả nội bộ của mình, nơi mọi thứ đều được ghi chép đầy đủ và bạn đang hướng dẫn họ đường đi để hoàn thành công việc, thì điều đó sẽ mang lại lợi ích lâu dài cho các nhóm nội bộ và tạo ra một chiến lược đổi mới mà ít sợ thất bại hơn.
  • Vẫn cần quá nhiều công việc của khách hàng để kết hợp một sản phẩm API tốt với nhau, bố cục của nhà cung cấp có thể phức tạp và không trực quan. Rất nhiều thuật ngữ và danh mục sản phẩm khá mới và không theo tiêu chuẩn. Khi các nhà xuất bản chuyển trọng tâm của họ từ nhu cầu xuất bản và tập trung nhiều hơn vào trải nghiệm nhà phát triển của người tiêu dùng, mọi thứ sẽ được cải thiện.
  • Việc thiếu các tiêu chuẩn được ghi chép đầy đủ, đặc biệt là khi nói đến việc lập phiên bản API.

Khác

  • Làm thế nào để bạn đạt được sự cân bằng giữa tính linh hoạt và tối ưu hóa? Đám mây công cộng là một nơi tốt để bắt đầu với lượng dữ liệu nhỏ nhưng với lượng dữ liệu lớn, nó bắt đầu trở nên phức tạp. Chúng tôi đang làm việc để giải quyết mô hình thông lượng của các API hiện tại. Công việc vẫn cần thiết trên mặt trận đó. Với kiến ​​trúc microservices, nó trở nên phức tạp hơn vì một dịch vụ phụ thuộc vào nhiều dịch vụ khác. Các công cụ như Istio và LinkerD trở nên quan trọng hơn đối với việc ngắt mạch và hết thời gian chờ nếu không nó sẽ trở thành một mớ hỗn độn hoàn toàn.
  • Quản lý API là một lĩnh vực hơi trưởng thành. Các khối chức năng chính khá rõ ràng - cổng vào, cổng thông tin, phân tích, khả năng kiếm tiền, giá trị khóa ngày nay là mức độ hiệu quả của các phần này tích hợp với nhau để triển khai và nhận giá trị từ cơ sở hạ tầng API. 
  • Lĩnh vực đang nỗ lực: các công cụ, kỹ thuật, thực hành bổ sung, các tác nhân xuất hiện thường xuyên - trong khi những công cụ hiện có vẫn đang được cải thiện. Những ngày mà không rõ liệu bán một API có thể là một ý tưởng hay hay không, đã qua lâu rồi.
  • Tôi nghĩ rằng thường tập trung quá nhiều vào việc nhanh chóng "đẩy" các API ra và đưa chúng trực tuyến mà không có nỗ lực có chủ đích để tạo ra một nền văn hóa ưu tiên API vững chắc. Các cân nhắc về thời gian chạy chẳng hạn như bảo mật chắc chắn là quan trọng, nhưng mọi thứ xảy ra trước khi một API được triển khai và chạy trong sản xuất cũng quan trọng không kém và thường bị bỏ qua. 
  • Các công cụ APIM hiện tại tập trung nhiều hơn vào nhà cung cấp và người tiêu dùng là người phải cân nhắc sau. Chúng tôi muốn trao quyền cho các nhà phát triển API biết có bao nhiêu yêu cầu được thực hiện bởi người tiêu dùng trong một khung thời gian nhất định. Chúng tôi cũng muốn người tiêu dùng có thể xử lý các tình huống như ngừng hoạt động, thay đổi API hoặc ngừng hoạt động, v.v.

    Thường không có phương pháp rõ ràng để các nhà phát triển truyền đạt thông tin này cho người tiêu dùng API một cách kịp thời và sau này thường được để lại trong bóng tối. Việc tiết lộ thông tin này đang trở nên quan trọng hơn trong nền kinh tế API ngày nay. Ngoài ra, việc thiếu kiểm tra API (Hợp đồng, Tự động, v.v.) là điều cũng sẽ cần được giải quyết. Việc triển khai thử nghiệm thích hợp sẽ đảm bảo ít khả năng xảy ra các thay đổi trong tích hợp phá vỡ API, độ tin cậy và khả năng kiểm tra trên quy mô lớn. 
  • Quản lý API không phải là một cái gì đó mới. Cửa ngõ kiểu cũ nằm ngoài đó. Thật khó để quản lý. Xu hướng đang xảy ra trên thị trường mà bạn thấy cổng API thế hệ tiếp theo nhẹ hơn nhiều và điểm cuối là proxy, mã nguồn mở để xem những gì đang xảy ra, quen thuộc với kỷ nguyên microservices. Sử dụng sao lưu K8s theo mặc định. Mọi người đang trình bày sai về những gì nền tảng của họ sẽ làm - cho thấy họ có thể tạo điều kiện thuận lợi cho các dịch vụ nhỏ trong khi họ vẫn đang chạy các ứng dụng nguyên khối, cũ. 
  • Chúng ta đang bước vào kỷ nguyên microservices khoảng một thập kỷ, nhưng vẫn còn rất ít công cụ và thực tiễn để hỗ trợ các công ty đang cung cấp các API microservice trực tiếp cho khách hàng. Ở cấp độ tiêu chuẩn, tùy chọn duy nhất mà thông số kỹ thuật OAuth2 cung cấp là Phạm vi và những tùy chọn này không đủ cho các API dịch vụ vi mô. Trong bất kỳ điều gì ngoài việc triển khai tầm thường, bạn cần phải lý giải về các tài nguyên mà người gọi có thể truy cập.

    Việc thiếu các tiêu chuẩn xung quanh vấn đề này khiến cho việc ủy ​​quyền và kiểm soát truy cập trở thành vấn đề mà không có giải pháp chung, vì vậy mọi người đều phải tự viết mã hoặc viết mã cho thiết kế của nhà cung cấp. Do sự bất đối xứng của việc thay đổi giao diện API (và mô hình truy cập của bạn là một phần hoàn toàn quan trọng trong giao diện của bạn), chúng tôi sẽ gặp khó khăn với các triển khai độc quyền này trong nhiều năm tới. 
  • Nhiều công cụ ước tính chi phí API có sẵn và ít người hiểu được chi phí dài hạn mà họ đang áp đặt cho bản thân và khách hàng của họ thông qua các API của họ. Một ước tính thận trọng là $ 25K để xây dựng một API và $ 15K để khách hàng của bạn tích hợp với nó. Cộng thêm 50% hàng năm để duy trì nó. Điều này có nghĩa là một ứng dụng có 100 API được 100 người tiêu dùng của bạn sử dụng sẽ tạo ra khoảng 15.000.000 đô la chi phí chủ yếu cho khách hàng của bạn.

Đây là người đã chia sẻ thông tin chi tiết của họ:

|