Joe DuffyのPulumi、$41M Series CでIaCをCloud Engineeringへ広げた転換

Joe Duffyは「Our ambitious mission is to democratize the cloud so that every builder, no matter their background, can make the most out of the cloud」とPulumiの使命を語った。出典

冒頭：cloudをコードで扱う

Pulumiは、infrastructureを専用DSLだけでなく、開発者がすでに使うprogramming languageで書く道を選んだ。

現在はopen-source engineとPulumi Cloudを組み合わせ、cloudの構築だけでなくstate、policy、deployment、visibilityまで扱う。出典

創業：IaCを開発者の習慣へ

2017年にJoe Duffyが始めたPulumiの出発点は、cloudがソフトウェアの競争力になる一方で、infrastructureが開発者から遠いという問題だった。

複数言語、IDEの補完、packageの再利用をIaCに持ち込むことで、開発と運用の境界を縮めようとした。出典

転機：open sourceからCloudへ

Pulumiはengineをopen sourceとして開きながら、teamが必要とするstate管理やvisibilityをCloudにまとめた。

2020年のSeries Bは$37.5Mで、Cloud Engineeringを市場へ広げる資金になった。出典

成長：IaCの外側まで扱う

2023年のSeries Cでは$41Mを調達し、2,000 customers、150,000 end users、100 employeesという節目を公表した。出典

Terraform/HCLの資産を移行対象として受け入れ、さらにPulumi AIやNeoでagentic infrastructureへ進む。

競合を全否定せず、既存資産の上に次のworkflowを置く転換である。出典

結び：抽象化の入口を広くする

Pulumiの歩みは、infraを特別な職人技から、開発者が扱えるsoftware workflowへ近づける試みだった。

今後の焦点はAI agentが生成する変更を、Pulumi Cloudのpolicyとreviewでどこまで安全に運用できるかにある。

PulumiのPMFは、cloudを使う開発者とplatform teamが、YAMLやBashの断片ではなく、既知のprogramming languageでinfrastructureをレビュー・再利用したい痛みにある。

公式docsは複数言語とcloudを同じIaCモデルで扱える点を説明している。出典

Open-source engineとPulumi Cloudを分けたことで、導入の入口は広く、state管理・policy・visibilityはチーム向けに拡張できる。

この分離が個人開発者からenterpriseまでの連続性を作ると考えられる。出典

技術的moatは、language SDK、provider ecosystem、state・policy・deploymentの実装を一つのworkflowに積み上げること。

open-sourceで利用者が試せる一方、Cloudの運用データと組織導入が商用側の継続理由になる。出典

ネットワーク効果は中程度。

provider、package、componentの共有が増えるほど導入価値は上がるが、単独チームでも完結するため、SNSのような強い相互依存ではない。

open-source communityと2,000 customersの蓄積が弱い正の循環を作る。出典

主対象は、複数cloud・Kubernetes・serverlessを扱うplatform team、開発者がinfrastructureにも触れる組織、IaCを標準化したいenterpriseだ。

個人開発者やOSS maintainerはfree tierから始められる。出典

逆に、単純な単一サーバー運用や、teamでコードを共有しない短期検証だけなら、Pulumi Cloudの管理機能まで導入する必要は薄い。

第一はlanguage-nativeなIaC。

既存のIDE、型、package、testをcloud定義に持ち込める。

第二はopen sourceとCloudの二層構造で、信頼と商用の運用価値を両立した。出典

第三はTerraform/HCLを正面から否定せず、既存stateを取り込む移行導線を作ったことだ。

競合の置換ではなく、移行コストを下げる提案に変えた。出典

最大のリスクは、language-nativeな自由度がteam内の標準化負債にもなり得ることだ。

複数言語・provider・state backendの組み合わせが増えるほど、platform teamにはpolicyとreviewの設計が必要になる。出典

また、公式には2,000 customersなどの利用指標はあるが、revenueやARRは開示されていない。

AI agent機能も40%超のusersがAI agentsでinfrastructureを管理するという公式発表の範囲で、長期の安全性・費用対効果は要確認である。出典

成長はopen-sourceのdeveloper adoptionを入口に、Pulumi Cloudのstate管理・policy・deployment・AIへ拡張するland-and-expand型だ。

公式は2023年時点で150,000 end usersと2,000 customersを公表している。出典

Terraform/OpenTofu state対応は既存市場を奪うより、移行の摩擦を吸収する戦略である。

一方、AI agent時代にはguardrailsを売る必要があり、速度と安全性のトレードオフが残る。出典

主要チャネル: openSource, developerCommunity, contentMarketing, cloudMarketplace, sales, conference

開発者向けinfraでは、既存の開発習慣に寄り添う抽象化が採用の入口になる。

Pulumiは「新しいDSLを覚える」ではなく、既知のlanguage・IDE・packageをそのまま使う方向へ設計した。出典

同時に、OSSだけで終わらず、state・policy・deploymentの運用面をCloudとして束ねる。

無料の入口と有料の複雑性解消を分離する考え方は、開発者プロダクト全般に応用できる。

日本では、複数cloudやsecurity reviewを抱える大企業のplatform team向けに、Pulumiのlanguage-nativeなIaCとpolicy as codeを導入支援込みで届ける余地がある。

既存Terraform資産を捨てずに始められる点は、移行を慎重に進める企業と相性がよい。出典

ただし、日本語docs・国内cloud運用慣行・SIerとの協業が採用の壁になる可能性がある。

まずはAWS/GCP/Azureの標準テンプレートと監査向けの運用例を揃えるのが現実的だと考える。