なぜプラットフォームエンジニアリングが必要なのか
レガシーシステムをモダン化する際には、多数のレイヤーで構成されているDB・ミドルウェア・アプリケーションを、マネージドクラウドサービスやコンテナ化されたマイクロサービスに置き換え、三次元の立体的な構成に変更するケースが一般的である。
しかし、この場合、アプリケーションに関しては、マイクロサービス化やインターフェースの変更、プロトコル変更によるロジック分離やリファクタリング、そしてDBに関しては、スキーマ変更やインターフェースのリセット、他にもネットワーク設定やセキュリティ、リソースの再構成や運用ポリシーの変更など、新たにさまざまな課題を抱えることになる。これにより、ラーニングカーブが急激に上昇し、学習に必要な認知負荷も高まってしまう。
また、開発上の課題だけでなく、複数の部署との連携が必要となり、組織構成や責任の割り当てなどの組織的な課題も生じるだろう。実際、株式会社ジールのNoh Seontaek氏は、多くの部署から問い合わせを受けると同時に、“エラい人”を納得させるために多くの時間を要した経験があるという。
「これでは、せっかく改善するためにモダン化したはずなのに、結局、時間もお金もかかってしまっている。そこで、DevOpsを導入して、改善しようと考えた」（Noh氏）
DevOpsは、開発と運用のプロセスを統合して不要なコミュニケーションをなくそうとする概念であり、「You build it, you run it.（自分で作ったものは、自分で運用せよ）」という言葉で表現される。
DevOpsを導入したことで、開発チームの効率性は上がった。だが、時が経ち、プロジェクトが増えていくと、クラウドネイティブ技術やアーキテクチャの複雑さは増していく。開発者があらゆる業務や責任を負わなければならない状況に陥り、DevOps導入前よりも生産性が悪化してしまったのだ。
この問題にはオーストラリアのエンジニア Evan Bottcher氏も着目しており、「デジタルプラットフォーム」という概念を2018年に生み出している。さらにその翌年、デジタルプラットフォームの概念とDevOpsのアンチパターンを掛け合わせて誕生したのが、Matthew Skelton氏とManuel Pais氏が著した書籍『Team Topologies: Organizing Business and Technology Teams for Fast Flow』である。
Bottcher氏が提唱したデジタルプラットフォームは、のちに「内部開発者プラットフォーム（以下、IDP：Internal Development Platform）」として進化を遂げている。IDPとは、開発者がセルフサービス機能を活用できるよう、ツールチェーンとワークフローを設計・構築したものであり、アプリケーションのライフサイクル全体に必要な運用要件を包括している。そして、このIDPを提供するのがプラットフォームエンジニアであるというわけだ。
IDPがあれば、開発者は不要な負担を背負うことなく「You build it, you run it.」を実現して、自分の開発に集中することができるようになる。
そんなIDPを提供するプラットフォームエンジニアリングの目標は、次の3つであるとNoh氏は語る。
- Go faster（迅速に対応する）：エンドユーザー（開発者）に迅速かつ持続的な価値を届けるべく、「Everything as a Service」を提供する。
- Decrease risk（リスクを減らす）：再利用可能なコンポーネントで手動プロセスを自動化する。
- Increase efficiency（効率を上げる）：デジタルプラットフォームとリソースを、フリートとして管理・拡張する。
続いて、IDPの構築において最も重要であるというコンテナプラットフォームの話に入っていこう。
