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