00:00
こんにちは、ソフトウェアエンジニアの三田です。
こんにちは、ソフトウェアエンジニアの博多です。
ゆるテクは、三田と博多が緩く技術の話をするポッドキャストです。よろしくお願いします。
よろしくお願いします。
はい、というわけで、今日も2人で何かを話していきましょうというところで、
今日のホストは、私三田の方でネタをちょっとピックしてきたんですけれども、
これまた緩くないやつ持ってきましたね。
いや、今のうちだからこそ緩く話せるんじゃないかって思ってるんですけどね。
確かに。まだね、あんまり普及し渡ってないというか。
そうそうそうそう。
はい、という前振りがありつつ、今日のネタはですね、
最近、わりと界隈でプラットフォームエンジニアリングっていう言葉を見かけるようになったりとか、
勉強会とかでも聞くようになってきたなっていったところで、
特段、何でしょう、答えとかもないものなんですけど、
どう思います?っていうのを今日2人で話していければいいかなと思いました。
はい、先に言っておきますけど、自分はプラットフォーム的なものを作ったことも運用したこともないです。
あ、そうなんですね。
はい。
はい、じゃあその観点でも、何だろう、むしろフラットな気持ちで話ができるとより良さそうだなって思うので、ぜひ行きましょう。
聞く感じで行きます。
プラットフォームエンジニアリングの定義と起源
はい、でですね、少し始まりを話すと、私初めてこのプラットフォームエンジニアリングっていう言葉を見かけたのは、
CNCFのクラウドネイティブファンデーションのブログで見かけました。
はい。
その時、CNCFのブログを読んだ限りで言うと、CICD周りのプラットフォームであったりとか、
そういうところを提供するようなエンジニアリングだよ、みたいな、割と薄く書かれてて、
プラットフォームエンジニアリングって大きく名前を定義している割には、
すごい責任範囲というか、対応する範囲が狭いなって思ったんですよ。
今、三田さんから送ってもらったURLを見てますけど、そんなにふわっと書いてありますね。
クラウドのインフラストラクチャーのAWSとかAzureとかGCPとかがあって、
さらにその上にオートメーション周りとかがあったときに、
そこを主に担当するのがプラットフォームエンジニアリングだよ、みたいな感じで本当に薄く書かれてて、
それを読んだ時点だと、違和感も感じましたし、
じゃあそれってSREとそんな何か違うのかなっていう疑問を初めて見かけたときは感じてました。
そこからちょっともやもやしていく中で、どんどんどんどん日本語の情報も出てきていて、
これも白竹さんに事前に共有させていただいたんですけれども、
プラットフォームエンジニアリングへの招待でしたっけ、ちょっとタイトル名間違えちゃったかもしれない。
このスライドですね。
はい、スライド。
プラットフォームエンジニアリングへの招待っていうスピーカーデッカの。
そうですね。
スライドを読ませていただいて、そこに書かれてたこともまだ決まった定義はないんです。
っていうところで、だいぶじゃあこれって最近出てきた言葉で、
まだみんなこうどうなんだろうどうなんだろうってわちゃわちゃしてるような感じなのかなって思って、
ちょっと資料を読み進めてました。
このプラットフォームエンジニアリングへの招待を読んだ限りだと、
提供するプラットフォームもそれって実際使う人たちがエンドユーザー?
開発者がエンドユーザーになるので、その人たちの使いやすさをちゃんと追求しましょうねっていうことを書かれていて、
その使いやすさを追求するってことはもうほぼプロダクト開発と同じようなものでしょって伝えてるんだと私は解釈してます。
自分も読んだ感じそういうことかなと思いました。
なのでよくあるかどうかわからないんですけど、
とりあえず新しそうな技術で自分が触ってみたいから入れてみたけど、
実際プロダクトチームであれも使ってくれないとか、
どんどん廃れていく技術とかってやっぱ現場として使ってるとあると思うんですけど、
そういった部分に対するアンチテーゼ的な考え方なのかなっていうのが、
こちらの資料を読んだ時に大枠として私は捉えたイメージでした。
今日この今収録しているのって5月18日なんですけど、
今週の月曜日5月15日にプラットフォームエンジニアリングミートアップの第2回っていうのがあってて、
これは今お話に出てたプラットフォームエンジニアリングへの招待っていうスライドを書かれた、
この草間さんっていう方の主催なのかなのイベントですけど、
そこで発表されてた方々の話を一応自分も動画でオンラインでなんですけど見て、
やっぱあれでしたね、皆さんいかに使ってもらうかのところに苦心されてるイメージでしたね。
そうですね、おっしゃる通りだと思います。
特に私は、私も当日参加できなくて後から動画を拝見させていただいた側なんですけれども、
一番しっくりきたのがメルカリのディートさんの資料、
開発者に使いやすいプラットフォームの提供
プラットフォームエンジニアリングアットメルカリっていう資料を読んでて、
その中で出てきたキーワードとして、
プラットフォームエンジニアリングはプラットフォームエンジニアリングイコールマイグレーションエンジニアリングだっていう
ページが出てきてですね。
マイグレーションかって最初見た時は思ったんですけど、
確かに自分たちのこれまでやってきたことを考えると、
最初に提供したプラットフォームに対して、
より開発者に使ってもらえるようにするであったりとか、
あるいは開発者が使うにあたって認知負荷を下げるために、
確かにどんどん分かりやすいもので言えばパイプラインだってマイグレーションしてってるなって思ったんですよね。
確かにマイグレーションですね。
なんでその時にディートさんのおっしゃってるプラットフォームエンジニアリングイコールマイグレーションエンジニアリングってめちゃめちゃしっくりきて、
博崎さんこの観点で考えた時に過去自分こういうのって実はマイグレーション、
みんなに使ってもらうためにマイグレーションしたケースあったなとかってあります?
それでいくとプラットフォームかというと微妙なんですけど、
例えばいわゆる開発していく上でプロジェクトとかがいろいろあったりとかした時に、
その固有の開発環境とかあったりするじゃないですか。
例えばDockerのDocker Composeとかの環境を整えていくとかですね。
とかデプロイのパイプラインとかを作っていくみたいなところはやっていたんですけど、
そこはそうですねめっちゃ改善は加えていってましたね。
そうですよね。それで多分どんどん使われるようになっていくみたいな流れですもんね。
そこをうまいことインターフェースっていうかをちゃんとやってあげないとあんまり使ってくれないというか、
なんかこうDockerのコマンドとか長いから、
例えば一時期流行ったやつで言うと今も流行ってるのかな、
Makefileとかでできるようにしたりとか簡単にですね、とかっていうのもあったりするんで、
そういうのをやったりとかしてなるべく使ってもらえるように、
使うのが簡単なようにみたいな苦心した覚えはありますね。
なるほど。じゃあ多分それも抗議な意味で言うと、
今で言えばもしかしたらプラットフォームエンジニアリングみたいなところに定義される可能性もありそうですよね。
そうですね。使ってもらうためにはっていうことでしょうしね。
なんとなくこれ読んでて、この言葉を見かけたタイミングでも少し思ってたんですけれども、
言葉の定義自体は割りかし新しいんだけれども、
多分この考え方自体って別に特段新しいものではないのかなって思っていて、
考え方によっては開発者に提供するプラットフォームって開発者が使いやすくあるって当たり前じゃんって考える、
捉える方だっていらっしゃるじゃないですか。
プラットフォームエンジニアリングの復活
そうですね。
それがなんとなく全体的な流れの中でそこに課題を感じ始めた人たちが多くなったから、
こういう感じで名称が定義され始めたのかなと思っていて、
例えば最初だとより開発プロセスを柔軟にしたいからアジャイルやりたいよねっていうのが最初のムーブメントとしてあって、
アジャイルやっていく中でソフトウェアというかテクノロジーなプラクティスとかも取り入れていかないと難しいよね。
多分XPでやったりとかDevOpsの文化入れるっていう流れになり、
DevOpsの文化を入れるってなった時にそれをメンテナンスしていくような人たちってSREとして必要だよね。
SREもしっかり醸成しなきゃねっていう流れになり、
SREまで入れ始めた結果プラットフォームどんどんSREチームとかが出してるんだけれども、
あんま開発者に使われないってダメだよねってそういうことを開発者にしっかり使ってもらえるように考えるって何て言うんだろうってなった時に
プラットフォームエンジニアリングっていうのが出てきたのかなって推測してるんですけど。
そういうことかな多分。
自分が考えてたことがあれだったんですよ。
この最初話に出てきたプラットフォームエンジニアリングへの招待のスライドでも言ってましたけど、
昔から統合基盤とかですね、共通基盤とかって言われるものって結構会社の中にあったりとかしたの、
何回か見たことあるんですよ。
なのでこれはつまりあの螺旋が回ってきたってやつだなと思ったんですよ。
確かになるほど。
で、螺旋だとすると前と何かが違うはずなんですよね多分。
前と何が違うのかなと思ってたのが、多分今三田さんがおっしゃったような流れがあっての戻ってきたところなんでしょうね。
なんかちょっと繋がりましたね。
ちょっと今納得しました。
そういう流れでもう一回戻ってきたんだろうなっていう。
そんな感じがしますよね。
なのでどうなんでしょうね、SREのオライリーのなかなか分厚い本あると思うんですけど、
プラットフォームエンジニアリングの本の可能性
あの中の一章とかに今後入ってくるものなんじゃないかなと思っていて、
ただ一章の中に入ってくるにしても内容のボリュームはありそうだから、
きっとオブザーバビリティエンジニアリングのようにプラットフォームエンジニアリング単独でも本は出そうだなとか思いつつ、
出たらきっと読むんだろうなとも思ってますが。
なんかそうそう、出るとした時にその本の内容がどういうふうになるのかなって思ってて、
なんでかというと皆さんあんまり今このWATSの話をしないんですよね。
社内の話だからなのかもしれないんですけど、
何を作るとかそういうことをあんまり話さずやっぱりいかにして開発者とコミュニケーションを取り、
必要な機能を実装していくかとか、やっぱりそっちの話が多くてですね。
なんでプラットフォームエンジニアリングとは結局人とのコミュニケーションの話なのではないかみたいな気持ちになってますね今自分は。
確かにそこは私も割と同じ考えだとかなと思ってて、
プラットフォームエンジニアリングって言葉自体は非常に新しく出てきた言葉だと思うんですけれども、
その中身ってまさに博多家さんがおっしゃったららせんじゃないんですけど、今まで出てきたものの組み合わせになってくるんだろうなとも思うんですよ。
そのチームトポロジーの考え方であったりとか、
プラットフォームをプロダクトとして考えた場合にどういうふうにそのプロダクトが本当に欲しいものを見極めるのかであったりっていう部分になるんだろうなと思ってて、
ここからは全部予想だから全然実りのない話になっちゃうかもしれないんですけど、
それに近い話として、私カオスエンジニアリングのオライリー本、去年でしたっけ?ちょっといつだったか忘れちゃったんですけど、
プラットフォームエンジニアリングとは人とのコミュニケーションの話
が発売されてその時読んだんですよ。
その中身もやはり具体的なhowじゃなく、本当に概念的な説明が前半の章にあって、
それ以降の章って割とケーススタディというか実際のケースを紹介していることがめちゃめちゃ多かったんですよね。
スラックの場合、スラックインクの場合みたいな。
もしかするとプラットフォームエンジニアリングが出るときもそういう感じで出てきたりするのかなと思ってしまいます。
そっかそっかそっか、そうですよね。
そこで思ったのは、以前我々のゆるテクで2人で話をした、
Kubernetesのエコシステムが育ちすぎてクラスターのポット割合変わっちゃったよって話あったじゃないですか。
これ場合によってはプラットフォームエンジニアリングをして、
分からないですけど、例えば認知負荷をなるべく1箇所に寄せようよとかになったときに、
どんどんそこに集まっていったりしないのかなって思っちゃいました。
認知負荷がですか?
認知負荷は少なめにしたいから全部クラスターに入れちゃえば、
1箇所じゃんみたいなことになって、
よりアプリケーションのワークロードとそれ以外のワークロードのポット割合が変わっていくっていうのが加速するのかな、
どうなんだろうなって思いながら。
するんじゃないですか。
とかとか。
思想だけど、
多分そこを上手いこと、アプリケーション以外のワークロードを使ってる側、開発者に意識させないみたいなことも必要になるでしょうね。
そういう気がするけどな。
確かにそうですね。
そこの認知負荷をやっぱり削減したいでしょうからね。
開発者はただアプリを動かしたいだけなので。
それ以外のポットとのリソースの割合がとか、
あんまりそういうのは考えたくないはず。
確かにこういう言葉が出て改めて考えて、
この視点で自分たちのプロダクトを見直すと、結構認知負荷は高いんだなとは思いましたね。
だってたしか水谷さんのところは、やむらかがないですもんね。
そうですね。
開発者が。
確かにな。あれはもうまんまプラットフォームの中身を書いてデプロイしてるから。
そう。こういうことなんだろうなみたいなことになりますよね。
そういうことですよね。そこを上手いこと、
GUIとかCLIとかでコマンド一発で書き込んでデプロイみたいな風に抽象化していくんでしょうね。
Wattの話をすると。
そうですね。そこの抽象化も、ベストプラクティスみたいなものってあんまりないんじゃないかなと思ってて、
どれくらいまで抽象度を上げておけば自分たちは使いやすいですって、きっとチームによりけりというか、
まさにプロダクトみたいなもんじゃないですか。
めっちゃめっちゃよりそう。
うちのチームは別にそこは自分たち全然わかるし、やることも不可じゃないからそこまでラッピングしなくてもいいんですってチームもあれば、
もう全然わかんないから、ここぐらいまでラッピングしてあとはブラックボックス動かしてくれよってなるところもありそうだし。
うんうん。わかる。
心もやり込もうと思えばやり込めるけど、やりすぎることがいいことかっていうと、現地点ではどうなのかなって考えちゃいますね。
そうっすよね。どこら辺まで理解してもらうかっていう。難しいですよねこの辺の。
そうなんですよね。
規模にもよるしな。
ただ一つ、それのなんでしょうね、ハウになりそうな部分としてはたまたまこのタイミングでなのか、このタイミングでっていうのもあれですけど、
今って生成AI系がなかなか勢いがついてるところがあるから、間違いなくハウの一つの選択肢には入ってきそうだなってところがありますよね。
なんてことだ、まさかあれで書いたらそう通りになる?
みたいなとか。
インターフェースが自然言語になりますか。
とかとかに突き詰めるとそういうことをやるとことが出てくるのかなって思っちゃいますよね。
はあ、すごいなあ。
自分はあんまりまだイメージできないですけどね、自然言語で。
結構全部のインターフェースが自然言語になるみたいな話ってたまに最近聞いたりしますけど、
自分は結構細かい調整とかをしたい派なので、
こんな感じで後はよろしくみたいな感じでうまく本当にいくのかなってすごい疑問です。
自然言語インターフェースとプラットフォームエンジニアリング
疑問というか、なるのかなって、会議的。
わかります。あとはどうなんでしょうね、それが実現するプロダクトにも寄り切りな感じしません?
どういうこと?
例えば、物によってはそういうことをやるのがオーバーエンジニアリングになっちゃうプロダクトもあるでしょうし、
逆に細かくチューニングしないとうまく回せないようなプロダクトの特性だってあるのかなと思ってて、
選択肢ぐらいにはなるんだろうなと思うんですけどね。
そうですね。
ただそうなった時に私も全然イメージついてないんですけど、
自然言語でできるようになった先で、そこでできてくるものを最終的に判断するのって現時点だとまだ人だと思うんですよね。
そうですね。
その判断する人がそれだけのものを判断できる力をつける方法って、
我々で言えばこれまでそういうのを自分で書いてきたから、勉強してきたから勝手に身についているところってあると思うんですけど、
それがスタート地点の人からすると、どういう流れでそういう判断力というか、
身につけていくんだろうな、どうやって育成していくんだろうなっていう別のところで興味が湧いてきますね。
クラウドが出始めの時に、物理インフラを触ったことない人間は結局運用できないって言われてた、同じ匂いを感じますね。
同じ匂いを感じてて、仮に書籍とかで自分で学習をしたとして、そこからきっとそれを使って何か手を動かして、
ちょっと古いかもしれないですけど、手を作らないとなかなか身にはならなさそうだなとか思いつつ。
結局、さっき言ったような話とかも一部当たってて、ネットワークの知識とかもある程度ないと、
クラウドで抽象化されていてもやっぱりトラブルシューティングとかできないですからね。
ですよね。
だからやっぱり生成系のAIとかで上手いことAIが全部やってくれるようになっても、
やっぱり判断は、自分ができることを肩代わりしてもらうって言おうとにしかできない気がしますよね。
うん、ですよね。生成系で言えばプロンプトエンジニアリングでなるべく的確な指示を出すというか、
プロンプトを入れて出てきたものがあったとしても、そこの判断ってってなりますもんね。
なりますね。
っていう感じで結構わからないことだらけというか、これってどうするものなんだろうなって疑問に思うことがいっぱいあるんですけど。
これあれですか、話変わっちゃうんですけど。
はい。
三沢さんはさっきほら、三沢さんのところだとあんまりプラットフォームプラットフォームしてない感じの運用になってるじゃないですかインフラが。
そうですね。
抽象化していく予定はあるんですか?そのプラットフォームっぽく。
今のとこだとあまりないはない、ちょっと表現が違うな。私たちの目から見るとあまりないんじゃないかなとは思っていますが、
プラットフォームエンジニアリングの言葉の中で出てくるプラットフォームアズプロダクトだよねっていうところで考えれば、
おそらくそこの要は現場のエンジニアの市場調査じゃないですが、ユーザーヒアリングすらまともにできていないかなとも思うので、
それをやった結果問題が見つかってくるのであればやる可能性はあると思っています。
じゃあ一旦その話聞いてみようぐらいはとりあえずやることとしてもう上がってはいるんですかね。
上がってますね。
なるほどなるほど。
それがよくわかんないくなるのはそこってSREだけがやるものなのかなとかはいろいろはてななんですけど、
でもなんとなくSREがやりそうなものだなとも思ってて。
そうですね。
っていう感じですね。
結構まだこうなんとなく方向性はわかってきたけど、うーんって感じです。
これもガートのハイプサイクルでいうとまだかなり最初の方ですよね。
一番最初のまだ過度な期待のところに入ってもいないところですよね。
ですねこのイノベーショントリガー的なところですか。
そうですね最初のところだ。
厳密機まで行くのかな。
マイクロサービス今これ見てて思ったんですけどマイクロサービスが今厳密機なんですね。
本当だ。
DevSecOpsとかもうこの一番最後のフェーズに入っている普及機器。
そんな進んでない。
本当に。
濃くなるとよくわかんないですよね。
そうですね。
GitOpsとマイクロフロントエンド
だって逆に言うとGitOpsとかまだ全然最初ですよ。
プラットフォームエンジニアリングより進んでない。
でもGitOpsって思うんですけど、
ちょっとこれ考え方違ってたら申し訳ないんですけど、
あれじゃないですかね。
でもKubernetesでやってなきゃGitOpsってなかなかやらなくないって思ってて。
確かに。
かつこれは私の不勉強というか経験不足なのかなと思ってるんですけど、
GitOpsをやるときのインフラ刷新がめちゃめちゃ大変だなと思ってるんですよ。
確かに。
シングルソースオブトゥルースなのでマニフェストを変えました。
じゃあ既存のやつもGitOpsされちゃいますだとめちゃめちゃ問題じゃないですか。
かといってしばらくブランチ2つにしましょうとかってことをやってしまうと、
シングルソースオブトゥルースどこいったみたいな話にも。
確かに。
個人的にはなってて、
じゃあそれってGitOpsをやる場合ってどういうソリューションというか、
方向性でやるべきなんだろうって思っちゃうんですよね。
確かに最初始めるとき、いわゆる今まで何も管理されてなかったインフラをIAC化するとき以上に大変そうですね。
メンバーとかSREの人と話してるときは、
じゃあ一時的に片方のGitOps止めちゃえばいいんじゃないかなとかって話をしたりもしたんですけど、
じゃあその間ってでもリリースできなくないみたいな話もしつつ、
確かにそうじゃん。
だから全然自分の中でも答えが見つかってないんですよね。
Kubernetesの普及とそういったGitOpsを使った場合の、
その他諸々のプロダクト運用のプラクティスというかパターンが出てこない以上、
なかなか難しいんじゃないかなって思っちゃいます。
個人的な予想ですけど。
でも確かにDevSecOpsはもう普及期、
確かにDevSecOpsっていう文字をよくツイッターとか、
あと勉強会とかの商品の紹介で見るようになった気がします。
そうですね、でも早かった。
これあれか、色で年が分かれてる。
2年未満ですよ、まだDevSecOps。
ものすごい勢いで、じゃあ。
セキュリティの観点ってみんな関心が高いってことなんですかね。
逆にこのLCAPってやつ、自分は初めて聞きましたね。
LCAPって何だ?
何でしょうね、調べておこう。
ローコードアプリケーションプラットフォーム。
それ全般の言葉ですか。
っぽいですね。
それなら確かにもうみんなやってるな。
この辺もあれですかね、逆にローコードのプラットフォームの中に
生成AIとか組み込まれたらより品質というか精度が上がっていくような感じなんですかね。
そういうことなんですかね。
全然ローコード界隈は調べたことがないというか、
あまり関心を持ってやったことがないので、適当なこと言ってますけど。
ナイスですね。
RPAとかも多分そこに入ってくるんでしょうけど。
ハイプサイクルのこれ、あまりまじまじ見たことなかったから面白いな。
確かにね。こうやって見ると、マイクロフロントエンドもまだあれなんですね。
イノベーショントリガーのところですね。
あれもカオスエンジニアリングもギリまだそこですね。
カオスエンジニアリングって本番とかでやる勇気があるところってそんな出てくるかなって思いますよね。
でもあれじゃないですかね。自分もちゃんと知らないからあれだけど、
本番でやらないと意味がないやつじゃないですかね。
ですね。
リリースの問題とプロダクト運用のパターン
それでいうとカオスエンジニアリングができる前に
オブザバビリティとかその他しっかり回復できるような仕組みを入れてないことには始められない感はありますよね。
そうですね。ただの障害が起きるだけですね。
壊したら戻らなくなっちゃいます。死体になりますもんね。
怖すぎる。
オブザバビリティがもう頂点を下ろうとしている。
そうですね。
げんめつきに入るな。
本当だ。
確かにまじまじとこれを見たことがなかったんで結構発見はありますね。
ちゃんとこれ見るようにしてみようかな。
キーワードとか拾えると面白そうですよね。
プラットフォームエンジニアリングからだいぶ横道に取りつつ
あまりプラットフォームの話ができなかった。
それだけ2人もそんなに経験もないし不運ぐらいの空気感なんだろうなって伝わってくるというか
ガッツリやってないですからね。まだね。
やってないしガッツリやる需要がある環境にできるかどうかもありますからね。
人数がめっちゃ多いところほど需要は多いでしょうからね。
うん、ですです。
はい、まあじゃあそんな感じで
多分これ以上我々もプラットフォームエンジニアリングを掘り下げられそうにもない気がするので
ない気がする。
今日はぼちぼちお開きにしましょうかね。
はい。
ではTwitterではハッシュタグユルテクをつけてツイートお願いします。
Googleフォームからもアンケートコメント等を送れますのでよろしくお願いします。
お願いします。
今日はありがとうございました。
ありがとうございました。
