云原生应用不需要云

当今的流行词“云原生”具有十足的讽刺意味。

首先要注意的是，尽管名为云原生，但其并不需要云。 我知道，对吧？ 该名称源自构建依赖于基础设施的应用应用的架构方法，并围绕云的概念进行设计：弹性、规模经济和分布式计算。 毫无疑问，云计算将这些概念带入了应用交付的各个方面：从应用程序架构到自动化，从基于 API 的集成到基础设施。 云计算改变了我们开发、构建和部署应用的方式。 在公共云中诞生的应用程序自然具有许多相同的依赖关系和特性。 因此，这个名字准确地代表了该建筑风格的词源。

毫无疑问，云原生与容器之间存在着联系。 这本身就使其不同于主要依靠虚拟机和云原生服务来实现类似目标的云原生应用程序。 云原生和容器紧密耦合，因为相关的容器编排器（Kubernetes）是将应用与提供弹性所需的基础设施耦合起来的最简单、最普遍的方式，并通过它实现所需的规模经济。

在云原生应用中，组件被原子化以支持规模经济。 因此，云原生和容器几乎是同义词。 您需要能够按需扩展所需的功能。 这种应用的弹性、功能分区传统上是通过依赖第 7 层（HTTP）路由的架构实现的，云原生也不例外。 相同的原则适用于这些现代应用，并且通常使用入口控制器（基础设施应用服务）来管理将入站请求分发到应用组件的适当的基于容器的实例。

这种分区通常在 API 级别进行，其中 URI 与和特定容器服务匹配的 API 调用相匹配。 入口控制将请求定向到适当的容器服务，然后它将请求分发到组件/应用实例池中。 这是一个两层的蛋糕，其中第 7 层（HTTP）入口控制分发到普通的旧负载均衡器（POLB）进行交付和履行。

此外，我们还依赖服务注册表，实际上，它是促进云原生应用弹性所需的另一项基础设施应用服务。 如果没有服务发现机制，负载均衡和入口控制就无法运行，从而导致应用无法运行。

组件、服务、服务注册表、负载均衡器和入口控制之间的这种关系是云原生应用原则的体现。 应用组件和基础设施紧密相连，但又不紧密耦合。 如果没有第 7 层路由和普通的负载均衡功能，组件就无法实现规模经济或跨环境分布。 基础设施和应用之间的依赖关系是真实存在的，并且对于交付应用程序的业务需求至关重要。

所有这些都不依赖或需要任何类型的云计算环境。 云原生应用可以（并且经常）单独部署。 事实上，如果我们查看有关容器及其运行位置的数据，我们会发现“本地”相对于公共云环境仍占据优势。 

现在，虽然确实可以在私有（内部）云上部署容器 - 而且我们自己的研究确实继续表明，内部私有云仍然是最流行的云模型。 在我们的2019 年应用服务状况调查中，超过四分之三 (79%) 的受访者在本地私有云中拥有应用，而公共云仍难以达到 45% 的多数。

云原生应用是一种快速增长的架构，可以肯定它在未来五年内将继​​续增长。 了解它们与基础设施应用服务的关系和依赖关系是成功交付（和保护）这些现代应用的关键要素。