为什么“少就是多”是云计算的秘密

作者：Jason Bloomberg 2019-07-23 10:40:58

云计算 在云原生计算方面缺少什么?结果、代码、状态、信任。混合IT、超融合基础设施、多云、容器、微服务。IT基础设施的发展速度如此之快，以至于人们的脚下也可能是即将喷发熔岩的岛屿，因此必须找到一些稳定的核心岛屿，以免被变化的创新和颠覆的岩浆所吞噬。

 在云原生计算方面缺少什么?结果、代码、状态、信任。

[[271489]]

混合IT、超融合基础设施、多云、容器、微服务。IT基础设施的发展速度如此之快，以至于人们的脚下也可能是即将喷发熔岩的岛屿，因此必须找到一些稳定的核心岛屿，以免被变化的创新和颠覆的岩浆所吞噬。

好消息是，人们有这样一个岛屿：云原生计算。

将云计算带给IT环境

云原生计算采用云计算的最佳实践——横向可扩展性、弹性和最终用户可配置性等，并将其扩展到整个IT环境。

正如云计算通常将硬件和整个物理层抽象化一样，云原生计算将此原则扩展到所有内部环境。因此，云原生方法是混合IT的基础，它试图抽象多个公共云、私有云、内部虚拟化和遗留环境，为人们提供端到端、基于策略的控制和工作负载可迁移性。

但是，云原生计算超越了混合IT。它还认识到容器化是现代IT基础设施的核心，不仅是唯一的，而且在从传统虚拟化到无服务器计算的范围内。

不出所料，Kubernetes成为当今实施云原生基础设施的核心，尽管并非所有云原生方法都利用它。

也许考虑云原生计算的最重要方式是作为一种架构方法。云原生架构建立在云计算和DevOps最佳实践的基础上，将它们从云计算本身带到了企业IT团队。

只有一个问题：云原生甚至不仅仅是一种方法，因为它改变了人们必须关注IT基础设施的方式。实际上它代表了一个镜头，通过这个镜头，人们可以在全新的视野中看待企业IT。出于这个原因，它是一种新的架构范式。

“Less”#1：无代码

具有讽刺意味的是，了解云原生架构的范式转换能力的较好方式是强调其中缺少的内容：云原生代码是无代码、无信任、无状态的。

并不是说人们不必处理状态信息或编写代码，也不是不相信任何事情。相反，这三个“Less”方式描述了人们在所做的每件事中都必须追求的核心云计算原则。

“无代码”适用于人们如何组装和配置IT基础设施的元素，并直接遵循软件定义的最佳实践。当人们说软件定义网络中的“软件定义”时，意味着人们可以将所讨论系统的行为表示为基于元数据的模型，这些模型的行为是声明性的。

“基础设施即代码”的移动是这个故事的一部分，只有在使用云原生时，人们才希望在描述和配置系统行为的方式上不再采用代码。相反，人们希望它们是可配置和可扩展的，而不是可定制的。

因此，Kubernetes遵循这样的做法并非巧合。甚至Kubernetes的各种“风格”都共享一个代码库。这种从可定制性到可扩展性优先级的转变，是由于学习了之前技术的经验和教训——从定制企业应用程序的昂贵工具到大量不同版本的Linux。

此外，虽然云原生基础设施的可配置性是无代码故事的一部分，但它也扩展到在该基础设施上运行的应用程序。因此，低代码和无代码应用程序创建平台也遵循无代码原则，这是没有错的。

事实上，无代码因此将几种现有趋势组合成单一的体系结构范例，其中包括软件定义的方法、声明性配置、模型驱动的计算以及可定制性的可扩展性。

“Less”#2：无信任

“无信任”或者网络安全专业人士也称之为“零信任”，是现代网络安全的基本特征。人们不能再依赖外围安全性来提供可信赖的环境。相反，人们必须假设网络的所有部分都是不可信的，并且每个端点都必须建立自己的信任。

因此，Kubernetes呼吁进行无信任的互动并不奇怪。微服务端点是动态的，因此这些抽象端点必须处理自己的安全性。

当然，无可靠性超越了Kubernetes和容器的世界。无服务器计算基本上是无信任的，因为功能端点现在是完全抽象的，因此负责其自身的安全性。

物联网和边缘计算的兴起

随着端点的数量和种类的爆炸性增长，物联网和边缘计算的兴起增加了无信任计算的风险。事实上，除非人们采取无信任的方法，否则无法充分保护物联网。

事实上，当人们考虑在企业物联网部署环境中管理安全性时，除非底层架构也是无代码且完全由策略驱动，否则根本就没有有效的方法。因此，无信任和无代码是齐头并进的。

“Less”#3：无状态

无状态也许是三个“Less ”方式中最难理解的，主要是因为状态在现代架构方法中的角色转变。

在客户端/服务器和n层体系结构中，在持久层(数据库)中管理状态。随着人们学习扩展n层体系结构，在缓存中管理状态变得越来越重要，而如今，缓存是云计算的重要组成部分，因此通常是云原生基础设施。

然而现在，容器和微服务提高了管理状态的风险。容器本质上是无状态的，是其固有短暂性的必然副作用。毕竟，如果数据在一瞬间消失，人们就不希望将数据存储在一个数据中。

无状态也是容器快速可扩展性和弹性的秘密之一。虚拟机可能需要几分钟才能启动，而容器化微服务(以及无服务器功能)需要几毫秒，主要是因为它们是无状态的。

然而，管理状态与以往一样重要，因为大多数应用程序需要某种形式的数据持久性，如果只是为了跟踪应用程序在任何时刻正在做什么。因此，必须在一个固有的无状态环境中处理状态，应用程序由无状态微服务组成，这些微服务知道如何处理信息而不存储信息。

为了在无状态环境中实现状态管理，Kubernetes采用云原生架构方法，通过无代码、声明性原则抽象存储，并通过API公开这些有状态资源。

这种方法允许组织从其持久层获得可用性和弹性，而不需要容器本身是有状态的。此外，由于状态管理完全依赖于API，因此以无信任的方式保护此类端点至关重要。

然而，在三个“Less”方式中，无状态仍然是最大的挑战，也是最具活力的创新领域。预计未来几年该领域将取得重大进展。

随着应用程序在云原生环境中向上和向下扩展，微服务在毫秒级别上出现和消失。此外，用于部署此类微服务的持续集成 (CI) / 持续交付(CD)方法将持续出现新的和不断变化的微服务。

配置基础设施以大规模处理此类动态行为的唯一方法是通过无代码方法。保护此类应用程序资产的唯一方法是通过无信任。这些应用程序可以跟踪任何事物，并且仍然可以扩展的唯一方法是在固有的无状态环境中管理状态。

无信任正在成为网络安全领域日益占主导地位的最佳实践。随着低代码/无代码平台的兴起以及Kubernetes和其他现代基础设施软件的可配置性，无代码性也正在建立。

随着短暂容器和微服务的兴起，无状态也在核心云原生架构原则中占有一席之地。

许多组织已经在这些实践中的一个或两个方面取得了进展。很少有人采用这三种方法，也很少有人采用这三个“Less”方式开发出云原生的架构。

但是不要搞错，为了支持新的架构，这三个“Less”方式的组合是企