第2章 何时采用云原生

云原生基础设施并不适合所有人。任何架构设计都是一系列的权衡。只有熟悉自己需求的人才能决定哪些权衡是有益的，哪些是有害的。

不要在不了解其影响和限制的情况下采用工具或设计。我们相信云原生基础设施有很多好处，但需要意识到它不应该被盲目的采用。我们不愿意引导别人通过错误的方式来满足他们需求。

你怎么知道是否应该使用云原生基础设施进行架构设计？以下是一些你需要了解的问题，以确定云原生基础设施是否适合你：

• 你有云原生应用程序吗？(有关可从云原生基础设施中受益的应用程序功能，请参阅第1章)
• 你的工程团队是否愿意并且能够编写体现其作业功能的生产质量代码作为软件？
• 你在本地或公有云是否拥有基于API驱动的基础设施(IaaS)？
• 你的业务是否需要更快的开发周期或非线性人员/系统缩放比例？

如果你对所有这些问题都回答“yes”，那么你可能会从本书其余部分介绍的基础设施中受益。如果你对这些问题中的某个问题回答是“no”，这并不意味着你无法从某些云原生实践中受益，但是你可能需要做更多工作，然后才能从此类基础设施中充分受益。

在你的业务准备好之前尝试采用云原生基础设施同样糟糕，因为它将强制使用一个不正确的解决方案。试图在调查不充分的情况下获得收益，你可能会失败，并将其架构视为有缺陷或无益处。由于过去的偏见，一个经过尝试的失败的解决方案以后可能很难采用，无论它是否是正确的解决方案。

在你准备将组织和技术成为云原生时，我们将讨论一些需要关注的领域。有很多事情需要考虑，但一些关键领域是你的应用程序，组织中的人员，基础设施系统和你的业务。

应用程序

应用程序是准备工作最简单的部分。设计模式已经很完善，自公共云出现以来，工具性能得到了显着提升。如果你无法构建云原生应用程序并通过经过验证和测试的管道自动部署它们，则不应继续采用基础设施来支持它们。

构建云原生应用程序并不意味着你必须先拥有微服务。这并不意味着你必须用最新的趋势语言开发你的所有软件。这意味着你必须编写可以由软件管理的软件。

在开发过程中，人类应该与云原生应用程序进行交互。其他一切都应该由基础设施或其他应用程序来管理。

了解应用程序的另一种方法是在它们需要动态地扩展多个实例时。扩展通常意味着负载均衡器后面的同一个应用程序有多个副本。它假定应用程序将状态存储在存储服务（即数据库）中，并且不需要运行实例之间的复杂协调。

动态应用程序管理意味着不需要人参与这项工作。应用程序度量触发了扩展，基础设施做了正确的操作来扩展应用程序。这是大多数云环境的基本特征。运行动态伸缩的资源组并不意味着你拥有云原生基础设施;但如果需要auto-scaling，它可能表明你的应用程序已准备就绪了。

为了使应用程序受益，编写应用程序和配置基础设施的人员需要支持这种工作方法。如果没有人愿意放弃对软件的控制，你将永远无法实现它的好处。

人

人是云原生基础设施中最难的部分。

如果你想建立一个能够用软件取代人们职能和决策的体系结构，你需要确保他们知道你有最大的利益。他们不仅需要接受变化，还需要自己去寻求并改变。

开发应用程序很困难;运营基础设施很难。应用程序开发人员经常相信他们可以用工具和自动化取代基础架构操作员基础架构操作员希望应用程序开发人员能够编写更可靠的代码，并提供自动调试和恢复。这些紧张关系是DevOps的基础，DevOps有许多其他书籍，包括由Jennifer Davis和Katherine Daniels撰写的EffectiveDevOps(O’Reilly，2016)。

人们不会扩大规模，也不擅长重复，平凡的工作。

应用程序和系统工程师的目标应该是消除世俗和重复的任务，以便他们可以专注于更有趣的问题。他们需要具备开发可以包含业务逻辑和决策的软件的技能。需要有足够的工程师来编写所需的软件，更重要的是，维护它。

最关键的方面是他们需要一起工作。如果没有其他方面的支持，工程的一方无法迁移到运行和管理应用程序的新方式。团队组织和沟通结构非常重要。

我们将尽快解决团队准备情况，但首先，我们必须确定基础架构系统何时准备好用于云原生基础设施。

系统

云原生应用程序需要系统抽象。应用程序不应该关注单个硬编码主机名。如果你的应用程序无法在个别主机上运行，那么你的系统尚未准备好使用于云原生基础设施。

使用单个服务器(虚拟或物理)运行操作系统，并将其转换为访问资源的方法，这就是我们所说的“抽象”。单个系统不应该是应用程序部署的目标。资源(CPU、RAM和磁盘)应该集中在所有可用的机器上，然后由平台根据应用程序的请求进行分配。

在云原生基础设施中，你必须隐藏底层系统以提高可靠性。云计算基础设施(如应用程序)会预期的发生基础组件故障，并且旨在优雅地处理此类故障。这是必要的，因为基础设施工程师不再控制堆栈中的所有内容。

Kubernetes云原生基础设施

Kubernetes是一个框架，它使管理应用程序变得更容易，并且以一种云的方式促进了这样做。但是，你也可以用一种非云原生的方式使用Kubernetes。

Kubernetes公开了基于其核心功能的扩展，但这不是你的基础设施的最终目标。其他项目(例如，OpenShift)建立在它之上，将Kubernetes从开发人员和应用程序中抽象出来。

平台是你的应用程序应该运行的地方。云原生基础设施支持它们，但也鼓励了运行基础设施的方式。

如果你的应用程序是动态的，但你的基础架构是静态的，那么你很快就会陷入单靠Kubernetes无法解决的僵局。

当它不再是一个挑战时，基础设施已经准备好成为云原生的了。一旦基础设施变得简单，自动化、自助服务和动态，它就有可能被忽略。当系统可以被忽略，并且技术变得单调时，是时候向上移动堆栈了。

如果你的系统管理依赖于硬件定制或在“混合云”中运行，则你的系统可能还没有准备好。可能需要管理一个数据中心，并且私有化。你需要保持警惕，将建立数据中心的责任与管理基础设施的责任分开。

谷歌、Facebook、亚马逊和微软都发现通过开放的计算项目从头开始创建硬件是有好处的。需要创建自己的硬件有性能和成本的限制。因为硬件设计和基础架构构建者之间存在明确的责任分离，这些公司能够在创建定制硬件的同时运行云原生基础设施。它们不会受到“内部部署”的阻碍。相反，他们可以共同优化其硬件和软件，以获得更高的效率和性能。

管理自己的数据中心需要大量时间和金钱的投入。创建一个私有云也是如此。两者都需要建立和管理数据中心团队、创建和维护API的团队以及在IaaS API之上创建抽象的团队。

所有这些都可以完成，并且决定管理整个堆栈是否有价值取决于你的业务。

现在，我们可以看看其他业务领域需要准备什么来转移到云原生实践。

商业

如果系统的体系结构和组织的体系结构不一致，则组织的体系结构会胜出。

——鲁斯马兰，“康威定律”

企业变革速度非常缓慢。当通过扩展人员来管理扩展系统不再有效时，以及产品开发需要更多灵活性时，他们可能已经准备好采用云原生实践了。

人无法无限扩展。对于增加管理更多服务器或开发更多代码的每个人来说，支持他们的人力基础设施(例如办公室空间)都有一定的压力。因为需要更多的沟通和协调，其他人也会有额外的开销。

正如我们在第1章中讨论的那样，通过使用公有云，你可以通过租用服务器来减少一些流程和人员开销。即使使用公有云，你仍然会需要管理基础设施详细信息的人员(例如服务器，服务和用户帐户)。

当通信结构反映业务需要创建的基础设施和应用程序时，业务已准备好采用云原生实践。这包括反映像微服务这样的体系架构的通信结构。他们可能是小型的独立团队，无需通过层层管理与其他团队交流或合作。

DevOps和Cloud Native

DevOps可以补充团队合作的方式，并影响使用的工具类型。它对采用它的公司有很多好处，包括快速原型化和提高部署速度。它也非常注重组织的文化。

云原生需要高性能组织，但更注重于设计，架构和健康度，而不是团队工作流程和文化。但是，如果你认为可以成功的实现云原生模式，而无需解决应用程序开发人员、基础设施运营商以及技术部门中任何人员之间的交互问题，那么你可能会感到意外。

迫使业务变化的另一个限制因素是需要更多的应用程序敏捷性。企业不仅需要快速部署，还需要彻底改变部署的内容。

部署的原始数量无关紧要。重要的是尽可能快地提供客户价值。相信部署的软件将第一次，甚至是第100次，满足所有客户的需求，这是一个谬论。

当业务意识到需要频繁迭代和更改时，它可能已经准备好采用云原生应用程序了。只要它在人员效率和旧流程限制方面遇到限制，并且可以随时更改，就可以为云原生基础设施做好准备。

所有那些表明何时采用云原生的因素都不能说明全部情况。任何设计都需要权衡折衷。因此，在某些情况下，云原生基础设施不是正确的选择。

什么时候不需要云原生基础设施

只有知道限制时，理解系统的好处才是重要的。也就是说，知道哪些限制可以满足您的需求通常可能更多是决定性因素而非利益。

记住需求随时间变化也很重要。现在关键的功能可能不会在未来。同样，如果以下情况现在不会使这种设施变得理想，那么您可以控制许多这些情况，并且可以改变采用它们。

技术限制

就像应用程序一样，在基础架构中，最简单的项目是技术性的。如果您知道什么时候应该采用基于技术优势的云原生基础设施，那么您可以改变这些特征，以找出何时不应该采用云原生基础设施。

第一个限制是没有云原生应用程序。正如在讨论中

第1章，如果您的应用程序需要人工交互，无论是调度，重新启动还是搜索日志，云原生基础设施都没有多大好处。

即使有一个可以动态调度的应用程序，也不会使其成为本地云。如果您的应用程序在Kubernetes上运行，但仍需要人员设置监控，日志收集或负载平衡器，则它不是云原生。只因为你有Kubernetes并不意味着你已经完成。

如果你有一个管弦乐队，重要的是看看它是如何运行的。您是否需要下订单，创建票据或发送电子邮件以获取服务器？

这些是您没有自助服务基础架构的指标，这是云计算的一项要求。

在云中，您只需提供帐单信息并调用API。即使您在内部运行服务器，您也应该有一个可以构建IaaS的团队，然后将云原生基础设施分层布局。

如果您要在自己的数据中心中构建云环境，图2-1显示了您的基础架构组件适合的示例。所有原始组件（例如，计算机，存储，网络）都应该可以从自助式IaaS API中获得。

图2-1. 云原生基础设施的示例图层

在公共云中，您拥有IaaS和托管服务，但这并不意味着您的业务已准备好迎接公有云的启用。

当您构建运行应用程序的平台时，了解您正在进行的操作非常重要。最初的开发只是构建和维护平台所需花费的一小部分，特别是对业务至关重要的平台。

维护通常会消耗大约40％到80％（平均60％）的软件成本。因此，这可能是最重要的生命周期阶段

发现业务需求和建立开发所需的技能可能对于一个小团队来说太过分了。一旦你掌握了开发所需平台的技能，你仍然需要投入时间来改进和维护系统。这需要比初始开发更长的时间。

为企业提供绝对最佳的环境是公共云提供商的产品。如果你不能或者不愿意让你的平台成为你的业务的一个区别，那么你不应该自己创建一个平台。

请记住，你不必自己构建一切。您可以使用可以组装到所需平台的服务或产品。

可靠性仍然是您基础架构的关键特性。如果您还没有准备好放弃对基础设施堆栈的更低级别的控制，并且仍然通过接受故障来制造可靠的产品，那么云原生基础设施并不是正确的选择。

也有可能超出你的控制的限制。非技术限制同样重要，难以解决。

业务限制

如果现有流程不支持更改基础架构，则需要首先克服该障碍。幸运的是，你不必一个人做。

本书希望有助于向需要说服力的人清楚地解释好处和流程。还有许多案例研究和公司分享他们采用这些做法的经验。本书附录C中将提供一个案例研究，但是您可以为您的企业找到相关示例并与同行和管理层分享。

如果企业还没有实验的途径和支持尝试新事物的文化（以及伴随失败而来的后果），那么改变流程可能是不可能的。在这种情况下，您的选择是达到必须改变事物的临界点，或者说服管理层认为改变是必要的。

从外部看，企业是否准备采用云原生设施是不可能的。一些明确指出公司未准备好包括的过程：

• 需要人工干预的资源请求
• 定期安排需要人工操作的维护窗口
• 手动库存跟踪和资源分配
• 电子表格清单

如果除了负责服务的团队以外的其他人员参与进程以调度，部署，升级或监视服务，则可能需要在迁移到云原生基础设施之前或迁移期间解决这些流程。

有时也有业务无法控制的过程，例如行业法规。可悲的是，这些变化甚至比内部流程更难和更慢。

如果行业法规限制了发展的速度或敏捷性，我们就没有任何建议，除非你能做到。如果法规不允许在公共云中运行，请尽量使用技术来运行内部部署。管理层将需要为任何管理机构制定的法规制定一个案例。

云原生基础设施还有另一个非技术障碍。在一些公司中，有一种不使用第三方服务的文化

如果您的公司不愿意或通过无法使用的流程来使用第三方托管服务，则可能不适合采用云原生基础设施。我们将在附录B中更详细地讨论何时使用托管服务。

结论

要成功，单靠计划是不够的。一个人也必须即兴创作

——艾萨克·阿西莫夫

在本章中，我们讨论了何时采用云原生基础设施的注意事项。有许多领域要记住，每种情况都是独一无二的。希望这些指导原则中的一部分可以帮助您发现进行变更的适当时机。

如果您的公司已经采用了一些云原生实践，这些问题可以帮助确定可以采用这种架构的其他领域。当你应该采用这些权衡和利益是正确的解决方案，以及如何开始时，了解这一点非常重要。

如果您尚未将云原生实践应用于您的工作，则没有捷径。企业和员工将需要共同决定这是正确的解决方案，并共同取得进展。没有人独自成功。