Platform Engineeringのコミュニティを覗いてみた

# これはなんの記事?
最近[Platform Engineering Meetup](https://platformengineering.connpass.com/)というイベントに参加してもっと知りたいと思ったはいいものの何をしていいかわからなかったので、コミュニティと記事を漁ってみました。
[Platform Engineering Community](https://platformengineering.org/)というコミュニティと記事読んで簡単に要約したものを書いています。

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

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

> 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が役立ちます。

https://martinfowler.com/articles/talk-about-platforms.html

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

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

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

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

## Slackチャンネル
https://bit.ly/39z3ZRE

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

# IDP(Internal Developer Platform)
ここからは[Internal Developer Platform](https://internaldeveloperplatform.org/)の記事の要約です。
## What is IDP
様々なツールで構成された開発者の認知負荷を軽減するための製品です。
ベストプラクティスに従い、プラットフォームを製品として扱いユーザー調査によって継続的な改善を行うことが大切です。

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

### 5つのコアコンポーネント
詳しくはこちらを参照。[core-components](https://internaldeveloperplatform.org/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](https://platformengineering.org/platform-tooling).

## 5つのコアコンポーネント
よりイメージができるようにそれぞれ書いていきます。

### Application Configuration Management
[Document](https://internaldeveloperplatform.org/core-components/application-configuration-management/).
重要なのはIDPに閉じ込めないこと(さもないとIDPがSPOFになる)。

IDPを使用していない典型的な例。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/722539/b6b12d8b-b686-f0dc-d4cb-e9853a6e4015.png)

IDPを利用している例。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/722539/9e32e7dd-9ded-2058-2fff-a922200e19c2.png)

### Infrastructure Orchestration
[Document](https://internaldeveloperplatform.org/core-components/infrastructure-orchestration/).
次の図はIDPの一般的な統合ポイントの概要です。
ポイントは2つで、できるだけ多くの既存の設定が統合されていること、必要に応じて独自の統合を提供できること。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/722539/72a72109-9087-72b9-9bf2-8b8c03279acc.png)

### Environment Management
[Document](https://internaldeveloperplatform.org/core-components/environment-management/).
以下はIDPを使用しない例。
新しい環境の作成には他のチームに要求して待ち時間が発生したり、次の使用の機会に備えて環境を残しておいたりします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/722539/8ff092a6-f781-baae-a4fc-5c4d2c00b2a5.png)

IDPを使用する例。
宣言方のアプリケーションを強制でき、デプロイの時に動的にマニフェストが生成されます。
UI, CLI, APIでの様々な方法を提供するのが一般的で、環境の作成と破壊・一時停止の自動化をサポートする必要があります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/722539/ce9dec7b-f7ff-e089-6189-4ad78ff302dd.png)

### Deployment Management
[Document](https://internaldeveloperplatform.org/core-components/deployment-management/).

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

#### 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つのコアコンポーネントという考え方がある