Pulumi vs Terraform vs CDK for Terraform vs Serverless + Terraform
Pulumi
TypeScript/Python/Go等によるコンフィグ
セールスポイント
プログラミング言語によりより柔軟なテンプレーティング、繰り返し処理など
Serverlessアーキテクチャ等Dynamicなインフラとの相性のよさを強調
Terraformのwrapperのような使い方
tf2pulumiでterraformリソースをpulumiに変換しようとしてみたが例外を吐いたためうまく出来なかった
引数なしでコマンド叩いてもversionが表示されなかったりちょっと心配になった
公式ツールの割りにはstacktraceだけ出して明示的なエラーもなしに終了したり全体的な使用感に不安が残る
DevOpsツールはOperationに関わる領域のためとにかく例外を吐いて終了する場合にもその原因と思わしきものの出力は出してほしいがこういった周辺ツールでもうまく動かないというのは本体も同様なんじゃないかという評価になってしまう
本体のissue処理状況は800 Open / 2300 Close
悪くはないが決して良くもない状況か
ちょうどプロジェクト成長期で負債に悩んでいる時期はこのようなOpen/Close比になることが多い
対してTerraformは1200 Open / 15000 Close
巨大プロジェクトとしてはかなり良好で十分Matureと言ってよい
1:10以上を確保出来ているのは負債をコントロール下に置いてロードマップも定まっており安定した一つの壁を抜けた状態
CDK for Terraform
Cloud Development Kit AWSのTerraform Provider
ポジション的にはPulumi Alternative的なところか
2021-02-01現在まだ0.1でProduction Readyではないのでこれからに期待か
素のCDKがCloudFormationテンプレートに変換するのに対してcdktfはterraform定義をJSON形式で出力する
CloudFormationに比べTerraformリソースとして出力されるので適用が早い
ただWrapperのWrapperといった感じで抽象度が高くなってきているため出力されるTerraformに理解がないとハマったときちょっときつそうだなとは思った
こちらもTypeScript/Python/Go等に対応
2021-01-15 0.1リリースされたがまだalphaのためProductioinにはまだ早いか
触った感じPulumiよりはmatureなように感じた
VSCodeのエディタサポートで良好なレスポンスと補完が効いた
ただ命令的な書き方になり宣言的な言語であるHCLの利点とは別になるためアプリ開発者をターゲットにしたソリューションか
結局内部的にはTerraformのコンフィグをJSONで吐いてTerraformを叩いているだけではあるので命令的言語を宣言的言語にトランスパイルしているだけといえばだけなので最初から宣言的に書けるならその方がいいのではという気もする
命令的な書き方になるのでリソースを書く順番に影響されたりモジュール間の依存等をランタイムに依存してしまう
つまりNode.jsのランタイムが更新されると以前有効だった書き方が無効になるといったことも考えられる
宣言的言語の良さはdeclartiveになることで副作用を抑えた射像が得られることなので
良くも悪くもチューリング完全になっているので繰り返し等は定義しやすいがモジュール間の依存の定義等やりずらさはある
エディタのサポートでジャンプとかはしやすいが明示的にnewしたり、また書く順によっても参照出来ないというような場合あもある
逆にTerraformのような宣言的言語では表現出来ない順序関係言語上のフローで表現されているのでその言語の習熟度によってメンタルモデルに差が出来そう
もちろん逆に依存関係をコードを上から読まないと分からないというのは宣言的でないのでインフラの全体像を掴むためにコードを読まないといけないというのがインフラ的な観点からはあまり体験は良くない
宣言的であるということはどこから読んでも得られるメンタルモデルに差がないということなのでTerraformのように部分的に読むということをしづらい
モジュール化どうするか問題
書き方は自由なのでオペレーションに差が出てしまうのもあまりよくない気はする
最終的に得られるTerraform jsonの差分で判断するしかないが
そういったところでcdktfがトランパイルレイヤーとしてちゃんとTerraformに追従していけるか、バグなくコンパイル出来るか、といったところがキーとなる
Terraform
デファクトではあるがサーバレスアーキテクチャ等の広がりにより、動的でアプリ寄りのアーキテクチャに関して制御しづらい箇所など出てきた
サーバレスFunctionの実装等コードベースを管理しづらい
とはいえド安定ではあるのでPulumiやCDK for Terraformの動き次第ではmigratitonしていくのもありか
Serverless
サーバレスアーキテクチャ用のフレームワーク
serverless.ymlに従ってCloudFormationテンプレートが生成されて適用される
ただこれのみでAWSリソース全体を作るのは難しいのでTerraformで共有される静的なインフラ(Route53, VPC, RDS等)を管理し、Serverlessでアプリケーションspecificなリソース(Lambda, IAM, Dynamo)を組み合わせるという方法もある
抽象度はかなり高くカスタムのリソースが必用な場合は resoucesにCloudFormationのテンプレートを渡す必用がある
serverless.yaml -> CloudFormation Template -> applyという流れになり元のserverless.ymlから最終的な成果物を想像しづらいところはある
アプリに集中するならありかもしれないがインフラのメンタルモデルが想像しづらくちょっと厳しいところはある
まずCloudFormationのテンプレート自体がかなり冗長で再利用性が薄いyamlとなっているため(要は宣言的でないので冗長になる)
LambdaとAPI Gatewayくらいに用途を限定するのなら悪くはないかも
それ以外のリソースも管理し始めると割りと沼
CloudFormation故に適用が遅いのがけっこうきつい
S3アップロード→CloudFormation適用→待ちとなるためちょっとした変更もそこそこ待つ
Serverless.ymlもあまり出来がいい感じはしない…
全てのコンフィグが集中し設定が肥大化すると行数が多くきつい
WebのDashboardもあるがそこへの誘導が違和感
Pulumiも同様だけど初期化時にアカウントを作ることを推奨されてよく分からず作るとWeb Dashboardにプロジェクトが追加される
課金モデルへ誘導したいのは分かるががっつきすぎというかそこはOptionalであることを明示してほしかった
Conclusion
2021-01-23現時点ではCDK for Terraformを評価しつつTerraform + 部分的にServerless等組み合わせるくらいがサーバレスアーキテクチャも使用した方法かな