結論
1 つのプロジェクトで利用したのみ + 現時点では開発していない状況ではあるのですが、いくつか感じたことがあったので、メモとしても残しておこうと思います。
以下のようなプロジェクトの特性であれば、おすすめできるかと思いました。
- 長期間利用されることを想定しているプロジェクト（R&D や PoC には向かない）
- Terraform を使ったことがあるメンバーが既にいる
- 最初期に掛かる学習コストが許容できる
下記のデメリットにも記載した通り、Lambda 関数のローカル実行ができないため、サーバレスアプリケーションを開発する際の開発体験としては非常に厳しいと言わざるを得ないかと思います。
ただ、serverless framework と組み合わせて使っているという記事があり、この記事中に記載されているような使い方をすることで、ある程度デメリットは回避できるのではないかと思います。（ただ、インフラコード自体は複雑になってしまうため、学習コストは上がると思われます）
それ以外の大きなメリットとして、コード上に書かれていないものが生成されるということがないので、コードとデプロイ先の環境に作成されたリソースに（おそらく）差分がないことだと思います。
AWS CDK や Serverless framework などは抽象化されている分、学習コストが低く簡単に使えるのですが、コードで書かれていないリソースが作成されることが多々あるため、クラウド上にどのように作成されたか分からないリソースがあった場合に確認しようがないということが起きます。
長く運用しているプロジェクトほど、謎のリソースあるけど消してもいいんだっけ？みたいに悩まされるケースに直面することが多いと思います。（テスト用のリソースを作成したままで放置されていたり、マネジメントコンソールからリソースを作成する際に、把握していないリソースが作成されていることに気づかないなど）
こういうことが避けれるのは良い点だと思いました。
それ以外にも感じたメリットやデメリットは以下の通りです。
メリット
- インフラ環境の構築にアプリケーションと同じ言語を使って開発できる
- 補完が便利（また、型定義ファイル内に Terraform の公式へのリンクがあるので、調べるまでの導線が非常にスムーズ）
- テストが書ける
- 抽象化されている部分が少ないので、コード上に書かれていないリソースがクラウド上に存在することがない。（リソース管理の観点で非常にメリットがあると考えている）
- CloudFormation をラッピングしているものに比べるとデプロイ時の変更の速度が早い。（ちゃんと計測して比較したわけではないですが、体感として）
デメリット
- Terraform を全く知らないと、学習コストが高い
- AWS CDK や Serverless framework 等では抽象化されていて意識しなくても良いところも把握していないと環境を構築できない。
- Lambda 関数を必要とする場合、Lambda 関数のビルド等を自前で実装する必要がある。（ただし、サンプルコードとなるものはあるので、コピペでできる）
- ローカル環境での開発が非常に不便（serverless framework や AWS SAM のようにローカル実行の仕組みがない）
コメント