これはなんの記事?

最近Platform Engineering Meetupというイベントに参加してもっと知りたいと思ったはいいものの何をしていいかわからなかったので、コミュニティと記事を漁ってみました。
Platform Engineering Communityというコミュニティと記事読んで簡単に要約したものを書いています。

What is platform engineergin?

プラットフォームエンジニアリングはクラウドネイティブ時代のツールチェーンとワークフローを設計・構築する分野。

プラットフォームエンジニアはアプリケーションのライフサイクル全体の運用上の必要性をカバーする「内部開発者プラットフォーム」IDP(Internal Developer Platform)という統合製品を提供する。

IDPは基盤となるテクノロジーを保持しながら、開発者の認知負荷を軽減する統合されたツールが含まれる。

From the ashes of DevOps: the rise of Internal Developer Platforms

DevOps概念の定着によりスケーラビリティ・可用性等の改善がもたらされた一方で、複数ある環境の一つに簡単なコード変更をデプロイしてテストするだけでもTerraform, Helmなど複数のツールを習得する必要がありました。

業界は、ツールチェーンの進化を通じて開発と運用の分業が得策ではないと判断しているように見えます。

つまり開発者がアプリとサービスをエンドツーエンドで展開・実行できる必要があります。真のDevOps
しかしほとんどの企業にとってかなり非現実的です。

真のDevOpsを実装しようとすると多くのチームで、より上級の開発者がインフラなどの管理責任を負うことになり、エンジニアに「シャドウオペレーション」が生まれます。これは高価なリソースを無駄遣いしています。

上級開発者の支援を必要とせず、開発者がアプリやサービスを実行できるようにするには？

上で触れたIDPが登場します。
IDPを使用する開発者は好みに応じて抽象化レベルを選択できます。(Helm, Terraformなどの好み)

IDPによりアプリがどこで実行されているか気にせずに、コードのデプロイ・テストに必要な環境がセルフサービスで利用できるようになります。

Golden paths and paved roads

現在ほとんどのCI/CDは単にイメージを更新することに重点を置いており、これはデプロイのユースケースをカバーできていますが基本的なワークフローを超える場合、複雑になり時間がかかります。

環境変数の追加と構成の変更
サービスと依存関係の追加
ロールバックとデバッグ
新しい環境を立ち上げる
リファクタリング
リソースの追加・変更
RBACの強制
など。

これらを実行する上でツールチェーン全体を学ぶ必要がなく、舗装された道路として結びつけるためにIDPが役立ちます。

プラットフォームは「セルフサービスAPI、ツール、サービス、知識、サポートの基盤」。

Principles of platform engineering

成功したプラットフォームチームとセルフサービス主導の組織に共通する原則。

明確な使命と役割
プラットフォームを製品として扱う
よくある問題に焦点を当てる
プラットフォームの価値を宣伝する
- 純粋なコストセンターだとみなされる
車輪の再発明をしない
- CIシステム、メトリクスダッシュボードなどはすぐに商用製品に追いつかれます。組織の特定のニーズに焦点をあてること。

いつプラットフォームエンジニアリングが必要になるか

プラットホームエンジニアリングは大規模なチームでのみ意味をなすと誤解されます。
5人の開発者で構成されるチームには確かに過剰であるが、組織の開発者が20~30人を超えたら検討の必要があります。

Slackチャンネル

リダイレクトされます。
ユースケースの共有などがされています。

IDP(Internal Developer Platform)

ここからはInternal Developer Platformの記事の要約です。

What is IDP

様々なツールで構成された開発者の認知負荷を軽減するための製品です。
ベストプラクティスに従い、プラットフォームを製品として扱いユーザー調査によって継続的な改善を行うことが大切です。

開発者は何ができるようになるのか

IDPにより通常のgit-pushデプロイワークフローにさらなる自動化が追加されます。
アプリケーション開発者は完全にプロビジョニングされた環境のスピンアップ・デプロイ・ロールバックなどを自律的に行えるようになります。

5つのコアコンポーネント

詳しくはこちらを参照。core-components.

Application Configuration Management
Infrastructure Orchestration
Environment Management
Deployment Management
Role-Based Access Controll (RBAC)

開発者はEnviron Management, Deployment Management, 一部のApplication Configuration Managementを利用します。

IDPの構成ツール

IDPはすでに導入されている既存のツールで構成されている。

とあるので新しい画期的なツールで実現されるものではなく、既存ツールの統合ということになりそう。

開発者が新しい環境を要求してきた際にプラットフォームチームは新しい名前空間にセットアップします。この時にCIツールによる更新, DB, DNSなどの外部リソースが接続されている状態にある必要があります。

以下はIDPで使用されている一般的なツールです。(CNCFのlandscapeに似ていて、薄暗いカードはgraduatedではなくリンクの有無です。)
脳死でこの中から選ぶのではなくチームの使命を思い出す必要がありそう。
Platform tools.

5つのコアコンポーネント

よりイメージができるようにそれぞれ書いていきます。

Application Configuration Management

Document.
重要なのはIDPに閉じ込めないこと(さもないとIDPがSPOFになる)。

IDPを使用していない典型的な例。

IDPを利用している例。

Infrastructure Orchestration

Document.
次の図はIDPの一般的な統合ポイントの概要です。
ポイントは2つで、できるだけ多くの既存の設定が統合されていること、必要に応じて独自の統合を提供できること。

Environment Management

Document.
以下はIDPを使用しない例。
新しい環境の作成には他のチームに要求して待ち時間が発生したり、次の使用の機会に備えて環境を残しておいたりします。

IDPを使用する例。
宣言方のアプリケーションを強制でき、デプロイの時に動的にマニフェストが生成されます。
UI, CLI, APIでの様々な方法を提供するのが一般的で、環境の作成と破壊・一時停止の自動化をサポートする必要があります。

Deployment Management

Document.

こちらには図がないようでした。
理想は、開発者はコードを書くこととテストに集中できるようになるように出来るだけの自動化を提供することです。

Git push

CIにより自動化されたテストやイメージがビルドされたらIDPは新しいイメージが利用可能になったことを通知します。

Automated Deployment

IDPによりイメージがどの環境にデプロイされるか定義されています。
このデプロイプロセスは開発者の介入なしに完全に自動化される必要がある。

Triggered next steps

IDPはデプロイの自動化では終わりません。
例えは、デプロイプロセスが成功したらコミュニケーションツールへ通知したり、完全なend-to-endテストをトリガーしたりします。(一般的にはWebhookが使用されます。)

Additional

デプロイが失敗した際のログの提供とデプロイ履歴の中央メモリとなることで監査プロセスを簡素化できます。

RBAC

エンタープライズレベルの細かいコントロールについて。
理想は、組織の役割とアプリケーション固有の役割に分割すること。

役割の例

Member
Machine
Manager
Admin

アプリケーション固有の例

Viewer
Contributor
Owner

When do you need an Internal Developer Platform (IDP)?

IDPが意味を成さない場合

1~15人の小規模なチームで上級のエンジニアで構成されている場合
モノリシックなアプリケーションの場合
シンプルなシングルクラウド構成のインフラで、アプリケーションが1つである場合

IDPが意味をなす場合

マイクロサービス
DevOpsチームがSLAやワークフローに集中できなくなってきた場合
開発者が依存関係により作業が妨げられている場合
マルチクラウド

How do Internal Developer Platforms (IDPs) relate to other concepts?

この業界では多くの概念が飛び交っているためIDPとは何かを明確にしておきましょう。

What is an IDP?

“An Internal Developer Platform (IDP) is built by a platform team to build golden paths and enable developer self-service. An IDP consists of many different techs and tools, glued together in a way that lowers cognitive load on developers without abstracting away context and underlying technologies. ”

ここに書いてある通りで、これ以上短縮できないと思います。
つまり、開発者のセルフサービスのためにプラットフォームチームによって作られるものです。
IDPは多くの異なるツールで構成されていて、開発者の認知負荷を下げ根底にあるものを抽象化します。
そして、ユーザーリサーチを元に継続的なメンテナンスと改善が大切です。

Integrated Development Environment (IDE) tools (Visual Studio Code, Eclipse, Xcode, etc.)
Version Control Systems (VCS) (GitHub, GitLab, etc.)
CI tools (Circle CI, GitHub Actions, Bitbucket)
Container registries (Docker, Harbor, etc.)
Platform orchestrators (Humanitec)
Developer portals and service catalogs
Kubernetes control planes
GitOps tools / CD controllers (ArgoCD)
IaC (Terraform, Pulumi, etc.)
Databases/storage
DNS
Managed or self-hosted Kubernetes
Cloud providers

これら以外にもモニタリング、ロギング、セキュリティなどのカテゴリがありますが、IDPとの重複で誤解されているものに焦点を当ててみます。

Developer portals/service catalogs

開発者ポータルとサービスカタログは IDP へのアクセスポイントとして機能し、開発者がプラットフォームの機能を発見するためのUIを提供できますが、IDPではないカテゴリがさらにあります。

End-to-end DevOps platforms and PaaS solutions

end-to-endのDevOpsプラットフォームやHerokuのようなPaaSはIDPとしては使用できません。より深いレベルまで変更ができないからです。

Environment as a Service

セルフサービスを目的としたEnvironment as a Serviceは特定の業界には意味がありますが、IDPとの統合はほぼ不可能です。

まとめ

IDPを構築して開発者の認知負荷を軽減し、根底を抽象化することができる
ユーザーリサーチを元に継続的な改善とメンテナンスが必要
そのために、原則に従って社内の特定のニーズを解決する。商用製品との差別化が重要
開発者が20~30人を超えた辺りから必要になる
IDPとは製品であり、全く新しいイケてる技術ではなく既存のツールの統合により構成される
5つのコアコンポーネントという考え方がある