5 个多云部署挑战（以及如何解决它们）

如今，你几乎读到任何科技博客，都能找到赞美多云架构的文章。 这是有充分理由的：多云提供了一系列好处，从节省成本到提高可靠性等等。

但是多云策略也带来了一些挑战，尤其是在应用部署方面。 在加入多云潮流之前，重要的是评估多云架构将如何影响您的部署策略，并确保您已准备好解决这些痛点。

本文介绍了多云环境中常见的部署挑战以及缓解这些挑战的技巧。

挑战1： 配置

当您拥有多个云时，您需要先配置多个环境，然后才能向其中部署应用。

在某种程度上，基础设施即代码（或 IaC）工具可以帮助简化这一流程。 您可以使用一个 IaC 模板以相同的方式配置多个云。

然而，IaC 对解决这一挑战的帮助是有限的。 如果您使用特定云供应商提供的 IaC 工具，它可能与其他云的兼容性很差甚至完全不兼容。 因此，您可能需要为每个云使用不同的 IaC 工具，这在一定程度上违背了 IaC 的初衷。即使您有一个可以与所有云配合使用的 IaC 工具，您也可能需要手动调整配置，因为您无法为每个云使用完全相同的模板。

在 IaC 无法解决您的多云配置挑战的情况下，更好的方法是使用完全从底层云中抽象工作负载的解决方案。 这样，您就不必担心单独配置每个云。

挑战2： application部署

与配置一样，如果您将实例部署到多个云，则实际部署应用程序的过程可能会很复杂。 每个云都需要不同的部署过程。

您可以尝试使用第三方发布自动化工具将应用实例自动部署到您使用的每个云。 这将简化流程，但与 IaC 工具一样，您可能需要进行一些手动更改，因为您无法使用完全相同的配置来部署到每个云。

再次，从托管工作负载的云中抽象出工作负载并提供跨多个云的完全一致的部署流程的解决方案比发布自动化工具更能缓解多云架构部署的挑战。

挑战3： 负载均衡

如果您在多个云上托管应用的多个实例，如何确保每个实例都处理理想的流量？ 如何避免将过多的流量导向一个云，而另一个云处于空闲状态？ 您如何知道何时需要添加或删除实例？

这些都是重要的问题。 如果您无法在多云架构中正确平衡负载，您可能会遭受性能问题并浪费金钱 - 这与多云架构应该提供的效果完全相反。

不幸的是，在多云环境中这些问题很难回答。 由于云供应商本身不提供可与其他提供商的云兼容的负载均衡解决方案，因此您需要单独、仔细地监控每个云，以确定如何平衡不同云和应用实例之间的流量。

通过使用可部署到多个云的通用网络和监控平台以及可自动连接和平衡负载的application交付网络，您可以避免这些挑战并确保您真正享受多云策略应该提供的好处。

挑战4： 出口

云提供商很贪婪。 他们希望您的工作负载和数据永远留在他们的云中。 如果您将数据移出（换句话说，执行数据传出），他们会向您收取大量费用。

这意味着，需要将数据频繁地从一个云移动到另一个云的多云架构可能会因传出费用而大幅增加您的云计算费用。

从基本层面上讲，您可以通过设计多云架构来降低这种风险，使得数据不需要在不同的云之间频繁移动。 例如，避免出现这样的情况：您的应用位于一个云中，但它需要提取的数据却托管在另一个云中，因为这需要大量的云间数据移动。

另一个有用的策略是使用应用交付网络来存储一些更活跃使用的数据。 除了提供一系列其他安全和性能优势之外，应用交付网络还可以减少一个云中的应用需要将数据移入或移出另一个云的频率。 相反，他们可以使用应用交付网络内的数据存储。

挑战5： 监控

保持对单一云的可见性已经够难的了。 当您拥有多个云时，监控所有正在运行的服务和配置将成为一项真正艰巨的任务。

旨在支持多云环境的应用性能监控 (APM) 工具可以在一定程度上帮助完成这项任务。 但它们只能带你走这么远。 当您的某个应用似乎出现问题时，它们会向您发出警报，但您需要确定哪个云或哪些云导致了问题，然后使用与每个受影响的云相关的工具来解决问题。

或者，考虑从底层云中抽象出您的工作负载，以便您可以只监控一个“逻辑云”和一组部署工具。 这种方法减少了您需要处理的移动部件的数量，以保持对您的应用和基础设施的可见性。

结论

在多云架构中管理应用部署本质上很困难。 虽然各种类型的自动化工具可以帮助简化配置、部署和监控等任务，但它们并不能完全消除手动操作的需要。

不要尝试使用各种工具来解决多云部署挑战，更好的方法是改变设计多云架构本身的方式。 通过采用VoltMesh和VoltConsole等解决方案，您可以以一致、集中的方式跨多个云部署和连接应用，同时还可以利用 Volterra 的全球应用交付网络来优化工作负载性能和安全性。