ガードレールを使用したセルフサービスにより開発者を支援する
ガードレールを使用したセルフサービスの原則に従うと、開発チームは明確に定義された一連のパラメーターまたはガードレール内で独自に決定を下すことができるようになります。 ガードレールは主要な利害関係者によって確立され、合意されています。 利害関係者には、組織全体のセキュリティ、運用、アーキテクチャのチームが含まれる場合があります。
ガードレールを使用したセルフサービスによって、開発チームは独立して開発に関する決定を下すことができます。 自動化とポリシーは、関係者がセキュリティ、コンプライアンス、運用、標準、コストを適切に管理するのに役立ちます。 この自動化を有効にするには、開発者、オペレーター、スペシャリストが必要なガバナンスを犠牲にすることなく、より多くのことを実行できるように、チームライン全体のコラボレーションを実現する必要があります。 これにより、開発者は最速でビジネス価値を提供することに集中できます。
[開発者の皆さんへ] すべての動作を心配する必要はありません。オンとオフを切り替えて、入力し、必要に応じて文字列を追加するだけです。作業は基本的にセルフサービスで完了します。提供された readme ファイルや入出力データを活用して、自由に開発を行ってください。 - Daniel、クラウド エンジニア、Fortune 500 メディア企業
セルフサービス エクスペリエンスを考慮したプロセスを確立することで、開発者の作業負担を軽減するだけでなく、開発、運用、管理チームが開発状況を視覚的に確認できるようになります。 これは、基盤となる自動化やデータ集計の機能を活用することによって、特定のタスクに関して学習コストを最小化したエクスペリエンスを実現するというアイデアです。 これらのエクスペリエンスは、インフラストラクチャのプロビジョニングなどのアクティビティだけでなく、監視、ポリシー、インシデント管理などの重要な機能へのアクセスも可能にします。 また、このアイデアは、内部 API、SDK、共有ツールやサービスの検出および共有にも役立ちます。 これらのエクスペリエンスによってオーバーヘッドが軽減されるため、開発チームは集中して作業を完了できます。
開発者にデジタル ストアと同様の機能を提供する内部開発者プラットフォーム
内部開発者プラットフォームは、企業間のデジタル ストアと同様の機能を提供します。 デジタル ストアは、本質的に顧客のセルフサービスを支援するように設計されています。 デジタル ストアでは、顧客が誰かと話すことなく自力で興味のあるアイテムを見つけて購入するため、一般的な実店舗よりもスループットが高くなります。 この例を参考にすると、開発者は顧客と同じ立場にあり、内部開発者プラットフォームでもデジタル ストアと同様のセルフサービス エクスペリエンスを提供する必要があります。 オペレーター、プラットフォーム エンジニアなどの役割にある人物は、小売業者が顧客に対応するように、開発者の要求に応じて、組織のガードレールに準拠するように設計された項目のカタログを設定します。
たとえば、新しいツールへのアクセスを要求する開発者は、デジタル ストアで注文をしているように考えることができます。 注文と同様に、要求が送信されると、開発者は進行状況を追跡し、完了した日時を把握できるようにしたいと考えています。 バックグラウンドで、リクエストは要求を満たすために適切なフルフィルメント プロバイダーに自動的にルーティングされます。 継続的インテグレーションおよびデリバリー (CI/CD) システムを 1 つのフルフィルメント プロバイダーとして、GitOps ツールまたは規範的なアプリケーション プラットフォームを 2 つ目として、手動プロセスのワークフロー自動化ツールを 3 つ目として考えることができます。 いずれの場合も、開発者は、明確に定義されたカタログのアイテムを同じ方法でセルフサービスで実行きます。
すべてをコード パターンとして使用する
継続的デリバリー (CD) パイプラインと GitOps ツールを通じてコードとしてのインフラストラクチャ (IaC) を使用することは、セルフサービスを可能にするための重要な部分です。 CD と IaC を使用すると、Bicep、Terraform、Helm チャート、その他のツールを使用して、必要に応じてクラウド リソースを作成および破棄できます。 クラウド インフラストラクチャの構成はソース コード リポジトリのコードと同じように管理されるため、セキュリティや監査可能性など、Git リポジトリのすべての利点を適用できます。
一般的なインフラストラクチャとツールのプロビジョニングだけが IaC アプローチの唯一の利点ではありません。 コードとしてのセキュリティや、コードとしてのポリシー (Azure Policy、Open Policy Agent などのツールを通じて) などのコード パターンを他のシナリオに合わせて調整できます。 この手法に従って、構成ファイル (通常は YAML または JSON) がリポジトリにプッシュされ、その時点で、ファイルを処理するワークフローがトリガーされます。 これらのファイルは、dependabot.yml や CODEOWNERS などのアプリ リポジトリの場合もあれば、別の中央リポジトリに保持されている場合もあります。 これを独自のシナリオに拡張し、コード (EaC) としてすべてを現実することもできます。
開発者は、セルフサービス エクスペリエンスを促進し、既定でベスト プラクティスを奨励する中央カタログで、これらの EaC テンプレートをそれぞれ参照できます。
適切なテンプレートを作成し、適切なガバナンスを確立する
ソフトウェア開発では、アプリケーションの設計時にカプセル化、モジュール性、構成可能性を目指します。 テンプレートを使用して、この同じ考え方をプラットフォーム エンジニアリングに適用する必要があります。 たとえば、一元的にセキュリティで保護された再利用可能な IaC テンプレートのセットを作成して、インフラストラクチャの構成要素として使用できます。
[開発者] 用のモジュールをビルドします... そのため、バックエンド自体の記述や心配をする代わりに、アプリケーション コードを心配するだけです。 - Daniel、クラウド エンジニア、Fortune 500 メディア企業
IaC、EaC、アプリケーション テンプレートを組み合わせて、コード (EaC) ソリューションとしてカスタマイズされたすべてを組み合わせます。これは、ソース コード リポジトリの作成、サンプル コードのシード処理、推奨される監視ツールの構成とサンプル コードの提供など、他のアクティビティにまで及びます。 その後、これらの IaC、EaC、アプリケーション テンプレートは、リポジトリ、Azure Deployment Environments のカタログ、クラウド ネイティブの Azure Container Registry (ACR) など、中央のセキュリティで保護された場所に保存したり、参照したりできます。
適切なテンプレートを自動化されたガバナンス、スキャン、ポリシー構成と組み合わせると、開発者は 1 日目からすぐに使用できます。
テンプレートは、自動化された安全なプラクティスで開発を効率化します
アプリケーション テンプレートを使用して、開発者がプロジェクトの過程を引き継ぐいくつかの重要な決定とアクションのために、定義済みの舗装されたパスをブートストラップします。 適切なテンプレートを開始すると、セキュリティ保護済みの管理された開発プラクティスが確立され、開発者は必要なツールへのアクセスを提供する自動化を有効にし、CI/CD パイプラインを構成し、インフラストラクチャとアプリケーション スタックをプロビジョニングし、必要な SDK や API への参照を含むボイラー プレート ソース コードを含むリポジトリを構成することで、迅速に開始できます。
これらのアプリケーション テンプレートで他の一元化されたテンプレート (IaC テンプレートなど) を参照することで、これらの個々の構成要素はそれぞれ独自の適切なテンプレートを開始するようになります。 これらのテンプレートには、出力を定義するだけでなく、開発者が選択できるオプションも含まれるため、セルフサービス エクスペリエンスを有効にする上で中心的な役割を担います。
テンプレートにより、ガバナンス、セキュリティ、コストの最適化が保証されます
ただし、テンプレートは、開発作業をブートストラップするだけでではありません。 また、プロジェクトのライフサイクル全体を適切に維持するために必要なポリシーとセキュリティ スキャンを通じて、制御とガバナンスを確立します。 別の例として、テンプレートでは、運用環境への未承認のマージを防ぐブランチ保護ルールを設定できます。 テンプレートはベスト プラクティスと一般的な構成を取り込むため、ツール、ベンダー、チーム全体のコストを最適化するための主要な手法の 1 つです。
適切なキャンペーンを実行して双方向のコミュニケーションを構築する
最後に、舗装されたパスに対する信頼度が高まるにつれて、アプリケーション テンプレートに組み込んだ、基本となる個々の構成要素を使用して、既存のアプリケーションを舗装されたパスに移動できます。 社内の顧客にはパイロットの舗装されたパスの価値が既に表示されるため、社内の適切なキャンペーンを実行して、他のアプリケーション チームとの双方向ダイアログを作成できます。 開発者はアプリケーションを移行する方法を学ぶことができ、プラットフォーム エンジニアリング チームは、プラットフォームを改善する方法について同時に学ぶことができます。
自分の体験をグラフに表示する
セルフサービス機能がカバーできる幅広いエクスペリエンスを考えると、社内の開発者プラットフォームが段階的に価値を提供できるように、投資作業と計画と優先順位付けの重要な焦点となります。 社内の開発者プラットフォームの作成における各組織の取り組みは異なりますが、製品の考え方に従うことで、まずセルフサービス エクスペリエンスを必要とする最も重要な場所をターゲットにするのに役立ちます。