プラットフォームエンジニアリングの過去・現在・未來

過去：開発者からプラットフォームエンジニアリングへの転換

早期開発者時代（30年前）

• コーブル（Cobble）、パイソン（Python）、ジェーヴァ（Java）などの言語を用いてコードを書く
• テストやビルドなどの繰り返し作業により、自動化ツールの必要性が生じる
• モダンなツールではなく、スクリプトを用いて手動操作を減らす

ジェーヴァアプリケーションサーバー時代

• アプリケーションサーバーを使用して繰り返し開発を減らす
• 共有ライブラリを構築し、アプリケーションの再利用性を高める
• 実裝ロジックに集中し、実行環境に注力しなくなる

ツールの臺頭とプラットフォーム概念の萌芽

• ジェンキントス（Jenkins）（20年前）：最初の內部開発者プラットフォームツール、APIとUIを提供
• ドッカー（Docker）（15年前）：アプリケーションのパッケージングと実行方法を変革、コンテナ化を推進
• メソス/Kubernetes：コンテナを生産環境で運用する課題を解決し、産業共識を形成

現在：プラットフォームエンジニアリングの標準モデル

コアモデル

• サービスオーナー（Service Owner）：AWSのEC2サービスなど、開発・管理を擔當
• サービスコンシューマー（Service Consumer）：サービスを利用する開発者やチーム
• APIとコントローラー（Controller）：
  • すべてのサービスはHTTP APIを通じて相互作用
  • コントローラーがAPIリクエストを処理（例：K8sクラスターの作成）

Kubernetesを基盤としたインフラストラクチャ

• 現在のプラットフォーム構築はすべてKubernetesを基盤としている
• サードパーティのコントローラー（例：Argo、Crossplane）や自前の実裝を選択
• 核心能力の要件：
  • 拡張性（サーバーレス）
  • 可観測性（Observability）
  • セキュリティ（Security）

プラットフォームエンジニアリングのキーパス

1. API設計：サービス間の相互作用を定義
2. コントローラー開発：リソース管理と自動化を処理
3. ユーザー體験の最適化：ダッシュボードの構築や操作の簡略化（curlコマンドの代替）

未來：カスタマイズとブループリント（Blueprints）

プラットフォームの領域特定化

• 組織のニーズに応じて獨自のAPIとコントローラーを構築
• 例：Crossplaneがインフラスラコード（Infrastructure-as-Code）の機能を提供
• Backstageなどのツールを用いて複數のK8sプロジェクト（Argo CD、Kube）を統合

ブループリント（Blueprints）の臺頭

• 産業がプラットフォームブループリントを公開（例：BackstageがCrossplane、Argoを統合）
• 組織がプラットフォーム構築にかかる時間と複雑さを削減
• 今後のトレンド：
  • 跨K8sクラスターまたはクラウドでの自動化リソース管理
  • より高い拡張性とセキュリティの統合
  • ユーザーフレンドリーなインターフェースとリアルタイムモニタリング

技術統合と進化

• Kubernetesエコシステム（CNCF）に依存
• コントローラーとAPI設計の継続的な最適化
• より柔軟でカスタマイズ可能なプラットフォームアーキテクチャへの進化

結論

• プラットフォームエンジニアリングの未來はコミュニティ協力、標準化、技術統合に依存
• AIの統合はプラットフォームエンジニアリングの核として、セキュリティ、ガバナンス、可観測性を確保する必要がある
• 技術の進化に伴い、継続的な學習と適応が求められる