1同じ設定が何度もコピーされる
チャットの場合
各リソースが同じ名前とオプションを繰り返します。値を一つ変えると、ファイル全体を探すことになります。
NebulaStackの場合
共有設定（タグ、バックアップ、ネットワーク）は一度書いて再利用します。同じ行を12箇所直す必要はありません。
緑のplanでは足りない
AIはplanが通るTerraformを書けます。チームはそのファイルと付き合わなければなりません。
チャットは正しそうに見える数千行を貼りがちです。NebulaStackは依頼内容を覚え、高い選択は確認してもらい、毎回同じ規則でファイルを書きます。
まったく違う二つの結果
チャットがすること
インフラを頼むと、ファイルの壁が返ってきます。直す対象はその壁です。緑のplanは文章が妥当なことだけを意味し、リージョンを変えても壊れないことではありません。
NebulaStackがすること
インフラを頼むと、その依頼を保存します。サイズとネットワークを確認し、依頼からファイルを書きます。残すのは生成コードの貼り付けではなく、依頼そのものです。
3つの手順
1
欲しいものを説明する
台数、ネットワーク、データベースを、チャットかフォームで伝えます。自分でTerraformを書く必要はありません。
2
足りないものを確認する
マシンサイズ、リージョン、OS、ネットワークを言っていなければ、こちらから聞きます。請求を膨らませる設定を黙って選びません。
3
ファイルを書く。確認する。
同じ規則はいつも同じファイルになります。後から変えるときは依頼を変えて、こちらが書き直します。
5つの問題、2つの答え
同じプロジェクトでもplanは通るのに運用は無理、ということがよくあります。よく壊れる点と、こちらが代わりにやることです。
2数値がコードに埋め込まれる
チャットの場合
リージョン、マシンサイズ、メモリ、ポートがすべて固定です。リージョン変更は多箇所の編集になり、一つ忘れます。
NebulaStackの場合
フォームで設定します。未指定なら、埋める前に確認します。
3全部が一つの山になる
チャットの場合
ネットワーク、サーバ、データベース、DNSが一つのファイルの山です。読み返しも再利用も難しいです。
NebulaStackの場合
ネットワーク、データベース、マシンは別ファイルです。依頼を変えて書き直し、手でコードを直しません。
4全部がappという名前
チャットの場合
5つのサービスがすべてappというリソースになります。午前2時のログは役に立ちません。
NebulaStackの場合
名前は入力から来ます。例: nebulastack_rds_db1。クラウドコンソールでも一意で読めます。
5高い問いに安い答えが付く
チャットの場合
データベースの待機、バックアップ期間、暗号化が簡単な設定のままです。アシスタントはその選択があることすら言いません。
NebulaStackの場合
Productionではデータベースの待機、長いバックアップ、削除保護、暗号化されたstateを有効にします。適用の前に検査します。
隠さないこと
魔法ではありません。実チームで使うなら、次の3点が重要です。
まだフォームに無いものがある
フォームにまだ無いリソースは、アシスタントが手書きのTerraformを出せます。ファイルが妥当かだけを確認します。ネットワーク、マシン、データベースはフォームを使ってください。
ファイルをコピーして手で直さない
適用できるプロジェクトを出します。正本はNebulaStackです。変わったら再生成してください。ファイルをコピーして手で直すと、また貼り付けの保守に戻ります。
高い選択の一部はこちらで決める
Productionはコストが上がってもデータベースの待機を付けます。サイズ、ネットワーク、OS、リージョンは確認してもらいます。信頼性のすべてのトレードオフではまだ止まりません。