DevOps の採用により、組織は開発ライフサイクルの早い段階で意思決定やタスクをシフトすることで、開発プロジェクトにおけるリスクを特定して低減できることを認識しています。このプロセスは「シフトレフト」と呼ばれています。その結果、現代のデベロッパーは、顧客に機能をリリースするためにそれ以上のことを求めています。スケーラブルなソフトウェア アーキテクチャの設計、安全でパフォーマンスの高いコードの開発、インフラストラクチャの設定、テストの実施、アプリケーションのデプロイとモニタリングなどを行うことが求められています。このアプローチは多くのメリットをもたらしますが、デベロッパーがコードの記述に集中できる時間も減るため、ソフトウェアの品質に望ましくない影響が及んだり、新機能のリリースが遅れたりする可能性があります。
DevOps エンジニアが外部顧客へのソフトウェア デリバリーの最適化に注力するのと同じように、プラットフォーム エンジニアは、内部の顧客(つまりデベロッパー)に一貫性のあるシームレスなエクスペリエンスを提供するプラットフォームの構築に注力します。社内プラットフォームの構築とはどのようなものですか?日常的なタスクには、自律性を可能にする標準化されたエクスペリエンスをデベロッパーに提供することが含まれます。これにより、新しいサービスを開発、デプロイする際の社内顧客の目に見える負荷が軽減されます。社内のデベロッパー プラットフォームには、デベロッパーにとってのゴールデンパスを作成するための特定の決定事項、標準、プロセスが組み込まれています。これにより、デベロッパーはコーディングに集中できるため、顧客に対して優れたソフトウェア エクスペリエンスを作成することができます。言い換えると、組織はシフトレフトに加えて、「シフトダウン」も行い、プラットフォームにより多くの責任を押し下げることが求められます。
デベロッパーがプラットフォームを最大限に活用できるように API を開発する場合は、次のことを行う必要があります。
優れたアプリケーションは、物品やサービスの提供に気を配り、一貫性を持たせています。複雑さが隠され、オペレーションがシームレスで使うのが楽しくなります。最終目標は常にユーザーに優れたエクスペリエンスを提供することです。優れたプロダクトを構築する組織は常に、ユーザーを念頭に置いた「外側」からスタートします。優れたエクスペリエンスを提供するには、デベロッパーが魅力的なアプリケーションを作成できるように支援します。そのためには、優れた API を提供することが不可欠です。優れた API は組織の複雑さを抽象化するため、デベロッパーはユーザー エクスペリエンスの構築に集中できます。しかし、優れた API は突然現れるわけではありません。また、こうした組織は API をデジタル プロダクトのように扱っており、チーム全体がプラットフォームの重要な機能として作成と管理に専念しています。
デベロッパーがデジタル プロダクトの構築に使用するプラットフォームもプロダクトとして扱う必要があります。そのため、プラットフォーム エンジニアリング チームも、要件を理解し、快適なエクスペリエンスを作成するために、ユーザー(すなわちデベロッパー)に対してアウトサイドイン アプローチを取る必要があります。プラットフォーム エンジニアは、フロントエンド アプリの開発、バックエンド サービスの開発、API の開発と使用など、デベロッパーがソフトウェアを構築する際に活用する内部テンプレートやツールの作成、構築、統合する責任を負います。チームの役割は、組織が作成するソフトウェアのテスト、保護、デプロイ、管理の仕組みを確立することです。サイロ化の解消は API 作成の効率化につながります。
ソフトウェア開発の他の側面と同様に、チームは、デベロッパーが横断的な懸念事項となる API アーキテクチャの要素を個別に再作成しないようにする必要があります。代わりに、すぐに使えるシンプルなツールと構成オプションのセットを提供します。API 管理の一部の側面には、お使いのプラットフォームで最適に処理できるものとして、次のものがあります(ただし、これらに限定されません)。
Apigeeは、プラットフォーム チームとその内部の顧客に、API をより効果的にビルド、管理、運用するための一連の機能を提供する API 管理プラットフォームです。
Apigee は、セキュリティ、検出、オブザーバビリティのレイヤをデベロッパーに追加することで、API プロデューサーがビジネス ロジックを公開する API を構築、管理できるようにします。プロダクト チームは、さまざまな消費行動の柔軟な「プロダクト セット」として API をバンドルして公開できます。Apigee は、API コンシューマが、使用可能な API プロダクトの確認、ドキュメントの閲覧、迅速なオンボーディングを行い、最小限の手間でアプリケーションの開発を開始することにも役立ちます。現在、Apigee は生成 AI の力を借りて API の開発方法も再考しており、経験豊富なデベロッパーも始めたばかりのデベロッパーも、システム間の通信をシームレスに管理できるようになっています。
Apigee で API を管理するプロセスは、API プロキシの構築から始まります。API プロキシは、デベロッパーがバックエンド サービスへのアクセスに使用するインターフェースを公開します。これらのサービスを直接使用するのではなく、プロデューサーが作成した Apigee API プロキシにアクセスします。プロキシを使用すると、バックエンドを実際の API から切り離すことができ、ユーザーにより信頼性の高いエクスペリエンスを提供できます。これにより、顧客に影響を与えることなく、バックエンドの更新や変更を行うことができます。API チームは、プロキシによって提供される機能を活用して、API の動作を保護し、制御できます。API プログラムを制作チームと消費チームの数が増えるにつれて適切にスケーリングするには、プラットフォームが、シームレスな自動化パイプラインと再利用可能な機能を通じてゴールデンパスを実現する必要があります。
たとえば、会社が新たな収益を生み出すために収益化できる新しい API を作成したいと考えているとします。チームとデベロッパーとミーティングを行い、新しい API の作成方法に関する包括的な戦略を策定します。チームの現在の仕事は、これらの要件を、共通のポリシー、トラフィック ルーティング制御、エラー処理規則を含む独自の API テンプレートという形で標準化することです。ユースケースによっては、各ユースケースに対応するテンプレートのセットが用意されている場合があります。一般的なユースケースとしては、オンプレミス環境で実行されている以前のバックエンドにキャッシュ保存や変換ポリシーを提供することが考えられます。apigee-samples リポジトリは始めるのに最適です。DevRel リポジトリにも参照用のサンプル プロキシ テンプレートが含まれています。プラットフォーム チームは、ポリシー テンプレートに加えて、デベロッパーがプロキシの構築とデプロイに使用するパイプラインを標準化することもできます。Apigee には、このようなゴールデンパスをサポートする CI / CD パイプラインの作成に使用できる管理 API とツールが用意されています。Google では、出発点として使用できるリファレンス実装を公開しています。
ソースコードからの MVP API プロキシ パイプラインは次のようになります。
さらに一歩進めて、パイプラインでは、Apigee の API ハブなどの内部カタログに API を登録することもできます。API ハブは、組織が API に関する情報を文書化、検索、公開するのに役立つツールです。ハブに組み込まれたレジストリには、関連する仕様、現在のデプロイ、所有権と連絡先情報、依存関係など、ライフサイクルが進むにつれて API の各バージョンに関する詳細情報が含まれています。組み込みのプロパティに加えて、顧客は検索とフィルタに使用できる独自の分類を定義できます。品質と整合性をさらに高めるために、API ハブでは、API 設計が期待される基準にどの程度達しているかをデベロッパーがよりよく理解できるようにするためのスコアカードも提供しています。API ハブのレジストリは、Backstage などの社内デベロッパー ポータルやその他の社内デベロッパー プラットフォーム ツールに同期できます。
最後に、外部利用者向けに、追加のドキュメントやユーザーガイドとともに、カスタマイズされたスタイルとブランディングを使用して、パイプラインで一般公開の API ポータルに API プロダクトを公開できます。
API を大規模に構築する場合のベスト プラクティスは、共通のポリシーを再利用して開発速度を高め、配信時間を短縮することです。Apigee では、共有フローを使用して API 全体に標準化と整合性を確保できます。共有フローでは、FlowCallout ポリシーまたはフローフックを使用して、ポリシーとリソースを組み合わせて複数の API プロキシ間で共有できます。共有フローは、多くの場合、特定の分野を担当するプラットフォーム チームや対象分野のエキスパートによって、API プロキシとは別に開発されます。たとえば、リクエスト フィールドとレスポンス フィールドの標準的なセットをキャプチャして Cloud Logging に書き込む共有フローを開発できます。もう一つの例は、標準化されたエラー メッセージとコードを出力するエラー処理フローや、サードパーティの ID プロバイダと統合する認証フローです。共有フローの開発は、API プロキシと同じツールとコンセプトを使用して自動化、テスト、デプロイできます。一般的な共有フローのその他の例については、こちらをご覧ください。
GitOps は、DevOps の台頭とともに普及しました。このフレームワークでは、Git を介したバージョン管理、pull リクエスト、CI / CD パイプライン、自動化、コンプライアンス ポリシーを使用するなどのベスト プラクティスを活用しています。API デリバリーのベスト プラクティスについて詳しくは、こちらのブログをご覧ください。こうしたプラクティスは、デベロッパーのゴールデンパスに組み込むことができます。たとえば、デベロッパーは Duet AI を使用して API を設計し、OpenAPI 仕様を作成してから機能ブランチに push すると pull リクエストがトリガーされます。pull リクエストが承認されてマージされると、CI / CD パイプラインが自動的に起動し、このプロセスが環境ごとに繰り返されます。Apigee では、プラットフォーム チームが別々の組織と環境を作成し、開発ライフサイクル全体を通してプロキシをデプロイしてテストできます。GitOps 戦略を使用すると、Git リポジトリの各ブランチを Apigee 環境にマッピングできます。
Apigee の従量課金制モデルを使用しているお客様は、さまざまな機能を持つ異なる環境タイプを選択できます。また、さまざまなユースケースに合わせて幅広い環境タイプを作成できます。
プロキシと共有フローコードをソース リポジトリにホストし、GitOps を使用することで、API デベロッパーが独自のゴールデンパスを作成でき、優れた API の設計と基盤となるビジネス ロジックの実装に集中できます。これをさらに簡単にするために、デベロッパーは VS Code 用の Cloud Code プラグインを使用して、ローカルで開発とテストを行うこともできます。
デベロッパーとプラットフォーム チームのコラボレーションが促進され、デベロッパーがすべてを自分で行う負担から解放されます。複雑さが軽減されることで、デベロッパーは本来の業務に集中でき、顧客のエクスペリエンス向上につながります。API とプラットフォームを組織のプロダクトとして扱うことで、自律性、速度、品質、イノベーションが向上します。上記の戦略を使用することで、デベロッパーの負担を軽減でき、より優れた API の構築を支援できます。準備ができたら無料で登録して、独自の無料サンドボックスで構築を開始できます。料金の詳細をお知りになりたいですか?Apigee の新しい料金をご確認のうえ、デベロッパー プラットフォームへの API 管理の組み込みにリソースをお役立てください。