たぶんだけど、アプリ側の人は開発工程の自動ビルド、自動テスト、自動デプロイなどの経験から柔軟なしくみを好むみたい。
一方、インフラ側の人は堅牢性を好むみたい。
同じジョブスケジューラでも、アプリ側が使いたいミドルウェアは業務で使っているプログラム開発言語がそのままUIになってたりAPIで制御できる柔軟性の高いツールを使いたいみたい。一方、インフラ側が使いたいミドルウェアは柔軟性よりも大規模でミッションクリティカルなシステムに導入して比較的シンプルなジョブを着実に実行して、仮にジョブがアボートしたりエラーになってもそのステータスが確実に観測されて定義どおりに処理されたり保留される実直さ、複雑なジョブネットワークでも可視性がよく、障害時のハンドリングがしやすく、ロギングやマルチベンダーでスケールされている大規模システムでも各ノード上のジョブが整然と実行してくれる実績があって堅牢なツール（電車のダイヤ運航システムのようなツール）を使いたいみたい。多少融通が利かなくても。
同じバックアップでも、ノード数やコンポーネント数が少ない場合は、気の利いたジョブを実行したり柔軟にカスタマイズさせたりして創意工夫次第でシステムの価値を飛躍的に向上できる場合がある。一方、ノード数やコンポーネント数が膨大なシステムの場合、ただ数が多いという事実が解決すべき問題となる。煩雑でミスを誘発するよりシンプルで確実なジョブを一斉に着実に実行してくれる信頼性の方が好まれるみたい。
