【中云网 译文】Puppet软件是模型驱动型，Ruby编程软件（Chef是其中的一种）是程序驱动型。二者都庞大无比、杂乱无章，是被众多陷阱所困的开源生态系统。
在过去几年中，围绕办公室的游戏计划总是十分简单。CEO们强调“要快”，CTO会说“云”，最后所有人点头答应“当然”。
所有美好的事物都走到了尽头。单词“云”曾让企业员工感到十分积极愉快，因为它承诺能帮我们分担太多的琐事。只要应用了魔法般的云，用云的魔杖轻敲网页，就能把所有问题的药方全部分配下去，问题也就随之消散。
唉，每个人都慢慢发现，云本身就面临着大堆的麻烦。旧的问题解决了，随之而来的是新的问题。困难就是我们现在需要管理着成打的、数以百计的、甚至是数以千计的机器设备。云让我们很轻松地部署了这些机器，但现在我们需要管理这些设备。这就像古老的格言描述小猫和流浪狗那般：喂养它们一次，（然后不得不）照顾它们一生。
在这种情况下，部署成打的、数以百计的、甚至数以千计的设备时获得的愉悦，意味着很快又有了成打的、数以百计的、甚至数以千计的补丁需要我们安装；有成打的、数以百计的、甚至数以千计的安全漏洞需要我们修补；有成打的、数以百计的、甚至数以千计的更新版本需要我们下载。当我们只有几台设备的时候，这种程度的保养维护只需要花费数分钟。但假如把这数分钟乘以几打、乘以几百，甚至乘以几千，我们得到的是以天、周和月来衡量的琐碎事情。
感谢老天爷，让我们可以自动化完成。过去那么多年，智能系统管理员看着激增的任务列表，找到了一种撰写脚本的方法，解决这些重复的任务。他们建立了他们自身的低级机器程序管理员来为他们做这些工作。
二者都是开源代码架，设计用于让用户方便地访问并打开存储在用户庞大的虚拟设备王国忠的文件。二者都拥有开源的市场，方便用户交换插件，扩展组织架构，管理特殊版本的硬件或软件。二者都非常酷，并且都在全球的数据中心的羊肠小道上找到了最合适的路径。二者现在都拥有公司围绕开源的核心卖点援助。
Puppet vs. Chef 一览
模型VS程序
有区别吗？不是那些特别抽象的感觉上的区别。他们都推送说明，帮助配置或改装用户的设备组合。当然“改装”总体来说，意味着安装收藏或其他文件的新版本。
但世界充满着派系党争。无论什么时候，每当我们靠近一个统一的谐波收敛，人类就会分裂为不同的竞争群体。人们总能找到某种方式，然后分裂。
在这种情况下，斗争是通过语言来进行的。Chef软件由Ruby编程和Erlang编写而成，用户可以在纯Ruby编程下编写特殊版本或延展版本，纯Ruby版本是全语言和显然不纯的语言，有时也被戏称为“特定于域”的语言的一个子集，该子集仅向用户提供足够的内容以满足用户需求。
Puppet，另一方面，则拥有非常独有的语言。它将所有的安装需求打包，用波形括号捆绑在一起。有点类似JSON，但通过有条件的运营商和面向对象的类架构增加了乐趣。如果用户不喜欢这样，Puppet自2.6版本之后，也可以允许用户使用Ruby编写特殊版本。
花费太多时间担心语言问题很可能并非好主意--真正的区别还在更深层的地方。Puppet代码是Puppet说明的依赖项列表，你可能会说，“在B之前安装A”，并且你在代码的任何地方都这么说。Puppet会找到你列出的内容，并确保A会第一个添加。
Chef，另一方面，更加透明。用户最好确保安装B过程之前，先安装B，因为Chef遵循给定的说明。
到底对用户来说，那种更好呢？很幸运地，有人撰写了长篇的评论文章讨论他们的观点。其中有一篇是文章作者本人喜欢的史蒂夫·特劳戈特（Steve Traugott）和兰斯·特朗（Lance Brown）合写的“为什么命令很重要：在自动化系统管理下的平衡转型”。Chef爱好者喜欢所有这些依赖项转向一个疯狂的数量，并且不会导致连贯在一起。Andrew Clay Shaefer在他的博客上辩论到，绝大多数的时间里，我们没那么聪明到用Puppet做正确的事情，并使用Puppet做好事而不会困扰--除非当他没那么干的时候。我仍然不能下定决心。