私は、Chef/Puppet/etc のようなツールについて初めて学んでおり、クラウド上にデプロイされたアプリケーションとの統合がどの程度 (または不十分か) なのか疑問に思っていました。
前もって感謝します！
開示：私はPuppetLabsに雇用されている開発者の1人です。
ベンダー固有のAPIや、それらのAPIを抽象化するJCloudのようなフレームワークがあるのに、なぜChefを使用するのでしょうか。
2つの理由があります。1つは、Chef、Puppet、および同様のツールがJCloudに似ていることです。これらは、特定のクラウドAPIを抽象化したものです。したがって、同じ理由でそれらを使用します。
もう1つは、ほとんどのクラウドAPIは実際にはマシンの作成に関するものであり、Chef、Puppet、および同様のツールは実際にはマシンの作成後の構成に関するものです。クラウドAPIを介した抽象化は、コアフォーカスよりも便利です。
これらの構成ツールを使用することでパフォーマンスコストが発生しますか、それともノード/マシンはクラウド上の他の（管理されていない）マシンと同じように動作しますか？
knifeマシンの作成に使用するのにパフォーマンスコストはありますか？いいえ、他の非管理対象ノードとまったく同じです。Chefがインストールされていないマシンを作成すると、Chefがインストールされていないマシンと同じようになります。パペット側なども同様です。
（Chef、Puppet、および同様のツールには、パブリッククラウドAPIに存在しないAPIはありません。そこでは恋人との取引はありません。;）
Chefを使用して、そこにあるテクノロジーを構成できますか、それとも「サポートされているベンダー/システム」のリストを提供しますか？つまり、Chefで構成されたPostgreSQLサーバーがたくさんあるとしましょう。そして翌日、クレイジーな新しいRDBMSが出てきたので、それに切り替えたいと思います。Chefがこの新しいシステムを「サポート」するのを待つ必要がありますか、それともChefベンダーに依存しませんか？
ChefとPuppetは、どちらもその中心に拡張性があります。どちらにも、箱から出してすぐに管理できる一連の機能と、他の多くのもののサポートに貢献するコミュニティがあります。
したがって、派手な新しいサービスが登場した場合、どちらかで管理できる機能のすべてではありませんが、いくつかを持っている可能性があります。（たとえば、パッケージ、ファイル、サービスを管理し、箱から出して任意のコマンドを実行します。これにより、管理のためのより詳細なモデルがなくても、ランダムな新しいサービスに必要な多くのことが実行されます。）
さらに管理したい場合、たとえば、データベース内のアクセス制御はモデルのファーストクラスの部分である場合、誰かが製品にサポートを書き込むのを待たなければならない場合があります。（その誰かが、明らかにあなたになることができます。:)
したがって、基本的なサポートをすぐに利用でき、それらの上にさらに構築するのは意図的に簡単です。
どちらの製品も、意味のある意味で「ベンダー固有」ではありませんが、どちらも他のプラットフォームよりもUnixで効果的であり、Windowsのサポートは制限されていますが、それでも価値があります。
ここにあるほとんどすべては、宇宙の他の製品にも当てはまります。