这篇文章已经发布一年以上。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已变得不正确。
云原生应用程序接口
标准接口（或者说，第十三要素）
当你在博学的公司里说我们需要“软件标准”时，你会得到一些有趣的眼神。大多数人承认软件标准对于最伟大和最成功的项目（如互联网）的成功至关重要。但大多数人也对它们如何应用于我们今天所处的创新世界持怀疑态度。我们的项目以周为单位执行，而不是以年为单位。在这个流动且竞争激烈的世界中，陷入大型软件公司驱动的标准实践将会是致命的。
这与“那些”标准无关。那些经过多年的深入考虑和协商后才出现的标准，最终由一个以四个字母缩写命名的机构发布。这是一种不同的方法：找到在现实世界中有效的方法，并作为一个社区来拥抱它。
让我们回到第一原则。要用一个词来描述云原生，我们会选择“可自动化”。
大多数现有应用程序都不是。
应用程序与其环境有许多接口，无论是与管理基础设施、共享服务还是其他应用程序。为了让运维人员不再需要修补、扩展、将应用程序从一个环境迁移到另一个环境、更换依赖项以及处理故障情况，一套结构良好的通用接口至关重要。不用说，这些接口必须为机器而设计，而不仅仅是为人类。机器友好的接口允许自动化系统了解受管理系统，并创建应用程序在自动化环境中生存所需的松耦合。
随着容器化基础设施的构建，应用程序可以使用一套关键接口，这些接口远远超出了今天单个节点可用的范围。“无服务器模式”（意味着短暂的、事件驱动的功能执行）的采用将进一步加剧在与节点完全解耦的环境中理解运行代码的需求。所需的服务将从应用程序配置开始，扩展到监控、日志记录、自动缩放等等。随着应用程序不断适应成为“云原生”世界中更完整的公民，功能集只会增长。
进一步探讨一个例子，已经开发了许多服务发现解决方案，但它们通常与特定的存储实现、特定的编程语言、非标准协议相关联，或者在其他方面有自己的见解（例如，规定应用程序命名结构）。这使得它们不适合通用用途。虽然 DNS 有局限性（最终需要解决），但它至少是一个标准协议，其实现方面具有创新空间。CoreDNS 和其他云原生 DNS 实现证明了这一点。
当我们查看 Google 内部的系统时，由于主要是同构的软件和硬件环境，我们能够在没有正式接口定义的情况下实现非常高的自动化水平。相邻系统可以安全地假设接口，通过提供一套普遍使用的库，我们可以绕过这个问题。一个很好的例子是我们的日志格式不需要正式指定，因为生成日志的库由维护日志处理系统的团队维护。这意味着到目前为止，我们已经能够在没有像 fluentd 这样的东西的情况下运行（fluentd 正在解决社区中与日志记录系统交互的问题）。
即使 Google 已经以这种方式设法应对，但它仍然伤害了我们。一种情况是当我们收购一家公司时。将其技术移植到我们的自动化系统中运行需要大量工作。在继续创新的同时完成这项工作尤其困难。更重要的是，开源世界正在发生许多创新，我们不容易利用。当新技术出现时，我们希望能够对其进行试验，逐步采用它，并可能回馈它。当你运行一个垂直集成的、定制的堆栈时，这是很难做到的。
缺乏标准接口使客户面临三种选择：
- 接受高运营成本（现状），并接受你的开发人员在许多情况下会将大部分时间用于处理应用程序的维护和管理。
- 注册成为像 Google 一样（构建你自己的所有东西，甚至包括地板上的混凝土）。
- 依靠单个或少数供应商提供完整的解决方案，并接受一定程度的锁定。无论公司规模大小（从企业到初创公司），很少有人觉得这有吸引力。我们认为，开放的社区更加强大，并且当堆栈的每一层都有竞争时，客户会受益。应该有可能在每一层（日志记录、监控、编排、容器运行时环境、块和文件系统存储、SDN 技术等）组合一个具有最佳功能的堆栈。
标准化管理系统和应用程序之间的接口（至少通过约定）至关重要。可以将使用通用接口约定视为创建在云中和大规模工作的现代系统中的第十三要素（扩展了 12 要素方法）。
Kubernetes 和云原生计算基金会（CNCF）为支持标准接口的出现以及支持完全自动化的软件世界的出现提供了绝佳的机会。我们很乐意看到这个社区拥抱从工作技术中推广标准接口的理想。显而易见的第一步是识别一组关键的即时接口，并在 CNCF 中建立工作组，开始评估该领域中作为候选者的存在，并赞助工作开始开发跨容器格式、编排器、开发人员工具以及交付云原生愿景所需的众多其他系统的标准接口。