CTO头痛：云端迁移的主要难题（以及解决方案）

来宾帖子最初由Elastisys的高级云架构师和分支经理Lars Larsson发表在Elastisys的博客上

所有使用云服务的公司都这样做是有原因的。但是那些原因可能会改变。无论是出于对多云战略，最小化支出，立法或法规要求的推动，还是仅仅是为了更接近最终用户，许多组织都发现自己已从一个云迁移到另一个云。非平凡的应用程序从云到云的迁移包含许多未知的未知数。这会给CTO带来压力和不确定性。为了根据多年的经验积累经验，我们请Elastisys的高级云架构师Lars Larsson列出其中一些问题。

云提供商提供了广泛的服务，每种服务都有自己的相关费用。在进行计算时，请确保完全了解情况。

提供商倾向于通过完善的服务锁定客户。这些可能使迁移更加困难。

明确清点您的应用程序需要的托管服务的功能。这些可能与其他云提供商所提供的不匹配。

考虑所有这些清单，以计算任何云到云迁移的总拥有成本。

使用云原生技术将您的应用程序和组织与特定云提供商所提供的服务脱钩。这使将来的迁移更加容易。

大多数公司都被这一令他们感到惊讶的云法案所打击。一些服务或功能的成本远远超过了最初的预期。

您是否正在考虑从云到云的迁移以降低运营成本？如果是这样，请仔细研究每个云层中的各种成本。由于每种服务都有不同的成本模型，因此很难进行准确比较。您确实需要深入了解它。

计算和存储成本通常很容易比较，因为这是最明显的两者。但是其他服务呢？您在例如日志处理或监视上花费了多少？优质的服务（例如AWS CloudWatch）需要付出一定的代价，尤其是如果您也将其用于日志处理（AWS CloudWatch Logs）。您是否大量使用托管数据库服务？排队还是发布/订阅服务？

这次避免做作业，避免一次让意外的云账单打在脸上的感觉。毕竟，从经验中您会变得更加明智。

进出云端的网络传输也可能相差很大。三大提供商将免费为您提供传入网络流量，但向您收取传出流量费用。较小的区域性云提供商通常会具有更高的计算和存储成本，但不会向您收取网络流量费用。或在免费套餐中包含更多数量的商品。

压倒？我得到它。乍一看肯定是这样！但这不是必须的。我的技巧是查看您过去的一些详细的帐单，并将这些费用映射到您的新云提供商选项。

关键要点：深入考虑当前云计费的各个方面。找到产品之间的差异，并做出更明智的决定。

告诉我，您是否采用Kubernetes来减少对云提供商的依赖？减少供应商锁定？现在，您是否发现自己仍处于锁定状态，但又处于不同的水平，是否感到惊讶？

我看到的是，大多数组织将确保它们具有高度可移植的应用程序定义。通过依赖Kubernetes，应用程序定义可跨云提供商使用。

但是，我还看到的是，如果您使用托管的Kubernetes服务，则用户和权限处理可能并不与Kubernetes基于角色的访问控制（RBAC）功能相关，而与特定于云的产品相关。像AWS Identity and Access Management（IAM）。优质的服务，但将您与AWS平台联系在一起。

如果由云供应商自己提供全面管理的Kubernetes服务，则可以提供高度集成的体验。集成的代价是，迁移到另一个云提供商变得更加困难。

作为一个社区，我们已尝试解决此问题。但是作为工程师社区，这些修复是技术性的。 Kubernetes规定了某些组件或方面的标准。网络必须根据容器网络接口（CNI）标准进行工作。根据容器存储接口（CSI）进行存储。等等。伟大的。但是，业务人员已经采用了更为巧妙的方法将您锁定在平台上。这意味着其他不太明显的方面更难从一个云自由迁移到另一个云。

那有什么选择呢？您必须自己管理Kubernetes吗？不，当然不是。但是，调查与特定云提供商无关的托管Kubernetes产品可能有道理，以减少供应商锁定的风险。当然，不必自己承担日常操作的任务。

关键要点：研究由于不兼容的集成而使云提供商使迁移更加困难的方式。选择不与任何特定云提供商绑定的第三方供应商，并在需要时可以在其他云提供商之上提供他们的服务。

我交谈过的几乎所有组织都在说同样的话。他们之所以选择云计算，是因为他们希望以“服务即服务”的方式获得基础架构或平台功能。那是整个云的重点，不是吗？

因此，当然，所有云提供商都将提供某些服务。它曾经只是基础架构即服务（虚拟机，网络和存储），但我们也开始将例如对象存储和排队服务视为理所当然。许多此类服务将声称提供“ S3兼容API”或类似的东西。这是一个很好的起点！但是要当心，因为这种兼容性声明的真正含义是什么？

例如，AWS S3直到2020年12月才最终保持一致。自宣布以来，它是写后读一致的（强一致性）。 “ S3兼容”服务将具有哪种一致性级别？旧的吗？还是新的？而且，您的应用程序中是否有某些方面依赖于答案之一？你会立即知道吗？

顺便说一句，如果您不这样做，那么您的公司就很棒。讨论一致性保证时，大多数人的眼睛都看不到。但是话又说回来，您不想被错误的假设所导致的错误所咬，因此必须有人醒着才能弄清楚这些问题。希望不要超过午夜！

准备使用另一个令人兴奋的示例吗？排队服务（例如AWS SQS）提供某些交付保证。 SQS标准队列提供“至少一次”保证。这意味着一条消息可以多次传递到您的应用程序，并且必须具有处理重复项的逻辑。没有为此准备的应用程序将开始显示奇怪的行为。特别是在重负载下，因为那是多次交付的风险更高的时候。这是因为高负载意味着排队服务的时间更少。 （请注意，尽管SQS提供的FIFO队列具有``恰好一次''的处理保证，但并不意味着恰好是一次交付。）因此，对于以RabbitMQ的``最多一次''交付保证为前提的编码应用程序感到困惑！

讨论一致性保证时，大多数人看不见。阅读整篇文章CTO头痛：前5位云到云迁移的麻烦。有关更多https://t.co/exLGZu5SZG

-elastisys（@elastisys）2021年2月8日

我在这里要指出的是，您必须清点所用的所有云服务，以及其中的哪些功能是应用程序按预期方式工作的关键。因为您的用例很重要。

云提供商提供的服务需要进行一定的权衡，以确保其服务的可扩展性和可用性。从单个客户和应用程序的角度来看，理想的折衷选择可能有所不同。如果您使用RabbitMQ之类的软件，则可以根据您的用例和要求对其进行完美配置。不是云提供商。有些公司以与云无关的方式提供托管服务。特别是在Kubernetes上，值得您考虑。

关键要点：清楚列出您所使用的所有云服务，以及每个用例所需的功能。为了使从云到云的迁移更加容易，请从不依赖于任何特定提供程序的软件开始。

行业智慧和经验法则表示，约70％的软件成本用于维护。没有发展。只是让事情按预期运行。您如何解决？我的看法是尽可能地依赖智能工具和自动化。您的员工在死记硬背任务上工作的次数越少越好。他们所做的一切都是一个过程。因此，让我们谈谈这些过程。

运行您的关键任务云应用程序？一堆过程。而且，大多数（如果不是全部）都受工具支持。持续集成和部署，监视，通知和警报。这些是您的运营人员用来分析和优化应用程序部署的工具。

AWS CloudWatch等出色的工具可提供有关监视，日志记录（CloudWatch Logs）和容器化工作负载（CloudWatch Container Insights）的洞察力。您的团队可能取决于他们。但是它们特定于特定的云供应商。

如果您喜欢我多年来与之交谈过的许多组织，那么您可能已经深入研究了它们。现在，您的流程依赖于特定于云提供商的服务。感到熟悉吗？如果是这样，您可能会很难将所有这些流程迁移到新工具上。

因此，还需要对您使用的所有服务进行深入的清点。这次，他们发挥了支持您的运营流程的作用。一旦有了该列表，就必须决定从那里去哪里。

我的建议是选择一个面向未来的解决方案。那就是使用可在所有云供应商中使用的工具。不将应用程序日志存储在托管的Elasticsearch环境中，而不是通过云供应商存储。使用Prometheus和Grafana监视您的应用程序，而不是使用云供应商提供的软件。云原生环境具有大量可观察性的工具，可以帮助您以一种在大型云，小型区域云甚至在公司地下室的数据中心中同样有效的方式解决此问题。由于解决的问题相同，为什么工具也不会一样？

关键要点：记下支持组织过程的所有工具和服务。接下来，选择适用于所选云环境的类似工具。

如果您对成本的巨大差异非常谨慎，则可能会感觉到正在处理总拥有成本的问题。即，所有这些库存将需要多少成本来建立？确切调查您的应用程序需要哪些功能会花费什么？

就像对任何足够好的问题的答案一样，答案从“取决于”开始。在这种情况下，主要取决于开发团队的规模和应用程序的复杂性。只有您可以回答这些。

但是请不要忘记，迁移也有技术成本来源。一次性成本，例如数据迁移：从一个云迁移到另一个云将需要多少数据？我们是在谈论千兆字节，terra还是PB？

如果您需要围绕一套新工具来支持您的运营以支持您的流程，那么是否会涉及培训？定制软件开发？在基于Prometheus和Grafana的全新可观察性解决方案中创建新的数据导出器或仪表板？

关键要点：与任何更改相关的成本。到目前为止，您的库存和分析可能会显示出可能发生这些成本的地方。但是要当心那些不太明显的东西。它们增加了总拥有成本和运营云部署的总成本。

云到云的迁移可能是一项艰巨的任务。而且它也可能有点吓人，因为它充满了未知的未知数。我的建议是首先面对那有点可怕的情况。建立库存。对您的应用程序需要哪些服务和功能有一个清晰的了解。并支持您围绕操作和维护应用程序的组织过程。

有了这样的清单，您就可以开始做出明智的决定。消息灵通的人。睁开眼睛，而不是闭上眼睛，总是有助于您进行这种战略行动。

最重要的建议是什么？如果您的新云家庭需要更改，请考虑使用不依赖于特定云提供商的工具。这样，您无需担心以后是否需要再次将云迁移到云。您拥有丰富的云原生工具来支持您。借助基于此类工具的工作流程，您可以在任何托管设置中进行现代化的云部署。你有这个。

通过在LinkedIn上关注他或前往Elastisys博客来阅读Lars的更多内容，内容涉及高级云主题和工程HOWTO。

Elastisys是CNCF银级会员，并且是开源CNCF认证的Kubernetes分发兼容Kubernetes的创建者。