加速云：过渡到云

本文是Ampere Computing“加速云计算”系列文章的第三部分。您可以在这里阅读第一部分和第二部分。

正如我们在本系列的第二部分中所展示的，将应用程序重新部署到云原生计算平台通常是一个相对简单的过程。例如，Momento将其重新部署体验描述为“比我们预期的工作量少得多。Pelikan在T2A（谷歌基于Ampere的云原生平台）上立即运行，我们使用现有的调整流程对其进行了优化。”

当然，应用程序可能很复杂，包含许多组件和依赖项。复杂性越高，可能出现的问题就越多。从这个角度来看，Momento将Pelikan Cache重新部署到Ampere云原生处理器的经验提供了许多见解。该公司已经建立了一个复杂的架构，他们希望尽可能地自动化一切。重新部署过程为他们提供了实现这一目标的机会。

适合云原生处理的应用程序

首先要考虑的是确定您的应用程序如何从在云原生计算平台上的重新部署中受益。大多数云应用程序都非常适合云原生处理。为了了解哪些应用程序可以从云原生方法中获益最多，我们仔细研究了Ampere云原生处理器架构。

为了实现更高的处理效率和更低的功耗，Ampere采用了不同的方法来设计我们的核心——我们专注于云原生应用程序在性能、功耗和功能方面的实际计算需求，并避免集成为了非云用例而添加的传统处理器功能。例如，当应用程序必须处理大量3D图形或特定类型的高性能计算处理时，可扩展矢量扩展非常有用，但会带来功耗和核心密度方面的权衡。对于需要SVE的应用程序（例如云中的Android游戏），云服务提供商可以选择将Ampere处理器与GPU配对以加速3D性能。

对于云原生工作负载，Ampere核心的功耗降低和核心密度增加意味着应用程序以更高的性能运行，同时功耗更低，散热更少。简而言之，对于大多数应用程序而言，云原生计算平台可能会提供卓越的性能、更高的能效和更高的计算密度，同时降低运营成本。

Ampere擅长的是具有许多独立组件的基于微服务的应用程序。此类应用程序可以从更多内核的可用性中受益匪浅，Ampere在一个单芯片上提供128个内核的高核心密度，在一个带有两个插槽的1U机箱中最多可提供256个内核。

事实上，当您水平扩展（即跨许多实例进行负载平衡）时，您就可以真正看到Ampere的优势。因为Ampere与负载线性扩展，所以您添加的每个内核都会带来直接的好处。将其与x86架构进行比较，在x86架构中，每个新增内核的好处会迅速减少（参见图1）。

图1：由于Ampere与负载线性扩展，因此添加的每个内核都会带来直接的好处。将其与x86架构进行比较，在x86架构中，每个新增内核的好处会迅速减少。

专有依赖项

重新部署应用程序面临的挑战之一是识别专有依赖项。在软件供应链中任何使用二进制文件或专用基于x86的软件包的地方都需要引起注意。可以通过搜索文件名中包含“x86”的代码来找到许多这些依赖项。替换过程通常很容易完成：用适当的基于Arm ISA的版本替换x86软件包，或者如果您有权访问源代码，则为Ampere云原生平台重新编译可用的软件包。

一些依赖项会带来性能问题，但不会带来功能问题。考虑一个使用针对x86平台优化的代码的机器学习框架。该框架仍然可以在云原生平台上运行，只是效率不如在基于x86的平台上运行。解决方法很简单：识别针对Arm ISA优化的框架的等效版本，例如Ampere AI中包含的那些版本。最后，还有一些生态系统依赖项。您的应用程序依赖的一些商业软件，例如Oracle数据库，可能无法作为基于Arm ISA的版本提供。如果是这种情况，在提供此类版本之前，这可能还不是适合重新部署的应用程序。针对此类依赖项的解决方法，例如将它们替换为云原生友好的替代方案，可能是可能的，但这可能需要对您的应用程序进行重大更改。

一些依赖项位于应用程序代码之外，例如脚本（即Ansible中的playbook、Chef中的Recipes等等）。如果您的脚本假设特定的软件包名称或架构，则在部署到云原生计算机平台时可能需要更改它们。大多数这样的更改都很简单，对脚本进行详细审查将揭示大多数此类问题。注意调整开发团队多年来可能做出的命名假设。

现实情况是，这些问题通常很容易处理。您只需要彻底识别并处理它们即可。但是，在评估解决此类依赖项的成本之前，有必要考虑技术债务的概念。

技术债务

在福布斯文章《技术债务：数字化转型难以衡量的障碍》中，技术债务被定义为，“系统相对快速的修复的积累，或沉重但方向错误的投资，从长远来看可能是资金的流失。”快速的修复可以使系统继续运行，但最终积累的技术债务会高到无法忽视的地步。随着时间的推移，技术债务会增加软件系统中变更的成本，就像咖啡机中的水垢积聚最终会降低其性能一样。

例如，当Momento将Pelikan Cache重新部署到Ampere云原生处理器时，他们已经安装了依赖于15年前的开源代码的日志记录和监控代码。代码有效，因此从未更新。但是，随着工具随时间的推移而发生变化，需要重新编译代码。需要进行一定的工作来保持向后兼容性，从而创建对旧代码的依赖性。多年来，所有这些依赖项都会累积起来。在某个时候，当维护这些依赖项变得过于复杂和代价高昂时，您将不得不过渡到新的代码。技术债务可以说会被收回。

在将应用程序重新部署到云原生计算平台时，了解您当前的技术债务以及它如何驱动您的决策非常重要。多年来维护和适应遗留代码会累积技术债务，这使得重新部署更加复杂。但是，这本身并不是重新部署的成本。即使您决定不重新部署到另一个平台，总有一天您将不得不弥补所有这些快速的修复和其他推迟更新代码的决定。您只是还没有这样做。

技术债务有多真实？根据麦肯锡的一项研究（参见福布斯文章），该研究中30%的首席信息官估计，他们用于新产品的技术预算中超过20%实际上被用于解决与技术债务相关的问题。

重新部署是一个很好的机会，可以解决应用程序多年来积累的一些技术债务。想象一下，收回贵公司用于解决技术债务的“20%”中的一部分。虽然这可能会增加重新部署过程的时间，但处理技术债务具有从长远来看简化管理和维护代码的复杂性的好处。例如，您可以通过将代码迁移到当前的开发环境来“重置”许多依赖项，而不是继续依赖它们。这是一项投资，可以通过简化您的开发周期来立即带来回报。

Plesk的产品经理Anton Akhtyamov描述了他重新部署的经验。“移植后，我们遇到了一些限制。Plesk是一个大型平台，可以安装许多附加模块/扩展。有些不受Arm支持，例如Dr. Web和卡巴斯基杀毒软件。某些扩展也不可用。但是，我们的大多数扩展已经使用供应商为Arm重建的软件包得到支持。我们也有自己的后端代码（主要是C ），但由于我们之前已经对其进行了调整以支持x86-64，因此我们只是在没有任何关键问题的情况下重建了我们的软件包。”

有关将应用程序重新部署到云原生平台的更多实际示例，请参阅将Takua移植到Arm和Ampere Altra上的OpenMandriva。

在本系列的第四部分中，我们将深入探讨将应用程序重新部署到云原生计算平台时可以期待的结果。

以上是加速云：过渡到云的详细内容。更多信息请关注PHP中文网其他相关文章！