云的革命（三）原生云

 原 生 云

     术语原生云已成为一种愈来愈流行的简化方式，用于谈论利用云，容器和编排的现代应用程序和服务，一般基于开源软件。实际上，云计算本地计算基金会（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是事实上的标准容器编排系统，如今能够当即用于生产。

    Cloud native是一个有用的简写，用于讨论基于云的容器化分布式系统，这些系统由协做的微服务组成，由自动化基础架构做为代码动态管理。

    运营和基础设施技能远非被云本土革命淘汰，并且将变得比以往任什么时候候都更加剧要。

    对于中央团队而言，构建和维护使全部其余团队都能使用DevOps的平台和工具仍然是有意义的。

    将消失的是软件工程师和运营工程师之间的明显区别。它如今只是软件，咱们都是工程师。