プラットフォーム エンジニアリングは、開発者エクスペリエンスの向上と、セキュリティで保護された管理されたフレームワーク内でのセルフサービスを通じて、各開発チームのセキュリティ、コンプライアンス、コスト、およびビジネス間の価値の向上を目指す DevOps の原則から構築されたプラクティスです。 製品ベースの考え方のシフトと、それをサポートするための一連のツールとシステムの両方です。
最近では、プラットフォーム エンジニアリングという用語に関して多くの業界の興奮があります。 Gartner は、 エンジニアリング組織の約 80% が、2026 年までにプラットフォーム エンジニアリング専用のチームを持つ予定です。 これらのチームは、 内部開発者プラットフォームと呼ばれるものを構築することに焦点を当てています。 販売 (Microsoft Dynamics、 Salesforce)、サービス フルフィルメント (ServiceNow)、通信 (Twilio) のいずれであっても、ドメインに関係なく、プラットフォームは固有の性質により、スケールを達成し、ビジネス価値を提供するのにかかる時間を短縮するように設計されています。
開発者が使用または拡張するプラットフォームには、高度に最適化された開発者エクスペリエンスと簡素化された操作を使用して、開発プロセス全体で問題を排除する機能があります。 これらのプラットフォームには、次のツールが含まれます。
- 開発者が自給自足できるように支援します (スターター キットや IDE プラグインなど)。
- 一般的なタスクを支援します。
- 一般的なパターンとプラクティスを再利用可能な構成要素にカプセル化します。
- 問題やセキュリティ リスクに関する早期のアドバイスとフィードバックを提供します。
- 基になるインフラストラクチャとツールを管理することで、操作を簡略化します。
Microsoft のプラットフォーム エンジニアリング機能モデルでは、投資、導入、ガバナンス、プロビジョニングと管理、インターフェイス、測定とフィードバックという、プラットフォーム エンジニアリングを定義する 6 つのコア機能について説明します。 各機能領域で組織の現在の位置を把握し、将来の成長のための目標を設定するには、「 プラットフォーム エンジニアリング機能モデルについて」を参照してください。
内部開発者プラットフォームとは
内部開発者プラットフォームは、会社の内部開発プラクティスに重点を置いています。 運用環境に対して推奨およびサポートされている開発パスのセットを定義し、内部プラットフォームを使用して段階的に "舗装" します。
実際の例えを使用するために、新しいパスは多くの場合、ダート トレイルとして始まりますが、使用する人が増えるにつれて、速度とスループットを維持しながら安全性を向上させるために舗装されます。 内部開発者プラットフォーム内の舗装されたパスにも同様の目標があります。 開発者の配信速度を犠牲にすることなく、重要な要件と標準を開発者に案内するように設計されています。 これは、標準化されたセキュリティで保護されたスケーラブルなセルフサービス機能を開発チームに提供することで実現されます。 同時に、運用やIT組織が基盤のインフラストラクチャとツールが効率的で、準拠しており、コスト効率を備えていることを容易に確保できるようにします。 一部のパスは部分的に舗装される可能性があります。完全に舗装されたゴールデン パスでは、関係するすべてのユーザーの認知負荷が軽減されます。
開発者は、内部開発者プラットフォームの主要なコンシューマーまたは顧客です。 自動化と集中化により、効率的な運用が可能になり、コンプライアンスなどの利害関係者の要件が満たされます。
プラットフォーム エンジニアリングでは、 製品の考え方 と DevOps と DevSecOps の学習を組み合わせて一連のツールを提供することで、この内部プラットフォームを作成します。 これらのツールは、開発チームを自然に「成功の落とし穴に導く」十分な自動化、トラッキング、ガバナンス、および可観測性を提供します。多国籍マスメディア企業のプラットフォームエンジニアリングリーダーは、次のように述べています。
プラットフォームエンジニアリングは、製品を提供する速度または速度を向上するために採用されました。 一元化されたチームでは、各チームがインフラストラクチャについて心配する必要がなくなり、効率が向上します。...また、すべてが事前に定義されているため、安全性とセキュリティも強化され、エラーが減少します。 - クラウド エンジニア、Fortune 500 メディア企業の Daniel
内部開発者プラットフォームは、コグニティブな負荷と手動の手順を減らすか、または排除することで、開発と運用のライフサイクル全体にわたって専門的な知識を一元化し、スケーリングするのに役立ちます。
セルフサービスと自動化に重点を置いて、開発者プラットフォームを段階的に構築する
成功したプラットフォーム エンジニアリング戦略を実装するには作業が必要ですが、その価値はあります。 個人が 20 人未満のチームが、何千人もの開発者と数百のプロジェクトをサポートできることは珍しくありません。
ただし、内部開発者プラットフォームの作成は旅です。 ビッグ バンアプローチやトップダウン型の取り組みはお勧めしません。 プラットフォーム エンジニアリングの重要な側面は、開発者、機械学習の専門家、またはデータ サイエンティストを顧客として扱う製品の考え方を適用することです。 あるテクノロジ企業の 1 人のプラットフォーム エンジニアとして、次のように言います。
[そこに] [私たちの] プラットフォームエンジニアリングツールが解決するように設計された2つの主な問題があります。 1 つ目は、セルフサービス モデルを使用してサービスのプロビジョニングを容易にすることでした。 … 2 つ目は、パフォーマンス メトリックやアプリケーションの可用性などの自動サポート システムを提供することです。 目標は、開発者がアプリケーションのトラブルシューティングと最適化に必要なすべての情報を取得しながら、より迅速かつ効率的に作業できるようにすることでした。 - Alex、リード クラウド アーキテクト、大規模なテクノロジ企業
企業によって異なるため、段階的なプロセスを通じてこの旅を進めるために、内部顧客の特定のニーズを考慮してください。 一連のコア構成要素を時間をかけて組み立てることで、社内の開発者プラットフォームに十分な価値を持たせ、開発チームが自然に支持者となり継続的に使用したくなるようにすることができます。 この情報を使用して、最も実行可能な最も薄いプラットフォームを作成し、プラットフォームの実用最小限の製品を作成し、そこから成長します。
重要なポイントは、これらの分野で行う投資を、プラットフォーム エンジニアリング体験の重要な構成要素として考えたいということです。 その後、すべてをゼロから構築するのではなく、カスタム投資でまとまりのある接着剤を作成し、ビジネスに固有の価値を追加することに集中できます。