プラットフォームをプロダクトとして扱う

第1章 プラットフォームの急務なぜ 今、 社内プラットフォームが 不可欠な のか？

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

近年、ソフトウェアデリバリーの課題は変化している。もはやコードを迅速に出荷するだけでは十分ではない。デリバリチームは、安全性、コンプライアンス、可観測性、適応性、レジリエンスを確保しなければならない。従来、組織は開発者を増やし、サービスを増やし、インフラを増やすことでエンジニアリングの規模を拡大してきた。最近では、AI支援開発、サードパーティ・サービス、クラウド・リソースを採用する企業もある。どのパスを選んでも、ソフトウェアの提供と運用の複雑さは急速に増している。

カミーユ・フルニエとイアン・ノウランドによる同名の著書で論じられているように、プラットフォームエンジニアリングという概念は、ソフトウェア提供における断絶の増大にレスポンスして登場した。¹クラウドネイティブテクノロジーはインフラをより強力で柔軟なものにしたが、同時に開発者が独立してソフトウェアを提供することを難しくした。Kubernetes、Terraform、継続的インテグレーション／継続的デリバリ（CI/CD）パイプライン、クラウドAPIは強力なツールだが、運用に大きなオーバーヘッドをもたらす。適切な抽象化がなければ、開発者はYAMLと格闘したり、チケットで待機したり、あるいはトレーニングを受けていない演算子を引き受けることを余儀なくされる。

そこで、プラットフォームチーム（大きなコンテキストではチーム）の出番となる。その役割は、単にツールを管理するだけでなく、社内開発者プラットフォーム（IDP）という製品を構築することである。

DevOpsからプラットフォームエンジニアリングへ

多くの組織が、DevOpsの経験を通してプラットフォームエンジニアリングにたどり着いた。DevOpsは責任の共有と迅速なデリバリーの文化を促進するが、アプリケーション開発者がすべてのインフラと演算子を直接引き受ける、あるいは引き受けられるという意味に解釈されることが多い。実際には、この曖昧な責任は、ツールの分断、一貫性のない環境、オーバーロードのチームを引き起こす。

見落とされがちなのは、DevOpsの原則は2つのレイヤーにまたがって適用されるべきであるということだ。アプリケーション・レイヤーは、アプリケーション・チームが構築したサービスを所有し、演算子として運用するレイヤーであり、プラットフォーム・レイヤーは、プラットフォーム・チームがプラットフォーム自体を製品として構築し、運用し、継続的に改善するレイヤーである。どちらのレイヤーも、自動化、継続的デリバリ、可観測性、フィードバックループを利用するが、異なるコンシューマーを対象とした異なるAPIを通じてそれを行う。

これは、"開発"、"運用"、"QA "といった古いサイロを再び導入することではない。プラットフォームエンジニアリングでは、APIをレイヤー化することで、責任の所在を明確にし、デリバリシステムの他の部分から切り離されることなく、チームが自分たちのドメインの開発とサポートに集中できるようにする。アプリケーションチームは明確に定義された契約を通じてプラットフォームを利用し、プラットフォームチームは同じ方法でインフラを利用する。各レイヤーは、APIが安定し、十分に文書化されていれば、独立して改善・進化することができる。従って、各チームは、懸念事項の分離を通じて価値のフローを所有する。これは、デリバリーのスピードを促進し、物事がどうしてもうまくいかないときの爆発半径を制限する。さらに、疎結合チームは、エンドユーザ/コンシューマにとってよりまとまりのある体験を作成することになる。 ...