转载

互联网级企业的变革

在过去十年中，Google投入了大量的开发资源来创建支持大规模运维操作的系统。开发的复杂应用来应对规模巨大的流量和数据容量，导致我们在应用架构和总体的操作模型上采用了新的方式。

各大厂商开始称这种方式为‘本地云计算’，这里有3个核心特性，使得我们可以从传统系统中对其进行识别：

容器打包。作为应用部署的密封单位，运行于容器中，使得部署变得更具可预测性。对于我们管理的规模，使用传统的命令或脚本进行部署是不现实的。系统的自由度会随着规模成倍增加，这在互联网级别的规模下就会变得不切实际。
动态管理。在实践中，对于运维人员而言，每周调度和管理超过20亿的容器是不可能的。相反，我们使用依赖容器提供的高层视角的智能系统，来进行关于作业运行数量以及运行地点的决策。这彻底地提高了效率，并使得程序员能够专注于代码编写。此外，这也使得我们可以组建小型、专一、高度自治的运维团队，它们只需要着眼于提供通用服务。
面向微服务。我们所有的系统都基于松耦合架构，依赖通过服务端显式描述。这使我们的提供更加敏捷，并显著增加了代码复用。我们无需为子系统创建新的通用服务实例。

在Google之外，这套方法也戏称为‘GIFEE’——Google Infrastructure for Everyone Else。有趣的是，它也被称之为‘FIFEE’或‘TIFEE’——Facebook和Twitter都在计算中采用了类似的方法，来应对运维规模的扩展。具体的细节千变万化，但是基本的模式是一致的。这是典型的技术协同变革。迄今为止，只有一个实践方法来应对互联网级别的规模，就是每个互联网公司创建他们的共同基础模式的演绎。

看向未来，我们会发现更多的传统企业被迫处理互联网级规模的问题。IoT正在将规模空前的流量带向商业。一个具有更高相关性的移动性的用户基础和劳动力，需要互联网级别的解决方案来提供支撑。每家企业都将不得不应对这些挑战，这些都是难以避免的。对于一个社区而言，组建健壮的技术栈来支持这些公司，是很有意义的。

容器的下一阶段：标准化

截至最近，我们已经看到一些独立工作于特定技术的科技公司，支持转向本地云计算。个人主义方法的问题在于它要求每个供应商递交一个‘全栈’。没有标准化的容器运行时、工作流、通用服务以及数量众多的其余部分，组成一个本地云工具栈，每个公司都是一座孤岛，只有一小部公司会试着去做全套的解决方案。

我们深信，每个人都能够从能力专精中安全获益。如果一家初创公司对如何改善容器运行时环境有较好的想法，他们应该会继续前行，并创建一个独特的环境，而无需纠缠于自己的可重发布的镜像格式。如果另一家初创公司对于如何调度，以解决一个特定的工作负载问题，有较好的想法，他们应该会创建并出售，而无需创建整个栈。

带着这些，我们考量下Kubernetes的未来，容器工作流技术由Google中的同一团队完成，该团队也创建了Google内部的工作流和调度系统(如Borg)。将它贡献给社区是很有意义的，和更加广泛的社区合作，共同创建一系列协作‘栈’来支撑面向每个人的本地云计算。这就是为何我们会接触Linux组织，以及更加宽泛的技术伙伴(Intel，Red Hat， Cisco， IBM，VMWare，Docker，CoreOs，Mesosphere等)并创建本地云计算组织(CNCF)的原因

标准化的一条新途径

CNCF的目标不是创建一个传统的标准化组织(如，定义标准，然后实现规范)，而是创造一个场所，使得我们可以在供应商自制管理下集成相关的技术，然后协调这些技术，并给予已有的用户群技术，改进工具栈层级之间的标准接口。

我们的目标是创建一个拥有清晰接口(APIs)的架构，随后依赖于参考实现作为不同部分的语义标准。如果有意义，供应商可以自行扩展栈的任意一部分，然后通过一份品质测试套件来完成该部分的‘认证’，以示其能够和参考实现兼容。基于API的一致性是不充分的，对于用户群体而言，语义上的一致性才是根本，因为如此才能够使其分拆工具站，或是集成自己的演化版本。

带着这些，我们罗列了如下几条组织的核心价值：

快总比慢来的好。我们必须确保项目高速发展，以促进用户的积极采用。
开放。组织必须是开放的，易加入的，并且独立于特定团体意志而管理的。它必须根据贡献度接受所有来者，并且根据开源评估，它的技术必须是对全体可用的。
公平。我们必须营造一个公平竞争的环境，允许正在推动创新的小公司和知名公司拥有相同的级别参加。
一致性。无论是形式上，哲学上抑或是方法上，技术都应该尽可能保持一致性。
高度技术同一性。组织需要维持高度的自治性，并在项目间保证高度的技术同一性。
清晰的边界。组织的目标必须是清晰的，在某些情况下，组织的非目标边界会更加重要，它有效地允许项目共存，并帮助生态理解应该为创新聚焦于何处。

一种新颖的管理模型

为了使之行之有效，我们需要跳出思维局限，根据组织结构进行思考。当我们在羡慕那些已经被许多现存组织完成的工作时，我觉得这里依旧有许多关键目标尚未被完成。我们决定尝试在组织内尝试一些新的想法，而不是建立传统的业务管理委员会：

保持有力技术见解。我们的壮志是给市场带来突破性的新技术，并帮助世界转向更好的运维方式。为了实现这个目标，我们需要一个高度自治的组成，使其免受任何供应商意志的束缚。出于这些考虑，我们建立了技术监督委员会——一个选举出来的团队，由9个人组成，他们会为团队推进技术视角，接洽子项目，并处理技术上的分歧。这些成员从业界选出，依据是在各自领域内的贡献时间以及在社区内的回答，和特定供应商的意志无关。
对最终用户负有责任。关于组织受供应商驱动，不对最终用户负有强烈的责任心，此类现象，我们已经看到的太多太多。为了制止此事，我们正在积极招募组建一个自制的最终用户委员会。该委员会将会代表最终用户对于技术监督委员会的意志(就如同业务委员会代表供应商的意志一样)。

我们的理想是，通过提出这些检验与权衡条款，创建一个稳定、专注的社区，促进创新，并在法律上使世界走向本地云计算技术。

如何参与其中

对于最终用户的责任，要求广大企业社区的参与，这些企业正在从传统架构向本地云计算架构迁移。

通过参与CNCF的开源项目，有很多机会加入CNCF。为了加入Kubernetes社区，可以考虑参加 Slack频道，关注GitHub上的 Kubernetes项目，或是加入Google Kubernetes-dev群组。不仅仅是Kubernetes，技术监督委员会将会带来更多项目，往后参与CNCF的机会将会更多。

另外，CNCF需要多元观点，才能帮助指导我们的活动。作为最终用户成员加入CNCF ，将会确保大家听到你的诉求。

原文 http://dockone.io/article/1015

正文到此结束