プラットフォーム作りにありがちな失敗
過去数多のプラットフォームが生まれては定着せずに姿を消してきました。長く利用されるプラットフォームを作るのはとても難しいことです。ここでは、定着せずに消えていったプラットフォームはどのような特徴があったのかを説明します。
-
生まれながらに失敗しているパターン
- 開発者が欲しいものと全然マッチしていなかった
- 長期間開発し頑張って作り上げたが出した際はすでに技術が廃れていた
-
運用されずに失敗するパターン
- 特定の技術に依存していたため技術が廃れるのと同時に使わなれなくなった
- プラットフォームがリリースされたのと同時にプロジェクトチームが解散されメンテナンスされなくなった
- コストセンターと見なされ予算が割り振られなくなってプラットフォーム自体が縮小していき使われなくなった
上記のように失敗のパターンは数多く存在しますが、これらは先ほど説明した、「誰に」「何を」「どのように」の部分で利用者が求める価値と乖離してしまったことが原因です。継続的に「誰に」「何を」「どのように」の部分をアップデートし、利用者の求める価値を満たすプラットフォームを提供し続けることが求められています。
インフラチーム、SREチームとの違い
Platform Engineeringを話す上で、インフラエンジニア、SREとの違いに困惑される方が多いと思います。それぞれの役割とアプローチから、どのような違いがあるのかを考えていきます。
Platform Engineeringを担うPlatform Engineerは、開発者の開発効率を向上させる、いわゆるDX（デベロッパーエクスペリエンス）の向上に関心があるため、開発者の声を聞いて開発者のペインを解消するためのソリューションを提供します。
続いてSREはシステムの信頼性の担保に関心があるため、提供されているシステムを測定可能なサービスレベル（SLI、SLO、SLA）で表し、サービスレベルを満たすための活動を行います。
- サービスレベル指標（SLI：Service Level Indicators）とは、システムの可用性を特定するための主要な測定値およびメトリクスです。
- サービスレベル目標（SLO：Service Level Objectives）とは、外部からシステムに対して期待される可用性に関して設定された目標です。
- サービスレベル契約（SLA：Service Level Agreements）とは、合意された内容およびシステムがSLOを満たさなかった場合の対応を説明した契約です。
最後にインフラエンジニアはアプリケーションが動くためのインフラ基盤の提供に関心があるため、サーバーの選定、ネットワークやセキュリティの構築、ストレージサイズの選定といった活動がメインになります。
上記の違いをまとめると以下のようになります。各々クラウドといったITインフラを触るという点では似たように思われるかもしれませんが、役割やアプローチがそれぞれ違うことが分かっていただけたかと思います。
| Platform Engineer | SRE | インフラエンジニア | |
|---|---|---|---|
| 役割 | 開発者の開発効率を向上させる、プラットフォームの提供 | システムの信頼性と可用性の担保 | アプリを動かすためのITインフラ全体の設計・構築・運用 |
| アプローチ | 開発者が求める価値を満たすソリューションを提供し続ける | SLI、SLO、 SLAといった定めた指標を元に、運用を改善をしていく | アプリケーションの可用性を満たすサーバー・ネットワーク・ストレージといったインフラを提供する |
おわりに
第2回ではこれまでのプラットフォームと何が異なるのか、およびインフラエンジニアやSREとの違いを解説しました。プラットフォームの違いに関しては、過去のプラットフォームの失敗を踏まえ、toCにサービスを提供する場合と同じように「誰に」「何を」に注目してプラットフォームを提供することがポイントでした。また、インフラエンジニアやSREとの違いのパートでは、各々の役割とアプローチの違いに関して分かっていただけたと思います。
第3回では「Team topologies」や「Platform as a Product」といった考え方を説明します。
