自動車相乗りサービスを提供するスタートアップ企業のLyftは，自社のインフラストラクチャ設定管理ツールをPuppetからSaltStackに変更した。同社のエンジニアであるRyan Lane氏の記事によると，この他にAnsibleも選択肢にあったということだ。最終的には各ツールの使いやすさ，完成度，パフォーマンス，製品を取り巻くコミュニティなどを検討した結果，SaltStackが選ばれることになった。
使いやすさという点では，そのドキュメントの構成や充実度によって，SaltStackは良好な学習曲線を持っている。Ryanの評価では，Ansibleのドキュメントはシンプルで初心者向きではあるが，コードが大規模になった場合にはSaltStackの方が優位だという。設定ファイル(Ansibleではプレイブック，SaltStackではステート定義)を詳しく調べると，いくつかの違いが浮かび上がってくる。Lyftのエンジニアたちは入力，出力，設定の面で，SaltStackの方が一貫性があると考えた。例えばAnsibleが異なったファイル形式(INIファイル，YAML)を使用するのに対して，SaltStackはすべてYAMLで統一されている。ループや条件処理の実行方法も異なり，このロジックをDSLに組み込んでいるAnsibleに対して，SaltStackではPythonテンプレートエンジンであるJinjaを使用する。Ryanと同僚たちは，SaltStackのアプローチの方が好ましいと考えた。さらには，SaltStackの”素晴らしい"イントロスペクション機能も，決定要素のひとつになった。
完成度の面ではAnsibleもSaltStackも十分で，Lyftのユースケースに必要な機能はすべて備えていた。しかしRyanは，SaltStackの方がより機能が豊富だと考えている。さまざまな形式と位置に出力できること，さまざまなソースから取得したエッセンスデータの構造であるピラーをロード可能であること，さらにエージェントとして動作した場合には，リアクタシステムを経由してローカルイベントを発行可能であること，などがその理由だ。
Lyftのユースケースというコンテキストでパフォーマンスを考えた場合，SalStackは特に無変更時の実行速度が速い。
Salt:
- 全変更時: 12分30秒
- 無変更時: 15秒
Ansible:
- 全変更時: 16分
- 無変更時: 2分
この結果から，RyanはAnsibleのイシューを１件オープンした。同じシナリオでもSaltStackの方がはるかに速い，という理由からだが，現在そのイシューはクローズされている。Hacker Newsでは，Ansibleを開発したMichael DeHaan氏が，Ansibleのパフォーマンスチューニング方法の記事を紹介している。ただしその内容は，ユーザ関連の操作の遅さに関するRyanの不満に対処するものではない。
ツールのコミュニティに関しては，SaltStackの方がフレンドリで，その数も多いと判断された。ただしRyanが"Ansibleはmpdehaan(DeHaan氏のGitHubでのハンドル名)がほとんどひとりで書いた"としているのに対して，DeHaan氏は，Ansibleには"現時点で810名のコントリビュータがいる"と反論している。Lyftのエンジニアたちも，SaltStackのコミュニティの方がフレンドリで頼りがいがあり，機能リクエストにも前向きだという意見だった。SaltStackはAnsibleよりも積極的に変更を導入しているが，その一方で"コードの受け入れに関しては厳格さに欠ける場合がある(もっとコードレビューを行うべきだ)"。Michael DaHaan氏がHacker Newsで，"同意できない場合はノーと言います"と明言しているように，これはプロジェクト管理の哲学に関する問題だろう。"これは重要なことだと思います。フィルタリングとテストは，プロジェクトのレベルを決定するものだからです。"
ツールを変更した最大の理由は，コード行数で約10,000という，Lyftの複雑なPuppetコードベースにある。Lyftでは"ビルドして実行"的なアプローチを採用しているため，DevOpsチームとしては，Puppetコードベースは開発者向きではないという考えだ。結局，SaltStackもAnsibleも，1000行程度のコードでPuppetインフラストラクチャを再現することは可能だった。Puppetコードをスクラッチから書き直す可能性にについて問われたとき，Ryanは次のように返答している。
スクラッチから書き直せば，おそらくライン数は大幅に少なくなるでしょう。実行速度も改善されるかも知れません(...)。そうは言っても，Puppetを書き直すのは，あまりにも時間が掛かり過ぎると思います。
Lyftには新ツールに対して，いくつか重要な要件を持っていた。ひとつはマスタ不要のアーキテクチャが可能なことだ。マスタは"不要な障害発生点を増やす上，パフォーマンスを損なう"というのがその理由だ。また，コードは最適化によって変更されることなく，記述順に読み込まれる必要がある。コードは構成管理上の抽象化のあまりない，シンプルなものでなければならない。 横断的な設定(監視など)や，サービス/アプリケーション特有の設定を，別々のリポジトリに格納可能なデザインをサポートすることも必要だ。
InfoQでは以前にも，インフラストラクチャ構成管理ツールを取り上げた連載記事の中で，SaltStackとAnsibleを紹介している。この分野の主なプレーヤについて，それぞれ実際のユーザによる仮想討論会も行った。Ryanが指摘している各ツールの長所が，この仮想討論会においても注目されている点が興味深い。