云原生基础架构并不适合所有人。任何架构设计都经过了一系列的权衡。您只有熟悉自己的需求才能决定哪些权衡是有益的，哪些是有害的。
不要在不了解架构的影响和限制的情况下采用工具或设计。我们相信云原生基础架构有很多好处，但需要意识到不应该盲目的采用。我们不愿意引导大家通过错误的方式来满足需求。
怎么知道是否应该使用云原生基础架构设计？确定云原生基础架构是否适合您，下面是一些需要了解的问题：
- 您有云原生应用程序吗？(有关可从云原生基础架构中受益的应用程序功能，请参阅第 1 章)
- 您的工程团队是否愿意且能够编写出体现其作业功能的生产质量代码？
- 您在本地或公有云是否拥有基于 API 驱动的基础架构（IaaS）？
- 您的业务是否需要更快的开发迭代或非线性人员 / 系统缩放比例？
如果您对所有这些问题都回答“yes”，那么您可能会从本书其余部分介绍的基础架构中受益。如果您对这些问题中的某个问题回答是“no”，这并不意味着您无法从某些云原生实践中受益，但是您可能需要做更多工作，然后才能从此类基础架构中充分受益。
在业务准备好之前武断地采用云原生基础架构效果会很糟糕，因为这会强制使用一个不正确的解决方案。在没有充分调查的情况下可能会失败，您可以能会把云原生架构看做是有缺陷或毫无用处的。鉴于之前尝试的云原生方案的失败，今后该方案也可能很难再次采用，无论它是否是正确的解决方案。
在您准备将组织和技术转变为云原生时，我们将讨论一些需要关注的领域。要考虑的事情有很多，关键领域是您的应用程序、组织中的人员、基础架构系统和您的业务。
应用程序
应用程序是准备工作中最简单的部分。设计模式已经很完善，自公共云出现以来，工具性能得到了显着提升。如果您无法构建云原生应用程序并通过自动部署管道来验证它们的话，则不应继续采用云原生基础架构。
构建云原生应用程序并不一定需要微服务。这并不意味着您必须用最流行的语言开发所有软件。您必须编写可以由软件管理的软件。
在开发过程中，人只会与云原生应用程序进行交互。其他一切都应该由基础架构或其他应用程序来管理。
应用程序应该可以动态地扩展出多个实例。扩展通常意味着负载均衡器后运行着同一个应用程序有多个副本。假定应用程序将状态存储在存储服务（即数据库）中，并且不需要运行实例之间的复杂协调。
动态应用程序管理意味着不需要人参与这项工作。应用程序度量触发了基础架构操作扩展应用程序。这是大多数云环境的基本特征。运行动态伸缩的资源组并不意味着您拥有云原生基础架构；但如果您的应用程序可以自动伸缩，它可能表明您的应用程序已准备就绪了。
为了使应用程序受益，编写应用程序和配置基础架构的人员需要支持这种工作方法。如果没有人愿意放弃对软件的控制，您将永远无法实现它的好处。
人
人是云原生基础架构中最难的部分。
如果您想建立一个能够用软件取代人们职能和决策的架构，那么您需要确保人们了解您有最大的诉求。不仅需要人们接受变化，还需要他们自己主动寻求改变。
开发应用程序很困难，运维基础架构很难。应用程序开发人员经常相信他们可以用工具和自动化取代基础架构运维，运维人员希望应用程序开发人员能够编写更可靠的代码，并提供自动调试和恢复。这些紧张关系是 DevOps 的基础，DevOps 有许多其他书籍，包括由 Jennifer Davis 和 Katherine Daniels 撰写的 Effective DevOps（O’Reilly，2016）。
人们不会扩大规模，也不擅长重复无聊的工作。
应用程序和系统工程师的目标应该是消除无聊和重复的任务，以便他们可以专注于更有趣的问题。他们需要具备开发可以包含业务逻辑和决策的软件的技能。需要有足够的工程师来编写所需的软件，更重要的是维护它。
最关键的方面是他们需要一起工作。如果没有其他方面的支持，工程的一方无法迁移到运行和管理应用程序的新方式。团队组织和沟通结构非常重要。
我们会尽快将团队准备好，但首先，我们必须确定基础架构迁移到云原生的时机。
系统
云原生应用程序需要系统抽象。应用程序不应该关注单个硬编码主机名。如果您的应用程序无法在个别主机上运行，那就说明您的系统尚未准备好使用于云原生基础架构。
使用单个服务器（虚拟机或物理机）运行操作系统，并将其转换为访问资源的方法，这就是我们所说的“抽象”。单个系统不应该是应用程序部署的目标。资源（CPU、内存和磁盘）应该集中在所有可用的机器上，然后由平台根据应用程序的请求进行分配。
在云原生基础架构中，您必须隐藏底层系统以提高可靠性。云计算基础架构（如应用程序）会预期基础组件故障，并且可以优雅地处理此类故障。这是必要的，因为基础架构工程师不再控制堆栈中的所有内容。
Kubernetes 云原生基础架构
Kubernetes 是一个框架，它使云的方式管理应用程序变得更加容易。但是，您也可以用一种非云原生的方式使用 Kubernetes。
Kubernetes 公开了基于其核心功能的扩展，但这不是您的基础架构的最终目标。其他项目 (例如，OpenShift) 建立在它之上，将 Kubernetes 从开发人员和应用程序中抽象出来。
应用程序应该运行在平台上。云原生基础架构并且鼓励这样运行基础架构的方式。
如果您的应用程序是动态的，但基础架构是静态的，那么您很快就会陷入单靠 Kubernetes 无法解决的僵局。
当这不再是一个挑战时，基础架构已经准备好成为云原生的了。一旦基础架构变得简单，自动化、自助服务和动态，就有可能被忽略。当系统可以被忽略，并且技术变得单调时，是时候向上移动堆栈了。
如果您的系统管理依赖于硬件定制或在“混合云”中运行，则您的系统可能还没有准备好。可能需要管理一个数据中心，并且私有化。您需要保持警惕，将建立数据中心的责任与管理基础架构的责任分开。
谷歌、Facebook、亚马逊和微软都发现通过开放的计算项目从头开始创建硬件是有好处的。之所以创建自己的硬件是因为有性能和成本的限制。因为硬件设计和基础架构构建者之间存在明确的责任分离，这些公司能够在创建定制硬件的同时运行云原生基础架构。它们不会受到“内部部署”的阻碍。相反，他们可以共同优化其硬件和软件，以获得更高的效率和性能。
管理自己的数据中心需要大量时间和金钱的投入。创建私有云也是如此。两者都需要建立和管理数据中心团队、创建和维护 API 的团队以及在 IaaS API 之上创建抽象的团队。
所有这些都可以完成，决定管理整个堆栈是否有价值取决于您的业务。
现在，我们看看业务领域需要做哪些准备才能迁移到云原生。
业务
如果系统的架构和组织的架构不一致，则组织的架构会胜出。
—— 鲁斯马兰，“康威定律”
企业变革速度非常缓慢。当通过扩展人员来管理扩展系统不再有效时，以及产品开发需要更多灵活性时，他们可能已经准备好采用云原生实践了。
人无法无限扩展。对于增加管理更多服务器或开发更多代码的每个人来说，支持他们的人力基础架构（例如办公室空间）都有一定的压力。因为需要更多的沟通和协调，还会有更多额外的开销。
正如我们在第 1 章中讨论的那样，通过使用公有云，您可以通过租用服务器来减少一些流程和人员开销。即使使用公有云，您仍然会需要管理基础架构详细信息的人员（例如服务器，服务和用户帐户）。
当沟通结构反映业务需要创建的基础架构和应用程序时，业务已准备好采用云原生实践。这包括反映像微服务这样架构的沟通结构。他们可能是小型的独立团队，无需通过层层管理与其他团队交流或合作。
DevOps 和 Cloud Native
DevOps 可以补充团队合作的方式，并影响使用的工具类型。公司采用后有很多好处，包括快速原型化和提高部署速度。它也非常注重组织的文化。
云原生需要高性能组织，但更注重于设计、架构和健康度，而不是团队工作流程和文化。如果您原以为必须解决应用程序开发人员、基础架构运维以及技术部门中任何人员之间的交互问题，才可以成功地实现云原生模式的话，那么您可能会对此感到意外。
迫使业务变化的另一个限制因素是应用程序对敏捷性的要求更高了。企业不仅需要快速部署，还需要彻底改变部署的内容。
部署的原始数量无关紧要。重要的是尽可能快地提供客户价值。相信部署的软件将第一次，甚至是第 100 次，满足所有客户的需求，这是一个谬论。
当业务意识到需要频繁迭代和更改时，它可能已经准备好采用云原生应用程序了。只要在人员效率和流程方面遇到限制，且可以随时更改它，就可以准备迁移到云原生基础架构了。
所有那些表明何时采用云原生的因素都不能说明全部情况。任何设计都需要权衡折衷。因此，在某些情况下，云原生基础架构不是正确的选择。
什么情况下不需要云原生基础架构
只有了解了系统有哪些限制，再清楚系统可以带来的好处才有用。也就是说，是否采用一个系统的决定性因素是它的限制而使用它可以带来的利益。
记住需求随时间变化也很重要。现在的关键功能可能在未来并不是。同样，如果下面的情况目前并不理想，那么您可以不采用云原生。
技术限制
就像应用程序一样，在基础架构中，最简单的是技术性限制。如果您知道什么时候应该采用有技术优势的云原生基础架构，那么您可以思考下何时不应该采用云原生基础架构。
第一个限制是没有云原生应用程序。正如在第一章中讨论的那样，如果您的应用程序需要人工交互，无论是调度、重新启动还是搜索日志，云原生基础架构都没有多大好处。
即使您有一个可以动态调度的应用程序，也不会使其成为云原生。如果您的应用程序在 Kubernetes 上运行，但仍需要人工设置监控、日志收集和负载均衡，则它不是云原生。只是将应用程序部署在 Kubernetes 运行并不意味着云原生。
如果您有一个编排调度器，重要的是看看它是如何运行的。您是否需要下订单、创建工单或发送电子邮件以获取服务器？
这些是您没有自助服务基础架构的指标，这是云计算的一项要求。
在云中，您只需提供帐单信息并调用 API。即使您在内部运行服务器，您也应该有一个可以构建 IaaS 的团队，然后将云原生基础架构分层布局。
如果您要在自己的数据中心中构建云环境，图 2-1 显示了您的基础架构组件适合的示例。所有原始组件（例如，计算、存储、网络）都应该可以从自助式 IaaS API 中获得。
在公有云中，您拥有 IaaS 和托管服务，但这并不意味着您的业务已准备好使用公有云。
当您构建运行应用程序的平台时，了解您正在进行的操作非常重要。最初的开发只是构建和维护平台所需花费的一小部分，特别是对业务至关重要的平台。
维护通常会消耗大约 40％到 80％（平均 60％）的软件成本。因此，这可能是最重要的生命周期阶段，发现业务需求和建立开发所需的技能可能对于一个小团队来说太过分了。一旦您掌握了开发所需平台的技能，您仍然需要投入时间来改进和维护系统。这需要比初始开发更长的时间。
公有云提供商的产品为企业提供绝佳的运行环境。如果您不能或者不愿意让您的平台成为业务，那么您不应该自己创建一个平台。
请记住，您不必自己构建一切。您可以使用可以组装到所需平台的服务或产品。
可靠性仍然是基础架构的关键特性。如果您还没有准备好放弃对底层基础架构堆栈的控制，并且仍然通过接受故障来制造可靠的产品，那么云原生基础架构并不是正确的选择。
非技术限制同样重要，可能超出您的控制范围。
业务限制
如果现有流程不支持更改基础架构，则需要首先克服该障碍。幸运的是，您不必一个人做。
本书希望有助于向需要说服力的人清楚地解释云原生的好处和流程。还有许多案例研究和公司分享他们采用这些做法的经验。本书附录 C 中将提供一个案例研究，您还可以找到相关示例并与同行和管理层分享。
如果企业还没有实验的途径和支持尝试新事物的文化（以及伴随失败而来的后果），那么改变流程可能是不可能的。在这种情况下，您的需要等待达到必须改变的临界点，或者说服管理层认为改变是必要的。
以一个外部的视角准确辨别一个企业是否准备好采用云原生是不可能的。不过，下面这些流程可以明确指示一个公司未准备接纳云原生：
- 需要人工干预的资源请求
- 定期安排需要人工操作的维护窗口
- 手动库存跟踪和资源分配
- 电子表格清单
如果调度、部署、升级或监控服务，这些流程除了负责服务的团队以外还有其他人员参与的话，则可能需要在迁移到云原生基础架构之前或迁移期间解决这些流程。
有时也有业务无法控制的过程，例如行业法规。可悲的是，这些变化甚至比内部流程更难和更慢。
如果行业法规限制了发展的速度或敏捷性，我们就没有任何建议，只能尽您所能。如果法规不允许业务在公有云中运行，请尽量使用技术来运行内部部署。管理层将需要为任何管理机构制定的法规制定一个案例。
云原生基础架构还有另一个非技术障碍。在一些公司中，有一种不使用第三方服务的文化
如果您的公司不愿意或无法通过使用第三方托管服务的流程，则可能不适合采用云原生基础架构。我们将在附录 B 中更详细地讨论何时使用托管服务。
结论
要成功，单靠计划是不够的。还需要即兴发挥。
——Isaac Asimov
在本章中，我们讨论了何时采用云原生基础架构的注意事项。有许多需要记住的领域，每种情况都是独一无二的。希望这些指导原则可以帮助您发现变革的适当时机。
如果您的公司已经采用了一些云原生实践，这些问题可以帮助确定可以采用这种架构的其他领域。当您在权衡云原生是否为正确的解决方案，以及如何开始时，了解这一点非常重要。
如果您尚未将云原生实践应用于工作，则没有捷径。企业和员工需要共同决定云原生是否是正确的解决方案，并共同取得进展。没有人独自成功。