業界の専門家からなるパネルが、ここ数カ月間の API 環境を形成する主要なトレンドを調査します。
Lori Marshall 著『API Trends: Platform Engineering, the Unbundling and AI's role 』から翻訳。
マーケティング上の誇大宣伝の喧騒の中で、開発者にとって本当に重要なものを見つけるのは難しい場合があります。最近、Ambassador では、API 開発の世界をカバーする業界専門家からなるパネルを選出し、ここ数か月で API 環境を形成している主要なトレンドを調査しました。ここで、実際に注意を払う価値があるのは何なのか、単なる背景ノイズは何なのかを考えてみましょう。
グレートデカップリングについては一般的なコンセンサスはありません
過去 6 か月間、Gartner、Kong、その他の業界専門家が業界で話題にしてきたにもかかわらず、API 管理のグレート デカップリング理論は依然として物議を醸しているトピックです。 「大きなデカップリング」の考え方は、単一の完全なツール スイートから最善のニッチ ソリューションへと移行することに焦点を当てています。当社の専門家の中には、これをより消極的な姿勢と捉えている人もおり、提携している企業のほとんどが、さまざまなAPI 管理ツールを自社の配信パイプラインに統合するために時間、リソース、予算を投資したくないと説明しています。
「私のクライアントの多くは、これらのツールをすべて統合する簡単な方法がないことに非常に不満を感じています。そのため、一部の人が思っているほど簡単ではありません」と、 Launch Any
しかし、別のパネリストであるキース・ケーシーは、この切り離しは、舞台裏で何年も続いてきたことへのうなずきであり、それが公表されたのは初めてだと信じている。同氏は、多くの企業が一連のツールを標準化していると主張しているが、実際には、たとえばマイクロゲートウェイが組織全体に導入されていると指摘した。開発者がどのルートを選択しても、ツールの統合とパッケージ化を改善すれば作業が容易になることに誰もが同意します。つまり、API 開発プロセスに適用する戦略は、テクノロジー スタックに追加するツールの数や不足よりも重要です。
「開発者には人生の 2 つの目標があります。それは、何か役に立つものを作って家に帰ることです。現在、何か役に立つものを作るのを妨げるものがたくさんあるので、家に帰ることができず、イライラしています。」
– Keith Casey 氏、[Pangea] シニア プロダクト マネージャー
API セキュリティにおける AI は両刃の剣です
AI システムが日常のアプリケーションやプロセスにさらに統合されるにつれて、API を通じて交換されるデータはますます機密性が高まり、公開される可能性があり、貴重なものになります。これらの API を保護することは、潜在的な侵害、データ漏洩、不正アクセスを防ぐために重要です。 AI 時代にはセキュリティ侵害の潜在的な影響がより深刻になるため、パネル ディスカッションから得られた明確な結論の 1 つは、 API インフラストラクチャとそこで扱われる機密データを保護するために厳格なセキュリティ プロトコルの実装を優先する必要があるということでした。
Casey 氏は次のように述べています。「『ああ、私たちの API でそんなことをする人はいないだろう』と思うたびに、私たちは過去を振り返って、誰かが私たちの API でそれをするだろうと想定する必要があります。その人が人間ではないかもしれないことに気づきました。」
APIsec Universityの創設者であるパネリストの Dan Barahona 氏は、API と AI の間の継続的な絡み合い関係と、この関係が API セキュリティに与える影響を強調しました。 AI が攻撃ベクトルとして使用される可能性があるという深刻な懸念があります。非常に高度な攻撃を実行することがますます容易になってきています。一方で、AIは防衛や安全保障にも活用される可能性が非常に高いです。
「防御のために AI をどのように活用できるか、そして AI セキュリティ攻撃に対してどのように積極的に防御できるかを考える必要があります。セキュリティ コインの両面を評価する必要があります。すべての API 実務者は、『どうすればよいのか』を自問すべきです。」と Barahona 氏は述べています。 AI をセキュリティ ツールに組み込むことはできますか?」
テクノロジーのリーダーは、開発者がすでに探索およびテストのツールとして AI を多用しており、テクノロジーが進歩するにつれてその使用はさらに増加するだろうと想定する必要があります。今すぐ AI ポリシーとベスト プラクティスを確立し、AI ツールの機能を最大限に活用する方法を深く理解している開発者を雇用しましょう。その一方で、強力な開発者を完全に置き換えることのできるツールは存在しないことを認識してください。
さらに、パネリストは、セキュリティ分野では、受動的なセキュリティ対策を講じることに焦点を当てた物議を醸している「シールド右派」とは対照的に、「セキュリティ左派へのシフト」を強く推し進めているようだと指摘しました。展開されたシステムを潜在的な脅威から保護するために、シフトレフトが必要です。一方、API ゲートウェイ ( https://www.getambassador.io/products/edge-stack/api-gateway/securityなど) のようなツールの早期統合など、脆弱性を防ぐために開発プロセスの初期段階でセキュリティを積極的に統合することを優先します。 -認証) この早期統合により、セキュリティ問題に早期に対処するという「シフトレフト」の哲学と一致して、セキュリティ機能を開発プロセスに組み込むことができます。
センター・オブ・エクセレンスからセンター・オブ・エンパワーメントへ
プラットフォーム エンジニアリングが世界を席巻している中、私たちはまずブレーキをかけて基本を正しく理解する必要があります。プラットフォーム チームやセンター オブ エクセレンス (COE) に関する誤解は、彼らが DevOps の課題に対するソリューションの不可欠な部分ではなく、象牙の塔から発言しているというものであることがあります。パネリストは、焦点を「このプラットフォームをどのように管理するか?」から「人々の生産性を高めるにはどうすればよいか?」へと進化させる必要があることに同意しました。
「少し一歩下がって、プラットフォーム エンジニアリングの流行から離れてみましょう。現在、プラットフォーム エンジニアリングは非常に社内に焦点を当てており、大規模になっています。プラットフォームについて話す前に、開発者のために自動化を実現するための多くの作業を行う必要があります。ヒギンボザムの共有道路。 「API のイネーブルメントに焦点を当て、イネーブルメント センターまたはセンター オブ エクセレンスに目を向けて話を進めましょう。」
Casey 氏も Higginbotham 氏の意見に同調し、Center for Enablement (C4E) への移行が現実世界のプラットフォーム エンジニアリングの成功の鍵であると述べました。彼は、人々に奉仕し、生産性の向上を支援するという考え方と、高レベルのステートメントを発行し、開発者がそれに盲目的に従うことを期待する従来のアプローチを対比させました。
「COE は、API を実装して提供するコードに重点を置くのではなく、API 設計者、プロビジョニング チーム、および消費者を可能にすることに重点を置いています」と Higginbotham 氏は共有しました。
たとえば、API を構築しているチームがある場合、その API を使用する組織内に 150 の異なるチームが存在する可能性があります。これは、無駄のないプラットフォーム チームがなければ、まったく同じ会話をするたびに、それらの 150 人の関係者と作業することになる可能性があることを意味します。
COE アプローチを採用する強固なプラットフォーム チームに投資するということは、適切なドキュメント、サポート、コード サンプル、およびこれらの会話を完全に削減または排除できるその他のリソースに投資することを意味します。さらに、これらのリソースにより、消費者が API を使い始めることができるようになります。
したがって、結論は次のとおりです。はい、最初に配信の実現と開発者の実現に重点を置く限り、API 開発においてプラットフォーム エンジニアリングの重要性はますます高まっています。 API の真の成功を達成するには、プラットフォーム戦略と COE が連携する必要があります。
やっと
これらは新しい概念ではありませんが、API 開発リーダーがこれらの傾向に対して取るアプローチとデューデリジェンスは、開発者が前向きに対応できるかどうかに大きな違いをもたらします。詳細については、YouTube チャンネルで API 管理チームによる技術的なディスカッションの全文をご覧ください。
Google Python Foundation チームが解雇されたことを Google が確認し、Flutter、Dart、Python に関与するチームが GitHub のホット リストに殺到しました - オープンソースのプログラミング言語とフレームワークはどうしてこんなにも魅力的なのでしょうか? Xshell 8 が ベータ テストを開始: RDP プロトコルをサポートし、Windows 10/11 にリモート接続 できる Rail WiFi の最初の長期サポート バージョン 8.4 GA AI 検索ツール Perplexica : 完全にオープンソースで無料、Perplexity の代替となるオープンソースの価値をファーウェイ幹部が評価 : 継続的な抑制にもかかわらず、依然として独自のオペレーティング システムを持っています。ドイツの自動車ソフトウェア会社 Elektrobit が、Ubuntu をベースとした自動車オペレーティング システム ソリューションをオープンソース化しました。この記事はYunyunzhongsheng ( https://yylives.cc/ ) で最初に公開されたもので、どなたでもご覧いただけます。