こんにちは。取締役兼ACS事業部の責任者の上林です。
前回は「プラットフォームエンジニアリングの概要」について書かせて頂きました。前回注目されている背景として、さらっと「アジャイルやDevOpsの組織的な推進」と書きましたが、今回はその点を確認していきます。歴史的な背景をもう少し深堀しながら、紐解いていきたいと考えています。なにかのお役に立てば幸いです。
アジャイルとDevOpsの誕生
大きく端折って書くと、1990年代に大規模な開発の反作用としてRAD、スクラム、XPなどの開発の方法論の議論があり、2001年には象徴的に「アジャイルソフトウェア宣言」が登場します。その後、webサービスの発展により、開発の方法論だけでなく、サービスの安定性がより求められ、技術の専門性の高まりも相まって、DevとOpsの溝が深まります。その課題を解決する概念として2009年にDevOpsは誕生しました。
DevOpsの定着
アジャイルやDevOpsは非常に強固な概念でしたので、その後2010年代、概念は数々のプラクティス、ツールを生み出していき、スタンダードになっていきます。ちなみに、実際にはGoogleは2003年からSREを、Amazonでは2006年に最高技術責任者Werner Vogelsさんが「You Build It You Run It」という有名なセリフを残していますので、メガテック企業が先行して投入していた概念やプラクティスが徐々に業界に広がり、議論を加えながら発展を遂げていったということかと思います。
技術とツールの発展・リリース速度の向上
2010年代に入ると、技術的にも、クラウド、開発ツール、コンテナなどの技術が発展していきます。ちょっと確認しましたが、AWSが誕生したのが2006年、GitHubが2008年、IaCの概念も2008年、DBだとBigTableが2006年、Dynamoが2007年、Cassandraが2008年でしょうか。そしてコンテナだとDockerが2013年、k8sは2014年にGoogleがOSSとして寄贈しCNCFが誕生します。そんな中、2012年のre:inventでAmazonでは1時間に1000回デプロイするという発表を、2014年にはGoogleはすべてのソフトウェアをコンテナ化し毎週20億個のコンテナを起動しているという発表があり、業界を驚かせました。
その後、そういった技術も誕生・発展させていったGAFAMはもちろん、NetFlix、Spotify、Uberなどのデジタルを駆使したメガテック企業が発展していき、既存の業界をディスラプトしていきます。デジタルが産業の競争力として注目され、その競争力の源泉としてリリース(デリバリー)の速度が重視され、業界はより顧客価値の高い機能を、もっと早く、もっと品質良く、ということを求めて発展していきます。
開発チームの周辺で発生していること
このような外部環境の中で、リリース速度の向上のため、開発チーム周辺にも大きな変化が発生してきました。自整理すると大きく3つの変化があると考えています(整理の仕方は私見です)。
①開発チームの責任範囲の増大
②開発チームの規模の拡大
③技術やツールの増加による学習コストの増大
それぞれ見ていきたいと思います。
①開発チームの責任範囲の拡大
DevOpsによってプロダクト開発を行うチームがより速度を求めていったときに、他チームへの依頼は最小限にとどめる必要があります。そのために必要なのは、開発チームのクロスファンクショナル化(フルスタック化)によるオーナーシップの拡大です。Opsと言われる運用や監視のみならず、QAチームのテスト機能、インフラチームのデプロイの機能、フロントエンドであれば場合によってはデザインも、そしてなによりビジネス面にも拡大します。顧客からのフィードバックを即座に反映していくためにチームがプロダクトオーナーとともに機能自体も企画していく、それらすべての機能をチームの中に取り込む必要があります。
そういった要求を満たすように技術も進化してきています。コンテナ技術も上記のようなリリース速度を向上するために、アプリ開発者がインフラをコントロールする必要性の中から生まれてきたとも言えます。まさに「You Build It You Run It」の世界です。
更に、制約条件としてDevOpsのチームは2ピザチームとも言われ、コミュニケーションコストを考えると5-8名程度がベストであると言われます(諸説あります)。その少人数の中でそれれらの作業を完結しつつ、チームを維持しなければなりません。新たなメンバーの教育ももちろんチームの責任になります。
こういった、少数での開発チームの責任範囲の拡大と技術の進化は認知負荷を増大させます。
②開発チームの規模の拡大
デジタルによるビジネスが拡大すると、システムの数は増えて機能も増えます。更にDevOpsにおいては継続的にシステムや機能を維持・改善していく必要もあります。そのために、開発チームも拡大させていく必要があります。開発チームが増えると役割分担や連携の複雑性が生まれます。
特にマイクロサービスは大変です。各チームが独立的にデプロイを行うために各チームでデプロイメントパイプラインをメンテナンスし、これまで不要であったトレーシングなど概念が増えます。サービスメッシュやら、サーキットブレイカーなんてことも考えないといけませんし、そこにまたツールが登場し、そのメンテナンスも考える必要が出てきます。余談ですが、昨今、サービス系企業で一気にマイクロサービスでなく、まずはモジュラーモノリスを志向するお話が増えたのも、こういった複雑性に対する一つの選択肢と言う認識です。
マイクロサービスでない場合でも、開発チームが増えていく場合、役割分担や連携の課題が出てきます。各チームの情報がサイロ化しどこにAPIやドキュメントがあるかわからず探す手間が増える、チーム間の依頼の仕方がわからない、ナレッジなどが共有されづらく知らずに車輪の再開発を行っている、などは頻出する問題です。PayPalなどが実践するInnerSourceなどの活動はこういった課題に対するアプローチです。
また、規模の拡大の為に必要なスキルが高いと、人材不足が顕著な日本においては組織拡大の為の採用の課題にもつながっていきます。
これらの開発チーム間の役割分担や連携もまた、開発チームの認知負荷を増大させます。
③技術やツールの増加による学習コストの増大
前述のとおり多くの技術やツールが発展しています。主要パブリッククラウドのサービス数だけでも、AWSで約200種類以上、Azureで約250種類以上、GCPで約165種類以上あります。専門家である我々でも正直全部わかっていませんｗ そしてパブリッククラウドのベンダーロックインを避けるという動機もあったかと思いますが、特にクラウドネイティブの中心であるCNCFでは、k8sを中心としたエコシステムが劇的に発展しています。プロジェクトは1000以上です。最近はプロジェクトが一覧となるCNCF Landspcpeも重すぎて開きたくなくなるレベルですし、ハズキルーペが必要なレベルでアイコンが小さいです…。
CNCFのクラウドネイティブアプリケーションを開発するツール増大に対する貢献は偉大です。ミシュランガイドで一番星の数の多い日本の飲食店は規制が少ないからこそ発展した、という主張がありますが、CNCFも似たように自由にk8sエコシステムを発展させてきたからこれだけ発展し、プロジェクト数が増えた言えると考えています(雑な例えですみません…)。
発展はすばらしいのですが、光があれば影も生みます。数が増えればツールの選定は難しいですし、学習コストも増えます。こなれていなければ検証コストもまたかかってきます。余談ですが、CNCF内で複雑性を解消する動きもあります。Microsoftさんが取る、KEDAやDAPRなどをOSSとしてコミュニティと開発しながらAzure Container Appsというサービスに取り込んでいく戦略は、一つの方向性としては評価されて行っているのではないでしょうか。
いずれにしても、ツールの増大、これもまた開発チームの認知負荷を増大させます。
開発チームの認知負荷の増大と開発者体験の低下
これらの状況をまとめた表として、infoqさんの記事のこの画像がわかりやすいと思います。
引用：「Platform Engineering 101: What You Need to Know about This Hot New Trend」
特に2015年以降、開発チームの認知負荷の上昇しているのがわかりやすいですね。開発者体験は低下し、開発効率もまた低下することになってしまいます。では、それを改善する方法はあるのでしょうか？ やはりDevOpsは間違いで改めて開発とOpsやインフラの役割分担を元の通り分担していく必要があるのでしょうか？
もちろんそういうわけにはいかないと思います。確かに一部役割分担は必要ですが、違った形でそれを実現していく必要がありそうです。はい、ようやくですがそこにプラットフォームエンジニアリングが登場します。前回のお話の繰り返しになりますが、「開発者チーム」の「開発者体験と生産性向上を目的に」「プラットフォームエンジニアリングのチーム」として「セルフサービスのプロダクト型で」価値を提供していく、わけです。
DevとOpsを改めて分割するのではなく、開発チームの責任範囲の拡大は維持しながらも、新たな役割分担や連携方法を考えていく必要があるわけです。そのための原則とベストプラクティスがプラットフォームエンジニアリングです。
プラットフォームエンジニアリングはこれから更に発展していく概念だと思っていますが、k8sなどがそうであったように、すでにメガテック企業を中心に実施してきた概念が原則やプラクティスとして整理されたものでもあります。もしかすると3年後に名前は変わっているかもしれませんが、形を変えて発展していけばよいと考えています。例えば、標準化と各チームの最適化を具体的なプラクティスとしどう行っていくか、など、色々な側面でまだまだ議論の余地があると考えています。ただ、重要なのは以下で、これさえぶらさなければ良いのではないでしょうか。
「開発者体験や開発効率化に寄与すること」
「原則やベストプラクティスとして議論のたたきになり業界内で発展すること」
最後に日本での動向
DevOpsの発展にプラットフォームエンジニアリングが必要になるのかについて、いかがだったでしょうか。
またまた、ボリュームが多くなってしまった結果、本当は海外の動向や事例なども紹介したかったのですが、半分くらいに記事を削りました。またの機会にさせて頂ければと思います。最後に日本の動向を少しだけご紹介。
本日(2023/3/9)、「Platform Engineering Meetup #1」が開催されます！ HashiCorpの草間さんの呼びかけで開催されることになりました。PlatformEngineeringの概要を草間さんがご説明。CyberAgentの青山さんも登壇予定です。今回、弊社も場所及びフードスポンサーとして手を上げさせて頂き、スポンサー枠としてSpotifyの開発者ポータルOSS「BackStage」について語らせて頂きます。その後ディスカッションパートも設定しています。まだリモートには若干名の空きがありますので是非ご興味がある方がいればご参加いただければと思います。
「Platform Engineering Meetup #1」 platformengineering.connpass.com
書かせて頂いたように、まだまだ未成熟なこの領域、課題も多いと思います。コミュニティ内で議論しながら少しでも貢献していければと考えています！
