当企业将业务迁移到云平台，然后确定有些负载无法在云平台工作时会发生什么?答案就是云遣返，这种策略在最近几年变得越来越流行，有80%的公司报告计划遣返至少他们当前在公共云中托管的部分工作负载。
乍一看，人们可能会认为类似这样的统计数据，以作为证明将大量负载转移回内部部署数据中心的证据。然而现实是，云遣返还更加复杂和细微。在许多情况下，这与重新采用公司在采用公共云之前使用的内部部署配置无关;它更多的是利用新的混合云机会或找到更好的方式将内部部署工作负载与公共云服务集成。
以下了解云遣返意味着什么，为什么云遣返已经成为一种流行趋势，以及如何制定最有效的云遣返策略——这通常需要的不仅仅是在迁移到云平台之前重建所依赖的内部基础设施。
什么是云遣返?
简而言之，云遣返是将当前在公共云中运行的应用程序或数据移至公共云以外的基础设施的过程。
例如，企业可能将虚拟机托管在AmazonEC2或Azure虚拟机之类的服务上，然后又迁移回了内部部署数据中心。或者，企业可以将运行在公共云中的SaaS应用替换为托管在私有云或混合云中的一个。
由于多种原因，企业可能选择云遣返。从确定云计算成本实际上比预期的成本高昂到确定云计算并非总是满足某些需求(例如备份和恢复，其中基于云的计算备份可能需要更长的时间才能还原到在线备份)。
遣返如何改变云计算
关于云遣返的简单假设是，这意味着更多的组织将转向内部部署模型，云架构因此变得不那么重要。
但是现实更加复杂。尽管对于某些组织而言，云遣返意味着仅将工作负载转换回内部部署模型，但对于另一些组织，则需要迁移到更复杂的基于云计算的架构类型，而不是完全放弃云计算。
例如，考虑以下可用于遣返云工作负载的方式：
将以前托管在传统公共云中的SaaS应用程序迁移到边缘计算模型，这个应用程序本身保留在公共云中，但在内部部署服务器中进行数据处理以提高性能。在这种情况下，只返回工作负载的一个方面。
扩展了备份和恢复操作，其备份数据存储曾经仅依赖于公共云，因此可以将备份保留在云平台和内部部署设施中，从而为组织提供更多的恢复选项。在这个示例中，尽管原本仅在公共云中运行的工作负载现在也消耗了内部部署资源，但从技术上讲，云遣返甚至不会发生。
为了满足合规性需求，企业利用下一代混合云框架(如AzureStack或AWSOutposts)将以前在公共云中运行的工作负载移动到内部部署服务器。工作负载继续依靠公共云服务，但是托管在内部部署进行，从而简化了合规性挑战。
在这些示例中，云计算架构最终变得比发生云遣返归还之前更复杂。曾经只涉及公共云的架构会演变为混合或边缘模型。
云遣返的优秀实践
如果企业对公共云策略不满意，并考虑遣返部分工作负载，需要牢记以下几点提示：
遣返不是撤回：如上所述，在很多情况下，云遣返并不是要回到采用公共云之前使用的任何架构模型。相反，它是采用更复杂的架构来提高性能、成本或其他因素的一种方法。
确保企业可以处理复杂性：由于云遣返往往会通过集成公共云和内部部署资源而使其架构变得更加复杂，因此确保额外的管理负担是值得的。在存储或虚拟机方面节省一些成本是否值得同时监视工作负载的基于云计算和内部部署的组件?也许可以，但是在赶上遣返潮流之前先评估一下这些考虑因素。
使工作负载保持可迁移性：企业永远不知道何时可能需要再次更改架构以实现新目标或利用新机会。因此，在执行在执行云遣返时，需要努力使工作负载保持可迁移性，以便将来在需要时可以轻松地再次迁移。
考虑公共云的未来：企业在决定以导致更多复杂性的方式遣返其工作负载之前，需要认真考虑是否仅将它们留在公共云中并不是最佳的长期策略。这里特别重要的考虑因素是，随着时间的推移，公共云服务变得越来越便宜，并且功能越来越强大。因此，即使认为公共云并不是当今针对给定工作负载的理想解决方案，但将来可能会变得更好。企业不想遇到遣返的麻烦，只是发现在未来的一两年内，最好还是坚持使用原始的公共云架构。
结论
随着组织重新评估其云计算战略，大多数资源很可能会被遣返。但是，与其将云遣送视为仅仅是将时间推迟到云计算前时代的一种方式，还不如将其视为构建更强大的架构的一个机会。
