プラットフォーム実装の核となる側面
プラットフォーム エンジニアリングは、ソフトウェア エンジニアリング、システム設計、オペレーショナル エクセレンスを組み合わせて、アプリケーションをビルドおよびデプロイするための、信頼性が高くスケーラブルなインフラストラクチャを作成する、分野横断的なアプローチです。 その中核には、堅牢なプラットフォームをビルドするだけでなく、開発チームを支援しビジネス目標との整合性を確保しながらセルフサービス環境をビルドすることが含まれます。 プラットフォーム エンジニアリング イニシアチブの成功は、適切なチームと問題空間の明確な理解から始まります。 この基盤により、運用を合理化し、摩擦を軽減し、開発者がインフラストラクチャの管理ではなく、アプリケーションのビルドに集中できるシステムの開発が可能になります。
チームが立ち上がると、焦点は多くの労力が必要な作業領域の自動化と、時間を節約し、エラーを減らすために自動化できる手動で反復的なタスクの特定に移ります。 その後は、既存のリソースのインベントリが不可欠であり、チームはツールとサービスを一元化できるため、管理とスケーリングが容易になります。 次の手順は、"舗装された道を切り開くこと" と呼ばれており、プロジェクト間の一貫性を確保する標準のワークフローと環境の作成が含まれます。 その後、環境をサービスとしてデプロイして、プロセスをさらに効率化し、チームが必要に応じて環境をすばやく起動できるようになります。 その時点で、主な目的は、セルフサービス開発者エクスペリエンスを最適化し、開発者が成功に必要なツールとサポートを確保しながらワークフローを独立して管理できるようにすることです。 このアプローチにより、開発チームがインフラストラクチャとやり取りする方法が変わり、アプリケーションをビルドして提供するためのアジャイルでパフォーマンスの高い環境が作成されます。
明確に定義された実装計画を持つことに加え、プラットフォーム エンジニアリングを単一の広範な概念として扱うのではなく、実装プロセスを支援するために、次の 4 つの主要な領域に分割すると役立つことがあります。
- エンジニアリング システム。CI/CD、パッケージ管理、クラウドベースのコーディング環境、コード スキャナーとリンターのほか、GitHub Copilot のような人工知能 (AI) アシスタントなどの開発を可能にするツールとサービスが含まれます。
- アプリケーション プラットフォーム。一般的に使用されるアプリ スタック (Azure Policy、Azure Key Vault、Azure Container Apps、Cosmos DB など) の構成要素として使用される厳選されたサービスで構成されています。
- アプリケーション テンプレート:ワークロードのプロビジョニングを容易にし、ベスト プラクティスに合わせて、明確に定義された組織固有のテンプレートを提供します。
- 開発者のセルフサービス機能:開発者は、組織の標準に対するガバナンスとコンプライアンスを確保しながら、ワークフローを自律的に管理できます。
これらの領域を実装戦略に組み込むことが、開発者の作業を減らし、イノベーションを促進して、シームレスな開発エクスペリエンスを生み出します。
チームの構築
プラットフォーム エンジニアリング組織では、長期的な成功のために適切な文化を育てることが不可欠です。 事後対応型から積極的な文化への移行が重要であり、プラットフォーム チームは、組織をサポートするためのツールのビルドと保守の責任があります。 この変化は、知識サイロと運用の中断を減らす上で重要です。 プラットフォーム エンジニアリングの取り組みの成功は、暫定段階から最適化段階まで、組織成熟度を段階的に移行することに重点を置くプラットフォーム エンジニアリング機能モデルで概説されている投資能力と一致します。 暫定段階では、企業はプラットフォーム エンジニアリングの必要性を認識していますが、リーダーシップチームと開発チームの完全な連携が欠けている場合があります。 組織が成熟するにつれて、経営陣の賛同と文化の変化は、プラットフォーム チームが意味のある変化を促進し、組織を効果的にスケーリングできるようにする、より協調的で革新的な環境を奨励します。
プラットフォーム エンジニアリング チームには、信頼性の高い効率的で安全な内部開発者プラットフォームをビルドおよびスケーリングするために、多様な技術スキルと製品中心の考え方が必要です。 プラットフォーム エンジニアは、コンテナー オーケストレーション (Kubernetes など)、CI/CD パイプライン (GitHub Actions、Azure Pipelines など)、監視ツール (Azure Monitor、Prometheus、Grafana など) など、いくつかの重要な領域に熟練している必要があります。 Terraform や Bicep などのコードとしてのインフラストラクチャ (IaC) ツールの専門知識は、インフラストラクチャのプロビジョニングを自動化するために不可欠です。 さらに、プラットフォーム エンジニアは、システム間の自動化と統合を可能にするため、Python、PowerShell、Bash などのスクリプト言語でコードを記述することに慣れている必要があります。 プラットフォーム エンジニアの人材プールを活用するのは困難な場合もありますが、成功するチームは、ソフトウェア開発、サイト信頼性エンジニアリング (SRE)、IT 運用など、さまざまなバックグラウンドの専門知識を組み合わせる必要があります。
多くの労力が必要な領域を自動化する
通常、多くの労力が必要な領域の自動化は、開発者のセルフサービス機能を実現するための最初の標準化された方法を表します。 これを実装するには、まず、頻繁な、エラーが発生しやすい、または労働集約的なプロセス、特に手動またはサービス デスクの操作に関連するプロセスを特定することから始めます。 次に、自動化の対象に優先順位を付けるために、プロセスの頻度、複雑さ、監査可能性などの要因を評価します。 継続的デリバリー (CD) パイプラインにコードとしてのインフラストラクチャ (IaC) を実装すると、アプリケーションのデプロイが効率化されるだけでなく、共有インフラストラクチャとツールの動的プロビジョニングも可能になります。 GitHub Actions や Azure DevOps などの柔軟な CI/CD プラットフォーム、または Flux や Argo CD などの GitOps ソリューションを使用してボトルネックを減らし、チームを強化します。
時間の経過とともに、"Everything as Code" (EaC) パターンを採用すると、IaC テンプレートと構成 (Bicep と Azure Resource Manager テンプレート、Terraform マニフェスト ファイル、Helm チャートなど) 用の一元化された Git リポジトリを使用して、安全で反復可能な自動化フレームワークが作成されます。 運用チームが管理するこれらのリポジトリを使用すると、開発者はマージ前に安全にレビューおよび監査される pull request を送信できます。 同じ CI/CD ツールで、アプリケーション固有でも共有でも、あらゆるインフラストラクチャ、ツール、またはサービスをプロビジョニングおよび構成できます。 このアプローチでは、スケーラビリティ、開発者のセルフサービス、ガバナンス プロセスとのシームレスな統合がサポートされ、プラットフォーム エンジニアリングと組織の目標の一致、および運用の機敏性の促進が確保されます。
"Everything as Code" のアプローチは、安全な Git リポジトリ内のほぼすべてのリソースまたはプロセスをファイルとして表すことを中心に展開されます。 コミット履歴、アクセス制御、pull request、ブランチ保護などの Git の堅牢なセキュリティ機能により、透明性が確保され、コラボレーション レビューが有効になり、変更が統合される前に自動チェックが実施されます。 CI/CD システムと組み合わせることで、インフラストラクチャ、ツール、プロセスを管理するための、多様で監査可能で安全なフレームワークが作成されます。
インベントリと一元化
組織が成長するにつれて、技術資産の量と複雑さが増し、多くの場合、作業の重複、孤立したプロジェクト、無駄なリソースが発生します。 インベントリと資産の追跡を一元化することは、これらの課題に対処するためのプラットフォーム エンジニアリングの重要なステップです。 インベントリ システムを使用すると、チームはコード、API、コンテナー、仮想マシン (VM)、アクセス許可などの資産を追跡および管理できます。 このプロセスにより、ガバナンスが向上するだけでなく、再利用が促進され、検出可能性が向上し、チームがより効率的かつ効果的に運用できるようになります。
一元化されたインベントリは、資産のタグ付けと整理によって、ガバナンスを改善する上で重要な役割を果たします。 適切なタグ付けにより、リソースがそれぞれの所有者またはチームに関連付けられ、ライフサイクルの管理と、変更の潜在的な影響の理解が容易になります。 検出可能性の向上は、チームが既存のリソースを見つけて再利用し、不要な作業の重複を防ぐことで、技術上の無秩序な広がりを減らすもう 1 つの重要な利点です。 さらに、インベントリを一元化すると組織は古い、または不要な資産を特定し、クリーンアップしてリソースを最適化し、無駄が省かれ、コストの削減につながります。
さまざまなツールでインベントリと資産の追跡がサポートされ、それぞれが技術エコシステムのさまざまな側面に対応します。 たとえば、Azure Deployment Environments (ADE) には、コードとしてのインフラストラクチャ (IaC) を使用して作成された複雑なインフラストラクチャを追跡する方法が用意されています。 同様に、Azure API Center を使用すると、開発者は API を効率的に検出して管理できます。 GitHub Packages や Azure Artifacts などのパッケージ レジストリは、サプライ チェーンのセキュリティを強化し、承認されたパッケージと SDK を管理して、付加価値を提供します。
インベントリ システムの利点をさらに強化するために、組織は資産間のリレーショナル リンクを確立して、エコシステムのより包括的なビューを作成できます。 たとえば、API 定義、そのコード リポジトリ、関連する環境、ガバナンス ポリシー間のリレーションシップをマッピングすると、チームはリソースをより正確に管理できます。
舗装されたパスを切り開く
プラットフォーム エンジニアリングでは、"舗装された道" の例えが、イノベーションの促進と標準化されたガイダンスの提供のバランスを伝えています。 当初、チームはさまざまなツールやワークフローを試しながら、目標を達成するためにさまざまな非公式の道を歩むかもしれません。 時間の経過とともに、プラットフォーム チームは最も効果的で広く採用されているアプローチを観察し、それらを "舗装された道"に変換します。最適化されたワークフローは、効率的でユーザーフレンドリであり、チームが導入するのに説得力があります。
このプロセスは、"舗装された道を切り開くこと" と表現されることがよくあり、チーム ワークフローの一般的なパターンを特定し、標準化されたスケーラブルなソリューションに変換します。 これらの道は、セキュリティ、アーキテクチャのベスト プラクティス、コンプライアンス要件をシームレスに統合し、スムーズで信頼性の高いエクスペリエンスを提供します。 開発者は、コグニティブ負荷の軽減、統合のための一貫性のある API、必要に応じて組み合わせられるモジュール型の機能、運用目標に合わせた予測可能なパフォーマンスという恩恵を受けます。
プラットフォーム エンジニアリング機能モデルは、このプロセスにおいて極めて重要な役割を果たし、組織が非公式の道から舗装された道に移行するタイミングを決定するのに役立ちます。 標準化が必要な領域を特定し、これらのプラクティスを効果的にスケーリングする方法に関する分析情報を提供します。 この構造化されたアプローチにより、品質、コンプライアンス、パフォーマンスへの重点を維持しながら、イノベーションが妨げられないようにします。
舗装された道を切り開くアプローチは、過度に規範的でなくても優れた習慣を奨励します。 コミュニティへの貢献をサポートし、独自のユース ケースの柔軟性を維持しながら、チームが共同作業でプラットフォームを形成できるようにします。 イノベーションと標準化のバランスを取ることで、この方法論は、組織の要件が一貫して満たされるようにしつつ、チームが優れた成果を上げられる環境を促進します。
サービスとして環境をデプロイする
サービスとしての環境のデプロイは、インフラストラクチャの安全で、標準化され、自動化されたプロビジョニングを可能にするように設計されています。 このアプローチの重要な原則は、プロビジョニング ID とシークレットを永続化して、開発者がそれらに直接アクセスできないようにすることです。 これにより、インフラストラクチャの更新プログラムを安全に確保しながら、ガバナンスが適用されます。 たとえば、Azure Deployment Environments (ADE) は、ロールの分離をサポートし、IaC テンプレートの管理を一元化することで、このモデルの例を示しています。
ADE を使用して、プラットフォーム エンジニアと運用チームは、特定の環境の種類のテンプレートのカタログを共同でビルドおよび管理できます。 これらのテンプレートは、事前に構成された設定で強化され、マネージド ID を統合し、ロールに基づいてアクセスを制御します。 その後、開発者は CI/CD パイプラインを使用して、機密性の高い資格情報や基になるサブスクリプションに直接アクセスすることなく、Azure CLI や Azure Developer CLI などのツールを使用してインフラストラクチャをプロビジョニングできます。 この分離により、開発者の生産性を維持しながら、コンプライアンスとセキュリティが確保されます。
ADE を使用していない場合でも、コンテンツが安全で不変の場所から取得されたコードとしてのインフラストラクチャ (IaC) と、自動化および分離済みのシークレット管理を使用して、同じ原則をより広範囲に適用できます。 これらのプラクティスを実現すると、プラットフォーム エンジニアリングは、チームが組織のガバナンスと運用効率を維持しつつ、一貫した環境を展開できるようにします。
セルフサービスの開発者エクスペリエンスを最適化する
シームレスなセルフサービスの開発者エクスペリエンスは、プラットフォーム エンジニアリングの成功に不可欠ですが、これを実現するには、多くの場合、ユーザーがいる場所で対応する必要があります。 開発者、運用、その他のすべての役割は、ワークフローを定義する特定のツールや環境に結びついています。 新しいエクスペリエンスを導入する場合は、これらの既存の "重心" に合わせることが重要です。 実用的なアプローチでは、既に使用されているツールに合わせて調整された複数のユーザー インターフェイスの計画が含まれ、これによりチームは単純な機能強化から始め、その価値を証明し、ニーズが生じるにつれてより高度なソリューションに向かって進化することができます。
まったく新しいエクスペリエンスを作成する代わりに、既存のツールの強化と統合を検討します。 エディター、統合開発環境 (IDE)、DevOps スイート、CLI ツール、ロー コード環境などのプラットフォームには、多くの場合、最小限のオーバーヘッドでカスタマイズと拡張を可能にする拡張性モデルがあります。 このアプローチにより、メンテナンスが軽減され、使い慣れたユーザー エクスペリエンスが適用され、導入が促進されます。 たとえば、Web ベースの IDE 拡張機能は、VS Code または vscode.dev 用に構築されたものと同様に、ローカル開発環境にスケーリングできる柔軟な Web 互換の開始点を提供します。 同様に、Microsoft Teamsや Slack などのツールの ChatOps インターフェイスは、自動化ワークフローをトリガーし、CI/CD プラットフォームと統合するための直感的な方法を提供します。
一元化されたインターフェイスを必要とする組織の場合、カスタムの開発者ポータルへの投資は長期的な利点を提供できますが、慎重な計画とリソースが必要です。 最初に Spotify によって開発されたツールキットである Backstage.io のようなソリューションは、プラグインとサードパーティのツールを統合できる高度にカスタマイズ可能なポータルを提供し、動的な開発者中心のハブを作成します。 Power Pages などの軽量ソリューションから始める場合でも、包括的なポータルをビルドする場合でも、組織のニーズに合わせて開発者を支援するスケーラブルでユーザーフレンドリなエクスペリエンスを提供することが目標です。