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

Pulumiは、TypeScriptやPythonなどのprogramming languageでcloud infrastructureを定義するIaC platformだ。

open-source engineとPulumi Cloudを組み合わせ、state管理・policy・deploymentまで扱う。出典

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の標準テンプレートと監査向けの運用例を揃えるのが現実的だと考える。