云的革命（三）原生云

原生云

术语原生云已成为一种越来越流行的简化方式，用于谈论利用云，容器和编排的现代应用程序和服务，通常基于开源软件。实际上，云计算本地计算基金会（CNCF）成立于2015年，用他们的话说，“围绕一系列高质量项目建立社区，这些项目将容器作为微服务架构的一部分进行编排。”

作为Linux Foundation的一部分，CNCF旨在将开发人员，最终用户和供应商（包括主要的公共云提供商）聚集在一起。 CNCF旗下最着名的项目是Kubernetes本身，但该基金会还孵化和推广云原生态系统的其他关键组件：普罗米修斯，特使，头盔，流利，gRPC等等。

那么云本地人究竟是什么意思呢？像大多数这样的事情，它对不同的人意味着不同的东西，但也许有一些共同点。

原生云应用程序在云中运行;这没有争议。但是，仅仅使用现有应用程序并在云计算实例上运行它并不会使其成为原生云。它既不是在容器中运行，也不是使用Azure的Cosmos DB或Google的Pub / Sub等云服务，尽管这些可能是原生云应用程序的重要方面。让我们来看看大多数人都同意的云原生系统的一些特征：

自动化

如果应用程序要由机器而不是人工来部署和管理，则需要遵守通用标准，格式和接口。 Kubernetes提供这些标准接口的方式意味着应用程序开发人员甚至不需要担心它们。

无处不在，灵活多变，因为它们与磁盘等物理资源分离，或者它们碰巧运行的计算节点的任何特定知晓处，所以容器化微服务可以很容易地从一个节点移动到另一个节点，甚至一个集群移动到另一个节点。

弹性和可扩展性

传统应用程序往往有单点故障：如果主进程崩溃，或者底层计算机出现硬件故障，或者网络资源变得拥挤，应用程序将停止工作。云本机应用程序因其本质上是分布式的，可以通过冗余和优雅降级实现高可用性。

动态

容器协调器（如Kubernetes）可以调度容器以最大限度地利用可用资源。它可以运行它们的许多副本以实现高可用性，并执行滚动更新以平滑地升级服务，而不会丢失流量。

可观察

云本机应用程序本质上更难以检查和调试。因此，分布式系统的一个关键要求是可观察性：监控，日志记录，跟踪和指标都可以帮助工程师了解他们的系统正在做什么（以及他们做错了什么）。

分散式

Cloud native（原生云）是一种构建和运行应用程序的方法，它利用了云的分布式和分散式特性。它是关于您的应用程序如何工作，而不是它运行的位置。云本机应用程序往往由多个协作的分布式微服务组成，而不是将您的代码部署为单个实体（称为整体）。微服务只是一个独立的服务，只做一件事。如果你把足够的微服务放在一起，你会得到一个应用程序。

它不仅仅是微服务

微服务并不是灵丹妙药。 Monoliths更容易理解，因为一切都在一个地方，你可以追踪不同部分的相互作用。但是，就代码本身和维护代码本身的开发团队来说，很难扩展monoliths。随着代码的增长，其各个部分之间的交互呈指数级增长，整个系统的增长超出了单个大脑的能力来理解它。

精心设计的云本机应用程序由微服务组成，但决定这些微服务应该是什么，边界在哪里，以及不同服务应该如何交互也不是一件容易的事。良好的云原生服务设计包括明智地选择如何分离架构的不同部分。然而，即使是设计良好的原生云应用程序仍然是一个分布式系统，这使得它本身就很复杂，难以观察和推理，并且以令人惊讶的方式容易出现故障。

虽然云本机系统往往是分布式的，但仍然可以使用容器在云中运行单一应用程序，并从中获得可观的商业价值。这可能是逐步将整体部件向外迁移到现代微服务的道路上的一步，或者是在将系统重新设计为完全云原生之前的权宜之计。

运营的未来

运营，基础设施工程和系统管理是高技能的工作。他们是否在云原生未来面临风险？我们不这么认为。相反，这些技能只会变得更加重要。分布式系统的设计和推理很难。网络和容器协调器很复杂。开发原生云应用程序的每个团队都需要操作技能和知识。自动化使员工免于枯燥，重复的手工工作，以处理计算机无法自行解决的更复杂，有趣的问题。

这并不意味着所有当前的运营工作都得到保证。系统管理员曾经能够在没有编码技能的情况下顺利通过，除了可能编写奇怪的简单shell脚本。在云中，那不会飞。

在软件定义的世界中，编写，理解和维护软件的能力变得至关重要。如果你不能或不会学习新技能，世界将会让你落后 - 而且一直都是这样。

分布式DevOps

不是集中在为其他团队提供服务的单一运营团队中，运营专业知识将分散在许多团队中。

每个开发团队至少需要一名操作专家，负责团队提供的系统或服务的运行状况。她也将成为开发人员，但她也将成为网络，Kubernetes，性能，弹性以及使其他开发人员能够将其代码交付给云的工具和系统领域专家。

由于DevOps革命，大多数组织不再拥有无法操作的开发人员或不开发的操作员。这两个学科之间的区别是过时的，并且正在迅速被完全抹去。开发和运行软件只是同一件事的两个方面。

有些事情会保持集中

DevOps有限制吗？或者传统的中央IT和运营团队是否会完全消失，融入一群流动的内部顾问，指导，教学和解决操作问题？

我认为不是，或者至少不完全。有些事情仍然受益于集中化。每个应用程序或服务团队都有自己的方式来检测和传达生产事件，例如，或者自己的票务系统或部署工具，这是没有意义的。每个人重新发明自己的轮子都没有意义。

开发人员生产力工程

关键在于自助服务有其局限性，DevOps的目标是加速开发团队，而不是通过不必要的冗余工作来减缓他们的速度。是的，传统操作的很大一部分可以而且应该转移到其他团队，主要是那些涉及代码部署和响应代码相关事件的团队。但要实现这一目标，需要建立一个强大的中央团队并支持所有其他团队运营的DevOps生态系统。

开发人员生产力工程（DPE）。 DPE团队竭尽所能帮助开发人员更好，更快地完成工作：运营基础架构，构建工具，解决问题。

虽然开发人员生产力工程仍然是一项专业技能，但工程师本身可能会向外部进入组织，以便在需要的地方提供专业知识。

Lyft工程师Matt Klein建议，虽然纯粹的DevOps模型对初创公司和小公司有意义，但随着组织的发展，基础架构和可靠性专家自然倾向于吸引中央团队。但他说团队无法无限期缩放：

当一个工程组织达到约75人时，几乎可以肯定有一个中央基础设施团队开始构建产品团队构建微服务所需的共同基板功能。但有一点，中央基础架构团队不再能够继续构建和运营对业务成功至关重要的基础架构，同时还要保持帮助产品团队完成运营任务的支持负担。

此时，并非每个开发人员都可以成为基础架构专家，就像单个基础架构专家团队无法为越来越多的开发人员提供服务一样。对于大型组织，虽然仍然需要中央基础架构团队，但还有一个案例是将站点可靠性工程师（SRE）嵌入到每个开发或产品团队中。他们将自己的专业知识作为顾问带到每个团队，并在产品开发和基础设施运营之间架起桥梁。

你是未来

如果您正在阅读，那就意味着您将成为这个新的原生云未来的一部分。我们将介绍作为使用云基础架构，容器和Kubernetes的开发人员或操作工程师所需的所有知识和技能。

其中一些将是熟悉的，一些将是新的，但我们希望，当你完成这本书后，你会对自己获得和掌握云本地技能的能力更有信心。是的，有很多东西需要学习，但这是你无法处理的。

摘要

必定会让您快速浏览一下原生云DevOps环境，期待它足以让您快速了解云，容器和Kubernetes解决的一些问题，以及它们可能会如何变化IT业务。如果您已经熟悉这一点，那么我们感谢您的耐心等待。

快速回顾一下要点：

云计算使您免于管理自己的硬件费用和开销，使您可以构建弹性，灵活，可扩展的分布式系统。

DevOps认识到现代软件开发并不止于发布代码：它是关闭编写代码的人和使用代码的人之间的反馈循环。

DevOps还为基础架构和运营领域带来了以代码为中心的方法和良好的软件工程实践。

容器允许您在小型，标准化，独立的单元中部署和运行软件。通过将容器化的微服务连接在一起，这使得构建大型，多样化的分布式系统变得更容易和更便宜。

业务流程系统负责部署容器，调度，扩展，网络以及优秀系统管理员可以执行的所有操作，但是采用自动化，可编程的方式。

Kubernetes是事实上的标准容器编排系统，现在可以立即用于生产。