如果您认为云原生基础架构是可购买的产品或是从云供应商那购买的服务器，我们很抱歉让您失望了。如果不采用这些做法并改变您建设和维护基础架构的方式，您就不会受益。
它不仅仅影响服务器、网络和存储。它关乎的是工程师如何管理应用程序，就像接受故障一样。
围绕云原生实践建立的文化与传统技术和工程组织有很大不同。我们并不是解决组织文化或结构问题的专家，但如果您希望改变组织结构，我们建议您从高绩效组织中实施 DevOps 实践的角度来看待价值观和经验教训。
一些需要探索的地方是 Netflix 的文化套餐，它促进了自由和责任感，还有亚马逊的双比萨团队，这些团队以低开销推广自治团体。云原生应用程序需要与构建它们的团队具有相同的解耦特征。康威定律很好地描述了这一点：“设计系统的架构受制于产生这些设计的组织的沟通结构。”
在我们结束本书时，我们希望关注哪些领域是您采用云原生实践时最重要的。我们还将讨论一些预测变化的基础架构模式，以便您知道将来要寻找什么。
关注改变的地方
如果您拥有现有的基础架构或传统数据中心，则过渡到云原生不会在一夜之间发生。如果您有足够大的基础架构或两个以上的人员管理它，试图强制实施基础架构管理的新方法可能会失败。
采用这些模式与配置新服务器或购买新软件无关。要开始采用云原生基础架构，最重要的是是首先关注这些领域：
- 人
- 架构
- 混乱
- 应用程序
直到您准备好这些区域以使用本书中描述的实践，才能开始更改基础架构。
人
比竞争对手更快学习的能力可能是唯一的可持续竞争优势。
——Arie de Geus
正如我们在第 2 章中所讨论的，人是实施任何变革中最难的部分。他们的抵制有很多原因，而那些要求进行变更以帮助其影响的人有责任。
当需要改变的驱动激励时，变更更容易。主动提高潜力是一个很好的激励因素，但如果没有紧迫感，就很难改变行为。
人们抗拒改变的原因大多来自恐惧。人们喜欢习惯，因为他们可以控制并避免意外。
为了使任何技术取得成功的重大转变，您需要与人们合作以最大限度地减少他们的恐惧。给他们一种主人翁感，并解释变化的明确目标。确保突出新旧技术之间的相似之处，特别是在改变后他们将扮演的角色。
人们了解这种变化并不是因为他们在旧系统或现有系统中的失败，这一点也很重要。他们需要明白，要求已经改变，环境不同，并且希望他们成为变革的一部分，因为你尊重他们所做的并且对他们能做的事有信心。
他们需要学习新事物，为此，失败是必要的，预期的，并且是进步的标志。
鼓励学习和实验，并奖励适应数据洞察的人员和系统。让工程师通过诸如“百分之二十的时间”之类的自由来探索新的可能性，可以做到这一点。
如果敏捷系统没有改变，它就没有好处。一个不适应和改进的系统将无法满足正在改变和学习的企业的需求。
一旦你能够激发人们寻求改变，你应该用信任和自由来赋予他们力量。不断引导他们将自己的目标与业务需求结合起来，并赋予他们应聘的管理职责。
如果人们已经准备好采用本书中的做法，那么实现它就没有什么限制。关于创建组织变革的更深入的指导，我们推荐阅读 John P. Kotter（哈佛商业评论出版社）的“领导变革”。
改变环境文化需要组织的大量努力和支持，以及更改应用程序运行的基础架构。您选择的架构可能会对采用云原生模式的能力产生重大影响。
架构
弹性、安全性、可伸缩性、可部署性、可测试性是架构问题。
——Jez Humble
将应用程序迁移到云原生基础架构时，您需要考虑如何管理和设计应用程序。例如，作为云原生应用程序前身的 12 因子应用程序受益于在平台上运行。它们被设计为最小化手动管理，频繁更改和弹性。许多传统应用程序的架构都是为了抵制自动化，不经常升级和失败。在迁移它之前，您应该考虑应用程序的架构。
单个应用程序架构是一个问题，但您还需要考虑应用程序如何与基础架构内的其他服务通信。应用程序应已云环境中支持的协议以及通过明确界定的接口进行通信，通过采用微服务保持应用程序范围很小可以帮助定义应用程序间接口和提高应用程序部署速度。但是，采用微服务会暴露出新的问题，如应用程序通信速度较慢以及分布式跟踪和策略控制网络的需求。如果不能为您的基础架构提供好处，就不要采用微服务。
虽然您几乎可以适应任何应用程序在容器中运行并使用容器编排器进行部署，但如果首选迁移所有关键业务数据库服务器，您将很快就会后悔。
首先确定接近具有第 1 章概述的特性的应用程序并获得在云原生环境中运行它们的经验。一旦您围绕简单的应用程序集体获得经验和良好实践，那么您就可以决定接下来要做什么。
您的服务器和服务也不例外。在将基础架构切换为不可变的之前，您应确保它解决了当前的问题，并意识到新问题。
可靠系统中最重要的架构考虑是争取简单的解决方案。软件和系统自然会变得复杂，这会造成不稳定。在云中，您可以释放对许多区域的控制，因此在仍然可以控制的区域保持简单性很重要。
无论您将内部部署基础架构迁移到云中还是创建新的解决方案，都要确保您在第 1 章中进行可用性数学计算，并为混乱情况做好准备。
混沌管理
拥抱失败并期待混乱。
——Netflix 的 Andrew Spyker
当您构建云原生应用程序和基础架构时，其目标是创建最小可行产品（MVP）和迭代。尝试指定您的客户需要什么或他们将如何使用您的产品可能会有用一段时间，但成功的应用程序将适应而不是预测。
客户需求改变；应用程序需要随它们改变。您无法计划和构建完整的解决方案，因为在产品准备就绪时，需求已发生变化。
保持敏捷并在现有技术基础上发展很重要。就像您为应用程序导入库一样，您应该为基础架构使用 IaaS 和 SaaS。你越努力建立自己，你就越能提供价值。
无论何时释放对某物的控制，都会冒着意想不到的风险。如果因为导入的库已更新而导致应用程序中断，您将会知道这是什么感觉。
您的应用程序依赖于库所提供的功能，该功能已更改。你是否应该删除库并编写自己的功能以便控制它？答案几乎总是不。相反，您更新应用程序以使用新库，或者将正在运行的较旧版本的库与应用程序捆绑在一起，以暂时避免损坏。
运行在公有云上的基础架构也是如此。您不再控制硬连线网络，使用什么 RAID 控制器，或者虚拟机的哪个版本的虚拟机管理程序运行。您所拥有的只是可以在底层技术之上提供抽象的 API。
您无法控制底层技术何时发生变化。如果云提供商弃用所有大型内存实例类型，则您别无选择，只能遵守。您要么适应新的尺寸，要么支付更换提供商的成本（时间和金钱）（请参阅附录 B 关于锁定）。
最重要的是，您构建的基础架构不再可以从单个关键服务器获得。如果您采用云原生基础架构，无论您是否喜欢，您正在构建一个分布式系统。
通过简单地避免失败来保持服务可用的旧做法不起作用。目标不再是您可以设计的最大数目的几个 9—— 而是你可以摆脱的最小数量的几个 9。
站点可靠性工程（Site Reliability Engineering）以这种方式解释它：
坚持 SLO 将百分之百满足是不现实的和不可取的：这样做可能会降低创新和部署的速度，需要昂贵的，过于保守的解决方案，或两者兼而有之。相反，最好允许一个错误预算 —— 一个可能错过 SLO 的速率，并且每天或每周对其进行跟踪。
工程的目标不可用；它创造了商业价值。你应该制造弹性系统，但不要以过度工程解决方案为代价来避免混乱。
测试更改以防止停机的旧方法也不起作用。为大型分布式系统创建测试环境并不重要。当服务经常更新并且部署是自助服务时尤其如此。
当 Netflix 每天有 4,000 次部署或 Facebook 有 10,000 个同时运行的版本时，对环境进行快照是不可能的。测试环境需要动态分离生产部分。基础架构需要支持这种测试方法，并支持经常测试生产中的新代码所带来的失败。
你可以测试一些混乱（参见第 5 章），但混沌根据定义是不可预测的。准备您的基础架构和应用程序，以便可预测地对混乱做出反应，而不要试图避免它。
应用程序
基础架构的目的是运行应用程序。如果您的业务完全基于向其他公司提供基础架构，那么您的成功仍取决于其运行应用程序的能力。
如果你建立它，他们不能保证来用。您创建的任何抽象需要提高运行应用程序的能力。
避免“泄漏抽象”（Leaky Abstraction）
抽象并不完全隐藏抽象的实现细节。泄漏抽象定律指出：“所有非平凡的抽象在一定程度上都是泄漏的。”
这意味着你进一步抽象某事，隐藏事物的细节就越困难。
例如，应用程序资源请求通常通过请求 CPU 核心的百分比，内存量和磁盘存储量来抽象化。这些资源的物理分配不直接由应用程序管理（API 不是由它们规定的），但对资源的请求很明显地表明运行应用程序的系统具有可用的这些类型的资源。
相反，如果抽象是服务器或数据中心（例如，50 台服务器，0.2 个数据中心）的百分比，那么抽象并不具有相同的含义，因为不存在单一大小的服务器或数据中心单元。确保创建的抽象对于将使用它们的应用程序有意义。
云原生实践的好处是，随着您提高运行应用程序的能力，您还可以提高运行基础架构的能力。如果您遵循第 3-6 章的模式，您将很好地适应使用应用程序不断改进和调整您的基础架构以满足应用程序的需求。
重点关注构建范围小，易于适应，易于操作和故障发生时具有弹性的应用程序。确保这些应用程序负责所有基础架构管理和更改。如果你这样做，你将创建云原生基础架构。
预测未来
如果您已经采用了本书中的模式和实践，那么您现在处于未知领域。运行全球最大基础架构的公司已采用了这些做法。无论他们运行基础架构的新模式是否公开披露或仍在发现之中。
好消息是您的基础架构现在被设计为敏捷和变化。您可以更轻松地适应您遇到的任何新挑战。
为了展望未来的道路，我们可以不考虑现有的基础架构模式，而是考虑基础架构在哪里获得灵感 —— 软件。几乎所有基础架构采用的模式都来自软件开发模式。
例如，分布式应用程序。很多年前，当软件暴露于互联网时，在单一代码库下的单个服务器上运行应用程序不会扩展。这包括管理应用程序的性能和流程限制。
该应用程序需要复制到其他服务器上，然后进行负载均衡以满足需求。当达到限制时，它被分解成更小的组件，创建 API 以通过 HTTP 远程调用功能，而不是通过应用程序库。
基础架构采取了类似的方法来扩大规模；在大多数领域只适应比软件更慢的速度。像 Kubernetes 这样的现代化基础架构平台将基础架构管理分解成更小的组件。这些组件可以根据其性能瓶颈（CPU、内存和 I/O）独立扩展，并且可以快速迭代。
有些应用程序没有相同的扩展需求，也不需要适应新的架构。工程师的需要知道何时采用新技术。只有那些了解其堆栈的局限性和瓶颈的人才能决定什么是正确的方向。
当发现新的限制时，请密切注意新的解决方案应用程序的发展。如果您了解限制是什么以及进行更改的原因，那么您将始终处于基础架构的领先地位。
结论
本书的目标是帮助您更好地理解什么是云原生基础架构以及您为什么要采用它。虽然我们相信它比传统基础架构有很多优势，但我们不希望您在不理解它的情况下盲目使用任何技术。
不要期望在不采用其伴随的文化和流程的情况下获得所有好处。只是在公有云中运行基础架构或运行容器编排器不会改变该基础架构如何适应的过程。
在 AWS 中手动创建少量虚拟机，通过 SSH 连接到每台虚拟机，创建 Kubernetes 集群比改变人们的工作方式更容易。前者不是云原生的。
请记住，配置基础架构的应用程序不是及时的静态快照；它们应该不断运行并将基础架构推向期望的状态。管理基础架构不是维护主机。您需要为资源创建抽象，用 API 来表示这些抽象，以及使用它们的应用程序。
目标是满足您的应用程序的需求，并编写与您的业务流程和工作职能相当的软件应用程序。随着流程和功能的频繁变化，软件需要轻松适应。
掌握它时，您将不断发现在创建新抽象，保持服务弹性以及推动可伸缩性极限方面的挑战。如果您能够找到新的限制和有用的抽象，请回馈给您所属的社区。
开源并通过研究和社区回馈是这些模式是使得它们从先驱环境中出现。共享使更多的创新和见解得以传播，并使每个人更容易实践和适应。
创新不仅来自寻找解决方案或打造下一个出色的产品。创新通常来自寻常的提问、交谈和失败。
请继续做所有这些事情，尤其是失败和分享。