プラットフォームエンジニアリング ―成功するプラットフォームとチームを作るガイドライン

結び

この書籍を執筆する前に著者である私たちが自問したのは、過去25年間にわたって業界を席巻してきた他の多くの一時的流行†1と、プラットフォームエンジニアリングは同じなのかということでした。それについて私たちが書いてきた約10万語によって、あなたはそうではないと納得しているのを期待しています。とは言え、プラットフォームエンジニアリングがテクノロジのハイプサイクルの犠牲になる現実的なリスクを感じています。ベンダが独自実装を推進し、コンサルタントがチェックリストを作成する中で、私たちは経営陣向けダッシュボード用の何らかの指標を優先して、微妙なニュアンスを失う危険にさらされています。

[†1] 名前は挙げませんが。

だからこそ、私たちは第Ⅰ部で、業界が今日直面している複雑性の変曲点について多くの時間を費やして話しました。クラウド、ベンダ、OSSエコシステムは、ビジネスが求める分野での技術革新を加速させました（2024年では、AI関連のあらゆるものがその対象です）。しかし、サーバをペットとして扱い、独自のベンダプラットフォームを使用していた1990年代よりもソフトウェアのシステムをシンプルにすることはありませんでした。フラストレーションは、データセンターエンジニアとの対応から、Terraformの「コードベース」のコピー&ペースト的な性質との格闘へと移りましたが、複雑性は残ったままです。実際、継続的なイノベーションへの推進力とレガシーシステムを統合する必要性により、全体的な複雑性は増大し、1章で議論した過度に一般化された泥沼状態を招いています。

この業界は、プラットフォームをハイプサイクルの具体的な実装（IDP†2など）であると考えたり、盛り上がっているアプリケーションチームが将来のコストを考慮せずにベンダやOSSシステムを結合するために使用する、アドホックなグルーとしてプラットフォームを捉えることから脱却する必要があります。これらの都合のよいアプローチを乗り越え、アプリケーションチームを説得するには、 ...