很长一段时间以来,我一直想写这篇文章,但有一件事阻碍了我。对我来说,提供一个准确的历史、定义和正确使用Pets vs Cattle迷因是很重要的,这样每个人都可以理解为什么它是成功的,以及它作为推动理解云的工具的重要性。这个迷因之所以流行,是因为它有助于人们理解“旧方式”与“新方式”的做事方式。这很好,但当误用时,模因的价值就变得模糊了。我们都同意,已经有足够的术语和措辞含糊不清,例如“云”、“混合”和“DevOps”。因此,这篇文章旨在澄清事实,并确保每个人都可以参考和使用规范的历史。

历史

2011年或2012年的某个时候,我很难向客户解释AWS、云原生应用程序和更广泛的云与以前有什么根本的不同[1]。大多数解释都需要过多的时间。当我看到比尔·贝克关于扩展SQL Server。比尔并没有到处乱跑,在云端圈子里展示这件事。我通过谷歌搜索找到了它。比尔并不是在谈论云或云计算。他的重点是“扩展”与“扩展”架构的总体对比。

最重要的是,比尔用了一个让我产生深刻共鸣的比喻。他在比较宠物和牛群的背景下谈到了放大与缩小。我头顶上的一盏灯亮了起来,我意识到这就是我要找的电梯广告。但我关注的是一个细微但重要的细微差别。首先,我把宠物和牛放在云的背景下,其次,我强调了牛的可处置性和宠物的独特性。这比你是扩大规模还是缩小规模更重要。我认为,这些都是您查看服务器时的副作用。如果您将服务器(无论是金属服务器、虚拟服务器还是集装箱服务器)视为可以随时销毁和更换的固有对象,那么它就是群中的一员。然而,如果您认为一个服务器(或一对试图作为单个单元出现的服务器)是不可或缺的,那么它就是一只宠物。

以下是我将在演讲中逐字逐句地进行的电梯推介:

在旧的处理方式中,我们将服务器视为宠物,例如邮件服务器Bob。如果鲍勃倒下了,所有人都在甲板上。首席执行官收不到电子邮件,这是世界末日。以新的方式,服务器被编号,就像牛群中的牛一样。例如,www001到www100。当一台服务器出现故障时,会将其取出,拍摄,并在线路上更换。

这个宠物vs牛的解释是什么与欧洲核子研究中心的蒂姆·贝尔共鸣和其他许多人一样,他们复制并传播了这个类比,这创造了一个迷因,它启发了这么多人,清晰地代表了我们所有人向云的过渡。

了解宠物和牛

让我们花点时间来明确定义宠物和牛。

宠物

服务器或服务器对被视为永不停机的不可或缺或唯一系统。通常,它们是手动构建、管理和“手动馈送”的。示例包括大型机、孤立服务器、HA负载平衡器/防火墙(主动/主动或主动/被动)、设计为主/从(主动/被动的)的数据库系统,等等。

由两个以上的服务器组成的阵列,这些服务器是使用自动化工具构建的,是为故障而设计的,其中没有一个、两个甚至三个服务器是不可替代的。通常,在故障事件期间,不需要人工干预,因为阵列通过重新启动故障服务器或通过三重复制或擦除编码等策略复制数据,显示出“故障路由”的属性。示例包括web服务器阵列、多主机数据存储(如Cassandra集群)、集群中的多个机架,以及几乎所有负载平衡和多主机的数据存储。

这里的关键是,在旧世界,通过两种方式实现冗余是不够的,即企业数据中心中普遍存在的HA对。所需要的是假设故障能够并且将会发生。每个服务器、每个组件都能够在不影响系统的情况下发生故障。

最重要的是,如上所述,这种类比有助于教育一代IT经理、首席信息官和其他人,同时为他们提供了进一步解释新旧对比的工具。

离开牧场

这就是为什么坚持或至少从上面的核心信息开始是很重要的。人们可以也会接受这个简单的类比,并将其用于自己的用途。人们增加了类比(例如“宠物、牛和蚂蚁”、“儿童、宠物和牛”等),并以各种方式对其进行了修改。这很好,但它经常会使水变得浑浊,这意味着它会降低价值。这里有一个最近的例子可以说明这一点。

Kubernetes团队借用了这个类比来解释他们今年夏天在Kubernete功能中添加了“宠物套装”,并发布了一个名为容器中的状态应用程序!?Kubernetes 1.3表示“是的!”可以理解的是,容器生态系统中的人们会把宠物比作牛,并将其解释为关于有状态应用程序的某种含义。有状态应用程序的容器适用性存在一定的不安全性。有些事情我个人并不理解,因为容器一直都适用于有状态应用程序,但对持久存储的容器生态系统支持可能还不太理想。尽管有不少人一直在寻求解决这个问题,包括Rex-Ray项目然而,这是一个较长的讨论。

k8s博客帖子的核心问题是,如果您查看Kubernetes 1.3中使用Pet Sets支持的有状态应用程序的示例,它是以下内容的规范列表-架构数据存储系统:“Cassandra、Kafka和MongoDB”。所有这些数据存储系统都是为失败而设计的,完全符合我对上述养牛应用程序的定义。换句话说,Kubernetes现在使用所谓的“宠物集”支持牛数据存储。

当然,问题在于,这意味着真正的宠物架构系统,例如主动/被动Oracle存储系统或一对NFS文件服务器,都支持使用宠物集。虽然这里有一些步骤有助于实现这一目标(例如支持有序设置主/从系统),但宠物集实际上是针对扩展数据存储,而不是上文定义的真正宠物。

这很重要。如果我们说宠物是关于需要“特殊处理”的系统而不是“不能失败”的系统,那么我们最终会混淆试图理解新方法与旧方法的人们。

从宠物和牛中获取价值

嘿,做你需要做的事。如果你觉得你需要把宠物和牛做比较,然后为了营销或其他目的而弯曲它,那当然是你的特权[2]。只需了解它最初是如何使用的,以及为什么它在快速帮助it人员和执行官快速了解发生了什么变化方面仍然非常重要。如果你能简单地承认你提供了自己的新背景,并指出这篇关于模因真实历史的博客帖子,我也会非常感激。

归根结底,关注服务器的可处置性(事实上,这是谷歌首创的概念)是宠物与牛的较量中最重要的一个方面,而这一点正在失去,关注其他方面,或将无意中的东西(例如,作为宠物的有状态应用程序)归咎于其他方面,都会分散注意力并搅乱局面。

通过理解并准确地表示模因的起源,我们保持了它的价值,帮助那些新的颠覆者理解计算交付方式的根本转变。

云开了。


[1] 云连接2011主题演讲
[2] 事实上,我已经开始在牧场主的困境:协调宠物和牛