云原生应用接口

标准接口（或第十三个因素）

在有学问的公司里说我们需要“软件标准”时，你会得到一些有趣的眼神。大多数人承认软件标准对于那些最胆大、最成功的项目（比如互联网）的成功至关重要。大多数人也怀疑它们如何适用于我们今天所处的创新世界。我们的项目是以周为增量执行的，而不是以年为单位。在这个瞬息万变、竞争激烈的世界里，受制于大型软件公司主导的标准实践将是致命的打击。

这不是关于“那些”标准。不是那些经过多年深入考量和谈判，最终由某个四字母缩写名称的机构发布的标准。这是一种不同的方法：发现现实世界中行之有效的东西，并作为一个社区来采纳它。

让我们回到基本原则。如果用一个词来描述云原生，我们会选择“可自动化”。

大多数现有应用并非如此。 

应用与其环境之间存在许多接口，无论是与管理基础设施、共享服务还是其他应用。为了让操作员摆脱补丁、扩展、将应用从一个环境迁移到另一个环境、更换依赖关系以及处理故障条件的任务，一套结构良好、通用的接口至关重要。不言而喻，这些接口必须是为机器设计的，而不仅仅是为人。机器友好的接口使自动化系统能够理解受管系统，并创建应用在自动化环境中生存所需的松散耦合。 

随着容器化基础设施的建设，应用可用的关键接口集远远超出了当前单个节点所能提供的范围。采用“无服务器模式”（即短暂的、事件驱动的函数执行）将进一步增强理解在与节点完全解耦的环境中运行代码的需求。所需的服务将从应用配置开始，扩展到监控、日志记录、自动伸缩等。随着应用不断适应成为“云原生”世界中更完整的公民，能力集只会不断增长。

进一步探讨一个例子，许多服务发现解决方案已经被开发出来，但它们通常与特定的存储实现、特定的编程语言、非标准协议绑定，或者在其他方面有自己的主张（例如，规定应用命名结构）。这使得它们不适合通用用途。虽然 DNS 有其局限性（最终需要解决），但它至少是一个标准协议，并且其实现有创新的空间。CoreDNS 和其他云原生 DNS 实现就证明了这一点。 

当我们审视 Google 内部的系统时，得益于高度同质的软硬件环境，我们在没有正式接口定义的情况下实现了非常高的自动化水平。相邻系统可以安全地对接口做出假设，通过提供一套普遍使用的库，我们可以规避这个问题。一个很好的例子是我们的日志格式不需要正式指定，因为生成日志的库由维护日志处理系统的团队维护。这意味着到目前为止，我们能够在没有类似 fluentd（它在社区中解决了与日志系统对接的问题）的情况下运行。

尽管 Google 以这种方式运行良好，但这也会给我们带来困扰。一种情况是我们收购一家公司时。将他们的技术移植到我们的自动化系统中需要巨大的工作量。在做这项工作的同时继续创新尤其困难。然而更重要的是，开源世界中正在发生许多创新，我们不容易从中受益。当新技术出现时，我们希望能够对其进行实验，零散地采纳它，或许还能回馈贡献。当你运行一个垂直整合的、定制化的技术栈时，这很难做到。

标准接口的缺失给客户留下了三种选择： 

• 承担高昂的运营成本（现状），并接受在许多情况下，你的开发者将花费大部分时间处理应用的维护和管理。
• 选择像 Google 一样（从地板上的水泥到一切都自己构建）。 
• 依赖单一或少量供应商提供完整的解决方案并接受一定程度的锁定。无论是大型企业还是初创公司，很少有人觉得这有吸引力。我们认为开放社区更强大，并且当技术栈的每一层都存在竞争时，客户会受益。应该能够组合一个在各个层面都具有最佳能力的技术栈——日志、监控、编排、容器运行时环境、块存储和文件系统存储、SDN 技术等。 

管理系统与应用之间接口的标准化（至少通过约定）至关重要。可以将使用通用的接口约定视为创建在云端和大规模场景下良好运行的现代系统的第十三个因素（对 12 要素方法的扩展）。

Kubernetes 和云原生计算基金会 (CNCF) 是一个极好的机会，可以支持标准接口的出现，并支持一个完全自动化的软件世界的到来。我们非常乐意看到这个社区拥抱从现有技术中推广标准接口的理念。显而易见的第一个步骤是确定当前的关键接口集，并在 CNCF 中成立工作组，开始评估该领域中哪些可以作为候选，并赞助相关工作，以开始开发可跨容器格式、编排器、开发者工具以及实现云原生愿景所需的无数其他系统工作的标准接口。

• ←上一篇
• 下一篇→