※ 商品リンクから購入されると少額の報酬が発生することがあります。
Pulumiが勢いづいてきている、という話を見かけました。
Pulumiが、TerraformやAWS CDKと並べて語られるインフラの構成管理ツールであることは分かっています。 今回気になったのは、使い方そのものより、TerraformやCDKとどういう思想の違いがあるのか、なぜ今勢いがついているのか、という点でした。
この記事はPulumiの紹介ではありません。 Pulumiをきっかけにして、私がこういう技術をキャッチアップするときに、どういう観点で見ていくのかを書いておきます。
今回Pulumiについて確認していたことを並べると、大きく4つありました。
まず大きく特徴を把握すること
Pulumi / Terraform / AWS CDK は同じ文脈で並べられますが、宣言の持ち方や適用のされ方は同じではありません。HCLで書くものと、プログラミング言語で書けるものが並んでいる時点で、まずその違いを大きく把握するところから始まります。
その特徴や既存のものとの差異から、課題になりそうな点を見ていくこと
HCLとプログラミング言語による記述の差異を見ると、HCLで書いていたときに難しい目に遭うresourceの識別は、むしろ複雑になりそうにも見えます。そこで、resourceを何で識別しているのか、renameや構成変更をどう扱うのかを確認していきました。その確認の中で、aliasesのような仕組みがさらなる課題として出てきます。気になる箇所を、もう少し深掘りしていく流れです。
その課題が認識されていて、実際にどう解決しようとしているのかを見ること
私の課題感は合っているのか、その課題は実際に認識されているのか、認識された上でどのような議論や対処が行われようとしているのかを見ていきます。Terraform依存があると知った時点で、そのままでいるのは筋が悪く、おそらく何か対処が行われようとしているだろうと考えて確認していきました。
なぜ勢いがついてきたのか、その要因と現在の状況を見ること
技術的な構造だけでは、なぜ今その名前をよく見るのかは分かりません。ライセンス変更、買収、コミュニティの反応など、成り立ちの経緯や今後の動向はかなり重要です。OpenTofuやPulumiが今どういう立ち位置にあるのかも、ここで確認していきました。
従来の調査と、生成AIで変わったこと
今までは、READMEを読んで、ソースコードを追って、IssueやDiscussionを見て、ブログや発表資料を探すなど、ネットの海を彷徨っていました。
今現在は、生成AIとのやりとりでかなりの速度で情報を集められます。もちろん、教えてもらった情報がそのまま真実と信じてはいけないのですが。キャッチアップしておく段階では直感がおかしいと言わなければそのままにしてしまっています。技術選定の時点では状況などが変わっていることも多々あるはずですし。
今回の確認メモ
以下は、生成AIとのやりとりを短くまとめたものと、その途中で考えたことです。
1. Terraform / CDK とPulumiの大きな違いを把握
質問
Terraform買収の話＋PulumiはTerraform/CDKと比べてどうか（思想・実用度）
回答要約
Terraformは宣言DSL、CDKは宣言生成、Pulumiは命令的コードで、柔軟性と実績のトレードオフがある
2. resource identity と aliases が気になった
質問
命令的かけるとより悪化しそうなTerraformモジュール問題（state不一致→再作成）をPulumiはどう扱うか
回答要約
Terraformは構造がIDだが、Pulumiは名前をIDにするためリファクタリング耐性が高い
質問
Pulumiのaliasesは負債化しないか（スパゲッティ化の懸念）
回答要約
aliasesは一時的移行手段であり、削除前提で運用しないと確かに負債化する
私の思考: terraformに依存していることを知り、今までの経験からある程度勢いがついたタイミングでバックエンドも自前で管理始めるだろうという考えが浮かび、その様子がないか気になる
3. Terraform 依存と Provider の実体を確認した
質問
PulumiのTerraform依存は筋が悪いのでは／自前化の兆しはあるか
回答要約
Provider依存は残るが、ネイティブProviderとSaaS基盤で依存を薄める方向にある
私の思考: terraformに依存していることを知り、今までの経験からある程度勢いがついたタイミングでバックエンドも自前で管理始めるだろうという考えが浮かび、その様子がないか気になる
質問
PulumiはHCLを生成しているのか／Providerを直接使っているのか
回答要約
HCLは使わずTerraform Coreも使わず、Providerだけを直接利用している
私の思考: terraformに依存しているといってもHCLを生成して乗っかるなどでなくterraformがHCLを元に動作するプロバイダを利用しているということを知ります
質問
TerraformのAWS/GCP Providerは誰が作っているのか／仕様依存か
回答要約
ProviderはHashiCorpやクラウドベンダーがTerraformのPlugin仕様に従って実装している
私の思考: terraformのプロバイダは操作対象のクラウドなどの業者が開発している印象だったので、念のため確認するとawsのプロバイダはHashicorpが作っているとのこと
質問
AWS ProviderがHashiCorp製であることへの違和感（将来性の懸念）
回答要約
クラウド制御レイヤーが外部に依存する構造であり、長期的なねじれリスクがある
私の思考: これはterraformと競合していく中で何かしらの課題になりそうだと感じ何か動きがあるか確認したところ、やはり独自実装が行われている（AWSのAPIを直接叩く何かがありそう）とのこと。aws以外はおよそ各社が作っているらしいので、状況により良い感じに変わっていきそうだなとは思った
4. 将来性とコミュニティの動きを確認した
IBMのHashiCorp買収合意に関して、技術キャッチアップとは関係ないと判断したらしく、私のIBMによる買収だという事実誤認を正しただけだったことがありました。 ただ、コミュニティがどう見ているか、実際に人がどう動いているかは、技術選定では無視できないと思っています。
質問
IBMによるHashiCorp買収合意は、TerraformからPulumiへの流れと関係があるのか
回答要約
直接の原因ではないが、中立性や将来性への不安を増幅し、移行判断を後押しする要因にはなる
質問
コミュニティで実際にどのような声が上がっているか（技術選定観点として）
回答要約
ライセンス変更への反発とフォーク発生、買収への将来不安、Provider構造への違和感、Pulumiは代替候補として言及されている
質問
HashiCorpのライセンス変更はいつか、IBM買収と関係があるか
回答要約
2023年8月にBSLへ変更、2024年4月に買収合意で、順序は逆。公式に因果関係は示されていない
質問
BSLの特徴とPulumiのAWSネイティブプロバイダとの関係
回答要約
BSLは利用制限付きソース公開ライセンスで、Pulumiの独自Providerとは直接無関係だが、依存回避という文脈では関連づけられる
質問
OpenTofuとTerraformのシェア推移、Pulumiはどうか
回答要約
Terraformは依然として最大シェアだが揺らぎはあり、OpenTofuは移行候補として増え、Pulumiは小規模ながら新規採用で伸びている
まとめ
概要把握から、思想や成り立ちの経緯、解決しようとしている課題は何か、対象自体に想定される課題が一致しているかということから自分の理解の正当性を確認しつつその課題の解決方針を見て、現在位置を確認しておく。こんなことをしているのだと思います。生成AIによってキャッチアップの速度が劇上がりで嬉しいです。
ウォッチしているトップエンジニアたちの多くは、もうコードは手で書いていない、と言っていて関心ごとや利用ツールなどは変化の兆しです。
一方でよくない使われ方も増えており、3月の中旬から怒涛の様相を見せていて戦々恐々ともしていますが、世界の変わるタイミングは非常に興味深いですね。