どうも、ローカルスタックおじさんです。
Dockerでコンテナを作る。
Kubernetesでオーケストレーションする。
これがマイクロサービスの醍醐味なんだ。
そしてヘテロジーニアスクラスタをHA構成。
くぅ〜、たまらねぇ。
……と思っていた時期がありました。
気づけば、Agentを作っていたはずなのに、local stackを育てていました。
Qdrant。
Redis。
Postgres。
FastAPI。
worker。
scheduler。
Ollama。
vLLM。
Docker Compose。
起動するものが増える。
.env が増える。
volume が増える。
port conflict が増える。
containerのご機嫌取りが始まる。
うお、Agentどこいった。
ローカルで全部持てることが強い、と思っていた
昔の常識では、全部持てることが強さでした。
自分で構成を理解する。
Dockerで固める。
Kubernetesで回す。
冗長化する。
ログを見る。
監視する。
壊れたら直す。
それがちゃんとしたエンジニアリングだと思っていました。
もちろん、今でもこれは間違っていません。
本番運用するサービス。
インフラ要件が厳しいシステム。
データを外に出せない環境。
チームで運用する基盤。
そういう場所では、今でもローカルや自前基盤の理解は強いです。
ただ、個人開発やPoC、Agent/RAGの実験で同じ重さを持ち込むと、話が少し変わります。
ちゃんと作っていたはずなのに、いつの間にか本体ではなく周辺が育つ。
Agentを作りたい。
でも、その前にQdrantを立てる。
Redisもいる。
Postgresもいる。
workerもいる。
schedulerもいる。
embedding modelも考える。
ローカルLLMも試したい。
GPUも見る。
volumeも見る。
ログも見る。
そして、Docker Composeが育つ。
ど典型です。
クラウドSaaSに「昔の常識を今の常識だと思うなよ、おじさんw」と言われる
クラウドSaaSに寄せ始めたとき、少し負けた感じがありました。
昔の自分なら、たぶんこう思っていました。
いや、そこは自分で持つでしょ。
そこをブラックボックスにしていいの？
運用を外に逃がすのは甘えでは？
ローカルで再現できないと不安では？
でも、クラウドSaaS側からこう言われている気がしました。
昔の常識を今の常識だと思うなよ、おじさんw
つらい。
いや、わかってる。
わかってるけど、Dockerで固めてKubernetesで回すの、気持ちいいんだよ。
containerが並ぶ。
serviceが分かれる。
networkができる。
volumeがある。
ログが流れる。
healthcheckが通る。
くぅ〜、たまらねぇ。
でも、気持ちよさと運用しやすさは別でした。
気づいたら視点までmicroになっていた
マイクロサービスは、責務を分ける考え方としては好きです。
大きな塊を分ける。
責務を明確にする。
境界を作る。
壊れた場所を見えるようにする。
これは今でもかなり好きです。
ただ、AgentやRAGを作っているときに、最初からスタックを細かく持ちすぎると、視点までmicroになります。
次はRedisを見る。
次はPostgresを見る。
次はQdrantを見る。
次はworkerを見る。
次は起動順を見る。
次は.envを見る。
次はportを見る。
見るものが増える。
でも、本当に見たかったのはそこだったのか。
Agentのstateはどう遷移するのか。
retrievalの結果はevidenceになっているのか。
どこで止めるのか。
どこで外部APIに逃がすのか。
どこまでをRuntimeが持つのか。
どこから先をユーザーに返すのか。
本当はそっちを見たかった。
なのに、視点がcontainerまでmicroになる。
うお、責務分離していたはずなのに、責務が増殖している。
ローカルスタックは楽しい。でも楽しいものが本体とは限らない
ローカルスタックは楽しいです。
自分の手元で全部動く。
壊れたら見に行ける。
ログも取れる。
ネットワークも分かる。
データも手元にある。
この安心感はあります。
でも、楽しいものが本体とは限りません。
Agentを作っているはずなのに、local stackを育てている。
RAGを作っているはずなのに、Vector DBの運用を育てている。
Runtimeを作っているはずなのに、containerのご機嫌取りをしている。
これ、普通に起きます。
しかも厄介なのは、やっていること自体は技術的に気持ちいいことです。
だから進んでいる気がする。
Docker Composeが伸びる。
serviceが増える。
READMEに起動手順が増える。
構成図が立派になる。
でも、Agent本体は始まっていない。
local stackだけ育って、本体が始まらない。
クラウドSaaSに寄せたら、見る場所が減った
クラウドSaaSに寄せると、考えることが減りました。
もちろん、全部が消えるわけではありません。
API制限はある。
課金もある。
vendor lock-inもある。
障害時にできることは限られる。
データの置き場所も考える必要がある。
でも、少なくとも個人開発やPoCの段階では、かなりの摩擦が減ります。
DBを育てなくていい。
embedding基盤を育てなくていい。
ローカルLLMのVRAMを見続けなくていい。
起動順に祈らなくていい。
port conflictで止まらなくていい。
volumeの中身を見て虚無にならなくていい。
そのぶん、Agent Runtimeの設計に戻れる。
stateをどう持つか。
evidenceをどう扱うか。
output boundaryをどこに置くか。
failure modeをどう分けるか。
何をRuntimeが判断し、何をユーザーに渡すか。
ようやく、見たかった場所に戻れました。
インフラを捨てたのではなく、インフラを見る時間を捨てた
クラウドSaaSに寄せたのは、技術を捨てたかったからではありません。
インフラを理解しなくていい、という話でもありません。
むしろ、何を外に逃がしているのかを理解していないと、クラウドSaaSはただのブラックボックスになります。
だから、理解は必要です。
でも、理解していることと、毎回自分で面倒を見ることは別です。
必要だったのは、全部を持つことではありませんでした。
今の自分が見るべき責務を選ぶことでした。
インフラを捨てたのではなく、インフラを見る時間を捨てた。
正確には、インフラを見る時間を、Agent Runtimeを見る時間へ移した。
クラウドSaaSに寄せたのは敗北ではなく、見たい責務を取り戻すためでした。
昔の常識を、今の作り方にそのまま持ち込まない
昔の常識では、全部持てることが強さでした。
でも、今の個人開発やAI開発では、全部持つことが初速を落とすこともあります。
ローカルで動くこと。
自分で構成できること。
全部見えること。
それらは今でも価値があります。
ただ、それを毎回の初手にすると、作りたいものに戻れなくなることがある。
必要だったのは、最強のローカルスタックではありませんでした。
Agent設計に戻れる環境でした。
ローカルスタックおじさん、クラウドSaaSに敗北しました
Docker。
Kubernetes。
マイクロサービス。
ヘテロジーニアスクラスタ。
HA構成。
Qdrant。
Redis。
Postgres。
Ollama。
vLLM。
Docker Compose。
対戦ありがとうございました。
ローカルスタックおじさん、クラウドSaaSに敗北しました。
でもたぶんこれは、悪い敗北ではありません。
Agentを作っていたはずなのに、local stackを育てていた。
そこから、ようやくAgent Runtimeに戻れる環境へ移っただけです。
自分が持つべきものは何か。
外に逃がしていいものは何か。
今見るべき責務はどこか。
クラウドSaaSに粉砕玉砕大喝采されながら、ようやくそこに戻ってきました。