簡単な概要
最先端の組織でさえ、人材不足の増大に直面して、開発成果を拡大するのに苦労しています。その結果、企業や開発チームは、これらの課題を克服し、大規模な配信を加速するために、社内の開発プラットフォームの観点からインフラストラクチャを検討し始めています。Gartnerなどの大手アナリスト企業、 Martin Fowlerなどの思想的リーダー、 HumanitecやUpboundなどのベンダー、Apple、Netflix、Twitterなどのテクノロジー巨人はすべて、社内開発プラットフォームに関する議論を開始しています。このレビュー記事はさまざまな声を要約し、実践的なアドバイスや関連参考文献とともに詳細を提供します。また、エンタープライズ レベルで IDP を計画、実装、運用するために推奨されるいくつかの焦点も取り上げます。
内部開発者プラットフォームは、ソフトウェア配信ライフサイクルにおける 3 つの主要な課題に対処するため、重要な新しい概念です。それ
- 開発から本番までの環境管理を提供し、CI/CDを統合
- 開発チームがアプリケーションに活用できる反復可能なパターンを統合する
- 開発チームと運用チーム間のトランザクションの負担を軽減
多くの場合、単にエンジニアを増員するだけでは直面する問題を解決するのに十分ではなく、企業組織の成長をサポートするのにも十分ではありません。この問題については後で詳しく検討します。
クラウド コンピューティング、コンテナ化、マイクロサービス アーキテクチャは、新しい環境の要件を達成するための社内ツールとシステムの幅広い選択肢を組織に提供します。社内開発者プラットフォームは、運用上の負担を軽減しながら、開発チームにツールとリソースの豊富な選択肢を提供することを約束します。直感的または意図的に、多くの開発チームはこれらの利点を認識していますが、インフラストラクチャに対する責任は、この抽象化を提供する少数の異なる個人にあります。多くの場合、企業は実際に社内開発プラットフォーム、または少なくともそのバリエーションを構築していることを知りません。InfoWorld の Scott Carey 氏は、社内開発プラットフォームを「雪の結晶」と表現したときにこの概念を捉え、「同じものは 2 つとしてありません。各プラットフォームは組織のスタック、文化、コードベース、ツールセットによって異なります。」と述べました。
私たちは、社内開発プラットフォームの適応性がコンセプトの中核要素であると信じています。これが、内部開発者プラットフォームの概念がソフトウェア開発組織にとって非常に強力で魅力的な理由の 1 つです。したがって、学術的な定義を避け、代わりにさらなる適応を促進するために、文献で見られたさまざまな機能と実装モードに焦点を当てます。
社内開発者プラットフォームとは何ですか
コミュニティ主導の Web サイト、internaldeveloperplatform.org は、内部開発者プラットフォームとは何かを理解するための優れた出発点を提供します。
内部開発者プラットフォーム (IDP) は運用チームによって構成され、開発者によって使用されます。運用チームは、どのリソースがどのような状況または要件の下で開始されるかを指定します。また、アプリケーション構成のベースライン テンプレートを設定し、権限を管理します。これにより、環境やリソースの起動などの繰り返しのタスクを自動化し、標準を適用することでセットアップの維持が容易になります。
Container Solutions の Brendan Kamp 氏と彼のチームは、IDP を「内部開発プロセスをサポートする中央プラットフォームに互いに統合できるツールのシステムであると考えています。開発者はそれを『サービスとしての内部プラットフォーム』と見なしています」と考えています。
Scott Carey による前述のInfoWord 記事でも、開発チームの特定の好みという観点から IDP のサービスの性質を強調しています。
優れた社内開発者プラットフォームでは、インフラストラクチャの意思決定を抽象化し、セルフサービス環境の構築を可能にし、既存の継続的インテグレーションとデリバリー(CI/CD ) およびデプロイメントプロセスと統合し、ロールベースのアクセス制御を割り当てる必要があります。これらのすべてにおいて、開発者は YAML を学ぶ必要はありません。 。
社内開発者プラットフォームの貴重な機能
ワッツ・S・ハンフリー氏の象徴的な言葉「すべてのビジネスはソフトウェア・ビジネスである」は20年近くにわたって存在しており、マイクロソフトのサティア・ナデラ氏を含む多くのCEOや戦略的リーダーによって繰り返し述べられており、この言葉は異なる見解を提唱しています。この引用は、実際の業界に関係なく、あらゆる組織が最新のアプリケーション開発で競争力を保つための重要な課題に対処するための適切な環境をソフトウェア開発チームに提供する必要性を強調しています。
典型的な需要と供給の問題
多くの組織は、クラウド導入プロジェクト、デジタルファーストの取り組み、デジタルトランスフォーメーションにおいて前例のないレベルの成長を遂げています。こうした動きにより、従来、開発チーム向けのプラットフォームの構築と保守を担当してきた運用チームに大きな負担がかかります。
全体的なバックログを減らし、ワークロードをより均等に分散するために、単にエンジニアや開発者を増員するだけでは、問題は解決されません。明確なプロセスと共通の理解がなければ、これは「より多くの人材」につながりますが、組織の内部技術スタックはそれぞれ異なるため、すぐには効果を発揮できない可能性があります。追加を開始する前に、新しいエンジニアがスキルセットのギャップを「埋める」のに時間がかかります。チームにとっての価値。
チームの認知的負荷を軽減します
ソフトウェア配信に携わるチームは、多くのタスクと責任を抱えて日々の業務を両立させなければなりません。社内開発プラットフォームは、日常のさまざまなタスクに関連する認知負荷の一部を高めます。コンテキストの切り替えによって引き起こされる認知負荷は、開発者の生産性の低下の問題としてよく挙げられます。開発者の生産性専門家の Matthew Skelton 氏と Manuel Pais 氏は、チームが圧倒されているように見える主な理由として、コンテキスト切り替えによる認知負荷を挙げています。ベストセラー『チーム トポロジー』の中で、著者はこれについて非常に詳しく説明しています。「認知負荷を考慮せずに、チームはあまりにも多くの責任と領域をカバーしようとして分散します。そのようなチームは、業界の習得を追求するための帯域幅が不足しており、コンテキストを切り替えるコストと格闘しています。」 再び、Puppet より 2020 DevOps レポートでは、次のように述べられています。 「ほとんどのソフトウェア開発者と運用エンジニアは、2 つのコンテキスト間を行き来することは多大な認知的消耗であることを理解しています。これには、コンテキストを切り替えるという人間の通常の課題とは別に、理由があります。詳細と考え方は各分野で大きく異なります。」 」。
しかし、組織やプロジェクトの計画中に認知負荷が考慮されることはほとんどありません。これにより、開発チームは大きな不利な立場に置かれ、組織が生産的な勝利を収めることができなくなります。内部開発者プラットフォームは、単一の対話ポイントでキャラクターを消費するための再利用可能なパターンのコレクションをチームに提供します。これによりコンテキストの切り替えの数が減り、チームの認知的負荷が軽減されます。
自律性とツールの多様性への挑戦
Martin Fowler のブログで、Evan Bottcher は、組織の開発チームと運用チームが直面する課題と、内部開発者プラットフォームがどのように役立つかを見事に説明しています。
...明らかに、優れたプラットフォームは、バックログを削減するカップリングの量によって特徴づけられる必要があります。プラットフォームは、チケットの発行や作業の割り当てを必要としないサービスを提供する必要があります。セルフサービスは、優れたプラットフォームの特徴を定義する重要な要素です。プラットフォームはチームにセルフサービス アクセスを提供する必要があります。具体的には、セルフサービスプロビジョニング、セルフサービスプロビジョニング、プラットフォーム機能と資産のセルフサービス管理と運用を可能にする必要があります...自律的な多様化と強制的な統合の間の適切なバランスを見つけることができますが、これを予測するのはさらに困難です。初期段階。
チームがより迅速に成果を出せるようにする
高品質のソフトウェアをより高速に提供することは、主に新機能に対する消費者の需要と市場内の競争のため、開発チームと彼らがサポートするビジネスにとって長年焦点となってきました。組織がそれぞれの市場で直面しているプレッシャーの非常によく知られた例としては、AirBnB がホスピタリティ業界を破壊したり、Uber やタクシー業界が混乱したりすることが挙げられます。これは、変化する市場で相対的な地位を維持するために企業が対応できる必要があることを示しており、それがアジャイルと DevOps を生み出し、企業は2015 年にはすでに「DevOps のタイヤを蹴り」始めていました。
それ以来、Puppet が年次 DevOps レポートで述べているように、クラウド企業と従来型企業の両方の多くの企業が「高パフォーマンスの DevOps 組織」として知られるようになりました。この用語は、これらの企業がソフトウェアをより迅速に提供し、それぞれのビジネス分野で構成企業を上回る業績を達成するために何ができるかについて、多くの業界リーダーやアナリストの意見を考慮に入れています。組織が高パフォーマンスの DevOps 企業とみなされるかどうかを評価するために使用される主要な指標には、次のようなものがあります。導入頻度/スケジュール、リードタイム、待機時間、平均修復時間 (MTTR)。
2020 年版の State of DevOps レポートでは、これらの業績の高い企業と社内開発者プラットフォームの導入の間には明らかな傾向が見られます。Puppet 氏は、「DevOps の進化と社内プラットフォームの使用の間には強い関係があることを発見しました。高度に進化した企業は、社内プラットフォームの使用率が高いと報告する可能性が中層組織のほぼ 2 倍であり、下位層の組織は社内プラットフォームの使用率が高いと報告する可能性が低いです。」使い方は「編成6回」。
社内でプラットフォームを開発するチームに参加する
社内開発者プラットフォームは従来、プラットフォーム チームと呼ばれる専用のチームによって構築および管理されてきました。プラットフォーム チームとともに、運用チームは組織の技術的ニーズに責任を負い、開発チームはソフトウェアの提供に責任を負います。以下では、各チーム、そのニーズ、課題について詳しく説明します。
プラットフォームチーム
プラットフォーム チームの編成は、組織内での内部開発者プラットフォームの成功の重要な要素であり、チームの使命は明確で定義されている必要があります。プラットフォーム チームを組織内の別個のエンティティとして定義することで、プラットフォーム チームの焦点が集中され、組織内での以前の役割によってもたらされた可能性のあるトランザクションの負担が一部軽減されるはずです。エヴァン・ボーチャー氏は再び強調した。
「プラットフォーム チームは、プラットフォーム コンポーネントと基盤となるプラットフォーム インフラストラクチャを構築、展開、監視し、待機しています。理想的には、プラットフォーム チームは、プラットフォーム上でどのようなアプリケーションが実行されているかさえ知りません。彼らが責任を負うのは、プラットフォーム サービス自体の可用性。」
プラットフォームの構築と保守において、プラットフォームはプロダクト思考を採用する必要があります。これについては、ブログの後半で詳しく説明します。
運用チーム
従来、運用チームは組織の IT インフラストラクチャのいくつかの重要な要素を担当していました。少数のプロジェクトを同時に抱えている開発チームとは異なり、運用チームは通常、ソフトウェア ソリューションを構成する複数の環境、データベース、ネットワーク、クラウド インフラストラクチャ、およびその他の多くの要素を管理するはるかに広い作業範囲を担当します。
同時に、運用チームは組織のリアルタイム環境にも責任を負います。この環境では通常、消費者や内部ユーザーが日常的に会社とやり取りします。これには、開発チームの能力を高めることと、ビジネスを継続するための「明かりを灯し続けること」との間の興味深いバランスが必要です。これらのチームは通常、チケット発行システムによって管理される先入れ先出し (FIFO) ベースで作業し、失敗が他のタスクよりも優先されます。
2020 DevOps レポートでは、効果的な DevOps 組織は、開発者のセルフサービスを可能にし、運用チームのプロジェクトとトランザクションの負荷を軽減するために、内部開発者プラットフォームに投資する必要があることを強調しています。多くの組織は、知らず知らずのうちに、チームに内部開発者プラットフォームを提供するプロセスを開始しています。組織は特定のクラウドで標準化するか、Kubernetes や Openshift などの特殊なコンテナ プラットフォームにデプロイし始めるでしょう。社内開発者プラットフォームを構築する過程で、組織はソフトウェアのライフサイクル全体を通じての配信を改善するために、依存関係を解消するゲームを次々と実行します。「より迅速にリリースする必要がある場合は、ブロックを解除してボトルネックを取り除くゲームを行い、根本原因に対処する戦略を構築します」と、Zalando の元プラットフォーム ディレクターである Jan Loeffler 氏は書いています。
AmbassadorFestでの講演の中で、 「The Phoenix Project」と「The Unicorn Project」の著者であるGene Kim 氏は、運用チームが社内プラットフォームの有効性を理解するために使用できるいくつかの有用な指標を提供しました。Kim のDaniel Bryant氏が Twitter で発言したと引用されました。
「運用チームにとって、適切な尺度は、アプリケーション配信チームから定期的にどれだけ多くの『感謝』を受け取るかです。最終的な目標は、繰り返し発生する障害を解決し、導入の手間を軽減し、顧客に価値を提供しやすくすることです。」@ #AmbassadorFestで講演するRealGeneKim pic.twitter.com/bQfpAPvPA
— ダニエル・ブライアント (@danielbryantuk) 2020 年 11 月 17 日
開発チーム
内部開発者プラットフォームの恩恵を受けるコアチームは、組織の開発チームです。開発チームは多くの場合、新機能を市場に投入したり、組織の日常業務の中核となる内部システムを構築したりするなど、膨大なタスクを抱えています。
開発チームは多くの場合、運用チームまたは DevOps チームがアプリケーションをデプロイしてテストするための環境を作成するまで待つ必要があります。特定のアプリケーションの CI/CD を担当する集中プラットフォームがないと、開発チームは自分たちにとって最適なものを選択する傾向があります。その結果、「組織全体の制御または監査機能が制限される」とJan Loeffler 氏は説明します。これにより、個々のチームが自分たちが最もよく知っているツール、またはたまたま愛用しているツールを採用してワークフローを構築するため、組織全体に多くのツールが無秩序に拡散することになります。これによりツールが無秩序に拡散するだけでなく、厳しい地域要件や PCI 要件を持つ組織にとっては多くの問題が発生する可能性があります。
KubeCon North America 2020 では、多くの参加者がインフラストラクチャのセルフサービスに対する開発者の必要性を強調したとDave Sudia 氏は述べています。
プラットフォーム構築の文脈では、アプリ開発者は主要な顧客であり、使いやすさは開発者エクスペリエンスの重要な部分です。クラウド ネイティブ プラットフォームの価値は、開発者がプラットフォームによるサービスの実行方法を迅速かつ安全に構成できると同時に、アプリケーションをエンド ユーザーにリリースする方法を構成できる能力を持たない限り、完全には実現されません。
社内開発者プラットフォームを使い始める方法
通常、チームは最初に CI/CD、コードとしてのインフラストラクチャ、および Kubernetesへのアプローチを形式化し、標準化します。これらのテクノロジーは、ほとんどの社内開発プラットフォームの構成要素を形成します。プラットフォームを製品として確立することは、社内開発プラットフォームを成功させるための重要な要素です。
Evan Bottcher は、成功する IDP を構築するための3 つの重要な前提条件を強調します。
- プラットフォームは、構築と実行を担当する長期的かつ安定した製品チームを必要とする製品です。
- アプリケーションを実行する責任の一部またはすべてを、一元的な運用とサポートではなく、アプリケーション チームに任せる必要があります。
- 第三に、実行の厳密な一貫性と自律型アプリケーション チームに与える自由と責任を犠牲にする必要があります。
一方、Micheal Coté は、 「ビジネスのボトルネック」に関するレポートの中で、製品としての社内開発者プラットフォームを確立するという製品アプローチが成功の鍵である理由を強調しています。
製品アプローチでは、ソフトウェアのライフサイクル全体を検討します。つまり、ソフトウェアは役に立つか、顧客やユーザー、ひいてはビジネスに役立つかどうかです。すべては顧客と市場のフィードバックを収集し、それに応じてソフトウェアを継続的に変更することを中心に展開します。
これは、ビジネスがソフトウェアの提供に依存している企業向けに書かれていますが、社内製品にも同様に適用され、チームは外部の顧客とやり取りしているかのように成果物を管理するタスクが得られます。
Camille Fournier は、Medium の記事「社内プラットフォーム向けの製品」に次のように書いています。
あなたがプラットフォーム エンジニア、エンジニアリング マネージャー、PM のいずれであっても、顧客を重視してプラットフォーム製品の戦略を立てる必要があることを忘れないでください。影響力と価値を実証するための明確な戦略がなければ、見落とされ、人員不足に陥り、優れた新テクノロジーでそれを解決することはできません。
社内開発者プラットフォームの主要コンポーネント
内部開発プラットフォーム (IDP) は、開発チームに一貫したエクスペリエンスを提供するために密接に結合されたツールとシステムのコレクションです。
これらのプラットフォームは、それを構築するチームと同様に独特であることが多いですが、多くの異なるビジネスで見られるコンポーネントとパターンがあります。Internaldeveloperplatform.orgのチームは、これらをきちんとしたリスト (アプリケーション構成管理、インフラストラクチャ オーケストレーション、環境管理、展開管理、ロールベースのアクセス制御) にまとめました。これらのそれぞれについて詳しく説明し、重要な領域のいくつかに焦点を当てます。
アプリケーション構成管理
多くの異なる環境でアプリケーションの構成を管理することは、特にアプリケーションが多数の異なるサービスやプラットフォームで構成されている場合、簡単に複雑になる可能性があります。内部開発者プラットフォームは通常、コードと同じ方法でアプリケーション構成を管理します。ソース管理プラットフォームを使用してアプリケーション構成を維持することで、バージョン管理や変更管理などのいくつかの重要な機能が可能になります。
アプリケーションの複雑さが増すにつれて、アプリケーションの実行、展開、管理に必要な構成も複雑になります。SCM に保存される構成の範囲を拡張することにより、中央の場所からの外部依存関係の構成と、関連するアプリケーションのバージョン管理が可能になります。
インフラ調整
内部開発者プラットフォームは、組織内の既存および将来のインフラストラクチャと互換性がある必要があります。これは、拡張可能なプラットフォームを構築することで実現されます。内部開発者プラットフォームは通常、パイプライン、クラスター/サーバー、ネットワーキング (DNS、ファイアウォール、ルーティング)、レジストリ、アーティファクト リポジトリなどを含む、組織のツールチェーン全体にわたって広範に統合されています。
理想的には、内部開発者プラットフォームがコードとしてのインフラストラクチャの背後にある推進力となり、ソリューション内のコンポーネントをプログラムで定義および管理できるようになります。通常、個々のチームまたは DevOps チームは、 Terraformなどを通じてインフラストラクチャを構築およびデプロイします。ただし、既存のスクリプトを内部開発者プラットフォームに統合すると、チームは既知のスキーマを持つディレクトリを使用できるようになります。
環境管理
多くの場合、新しい環境の構築には、プラットフォームの機能、チームのボトルネック、さらにはコストの制約が混在する課題が発生します。チームは、たとえ小さなことをテストするだけでも、環境が整うまで数日または数週間待つ必要があることがよくあります。内部開発者プラットフォームは、新しいアプリケーション環境を総合的に処理し、アプリケーションのすべての依存関係を 1 つの環境で実行できるようにまとめます。これにより、開発チームは必要に応じてセルフサービス環境にアクセスできるようになります。これによりボトルネックが大幅に軽減され、開発チームがより迅速に開発できるようになります。
社内開発プラットフォームのこの機能を活用すると、開発チームにとって新しいテスト環境の必要性をはるかに上回るメリットが得られます。これにより、チームは必要に応じてアプリケーション スタック全体とそのすべての依存関係を起動し、不要になったときにそれらを破棄することができます。これは、サービスの使用が消費パターンに基づいており、パフォーマンス テスト環境などの大規模な環境のアイドル状態は多くの場合コストがかかるクラウド環境で特に有益です。
導入管理
ソフトウェアを消費者に配信することは、組織内の開発チームにとって重要な役割であり、迅速な配信の必要性はよく知られた課題です。継続的インテグレーションと継続的デプロイメントの採用により、開発がより迅速かつより頻繁にデプロイされるようになりましたが、多くの場合、それぞれに独自の課題や問題が伴います。
内部開発者プラットフォームを開発ライフサイクルに組み込むことで、ターゲット環境へのすべての自動展開の中心点になります。内部開発者プラットフォームは、デプロイされたバージョンとそのデプロイメントに関連するプロジェクトを担当する自動化されたオートマトンになります。この統合は通常、 Webhookを使用して行われます。
アプリケーションと関連要素がデプロイされると、内部開発者プラットフォームは通常、すべてのデプロイメントのデバッグのための集中ポイントを提供し、アプリケーション バージョンの集中ポイントとして機能し、デプロイメントと同じ場所からロールバックを実行できるようにします。
役割ベースのアクセス制御
ロールベースのアクセス制御 (RBAC) は無視できない要素であり、複数のチームが共有プラットフォームを利用するため、どのプラットフォームでも除外することはできません。効果的な RBAC ポリシーでは、個々のチームがプラットフォームとやり取りする範囲が制限され、組織内での役割に基づいてメンバーを分離することもできます。
どのチームがプラットフォームとの対話を許可されるかを管理すると同時に、権限のない個人が獲得できる爆発範囲も制限します。Kubecon EU 2021でのプレゼンテーションで、Ellen Körbes と Tabitha Sable は、欠陥のある組織の Kubernetes RBAC ポリシーに関連するリスクの一部を詳しく掘り下げました。会議からの引用は、「私たちはスターでできていますが、RBAC はそうあるべきではありません」というもので、これは、環境内のシステムやリソースへのオープン アクセスがあってはいけないことを意味します。
結論は
最後に、社内開発者プラットフォームは、組織のデジタル変革と成長にとって重要な要素です。開発チームが顧客を喜ばせ、ターゲット市場で会社を成長させるソリューションの構築に集中できるようにすることによって。ただし、組織内の他のプロジェクトと同様、チームの利用と構築に対する影響を理解するには、プロジェクトを測定する必要があります。この点では、社内開発プラットフォームも例外ではありません。
社内開発者プラットフォームを成功させる最大の原動力は、エンド ユーザー (開発者) からのフィードバックを収集し、プラットフォームの成長に合わせてそのフィードバックを組み込むことによって、プラットフォームの作成と管理に製品の考え方を採用することです。
取り組みの各ステップで重要なのは、開発チームと運用チームの注意を成果物からそらす次のタスクや問題を見つけることです。これにより、運用チームにとっては、実際のビジネスクリティカルな問題に取り組むことができ、開発チームにとっては、最終的にビジネスを成長させる機能や製品を構築できるようになります。
