非云端部署的趋势是确实存在的，但并非无法逆转。

　　要做出将工作负载保留于内部部署或将其移动到云端部署的决定是很复杂的，需要深入了解您的数据中心基础设施和应用程序设计。如果盲目做出这一决定，可能造成性能降低或产生额外的费用成本。它也可能迫使您将工作负载从公有云迁移回公司内部——这就是被称为“非云端部署”的趋势。

　　在过去几年中，容器和微服务器趋势促使IT部门将应用程序分解成较小的组件，并帮助基础设施更具弹性。传统上，应用程序是一组设置在机器内部的组件集合，但更为现代的基础设施中的应用程序位于一组机器中。这将在系统内创建出新的流量模式以及依赖关系，并展示出决定应用程序或工作负载应该在何处运行的不同因素。

　　IT容易忽视这些新的因素，并且冲动地将负载迁移到云端，这凸显出可扩展性、高可用性和更多的第一手的方法，但云端部署并不是一揽子的解决方案。因为许多公司发现，公有云并非最适合每一项工作负载，所以出现了逆向迁移或者“非云端部署”的这一趋势。根据Datalink的调查显示，有近40%的具有公有云体验的组织已将系统从云端迁移到内部。

　　“非云端部署”的出现是有着诸多原因的，主要是为了节省资金或获得更高的管控水平，而这通常是由于缺乏了解所引起的。Datalink调查中只有31%的受访者对应用进行了评估，以确定应用程序是否属于在云端部署的优良候选。在您最初的云端部署与内部部署辩论之中，可提出以下五个问题，以防止反向迁移的麻烦。

　　企业在法律和法规要求方面有多严格?

　　必须考虑安全性和合规性，以确定应用程序或工作负载是否属于公有云还是在内部。工作量可能与某些法律和监管要求相关——例如，医疗保健公司的数据必须符合“健康保险可移植性和责任法案(Health Insurance Portability and Accountability Act)”，同样金融服务公司也必须严格地遵守法规。

　　IDC分析师马修·伊斯特伍德(Matthew Eastwood)表示：“在一家全球化的公司之中，在数据需求方面存在很多限制，如果您在欧洲工作，欧盟对此具有严格和明确的规定。他说，IT团队应该参加研讨会并与内部法律团队进行协调，以了解其组织的具体法律和监管要求。

　　451 Research的分析师杰弗里•菲达卡罗(Jeffrey Fidacaro)说，如果工作负载涉及到敏感的客户数据，那么在法律和监管方面的要求也是如此。将敏感的消费者数据移动到云端需要对云提供商的服务级别协议进行深入评估，因为许多合同细微差别可能会导致诸多并发问题。并不是每个人都会发现内部部署设置本身比云更加安全。一家金融服务公司的云运营协调员巴亚尔容(Pier-Luc Baillargeon)认为，对一些在内部部署的工作负载进行监管要求，但是如果公司的安全团队推荐该选项，则可以将这些工作负载移至企业内部。

　　“也许这是个意识层面的问题，人们还没有准备好说，外部设施与内部设施一样可靠，因此这只是一项循序渐进的事情。”他说。

　　另一些人认为，将敏感数据移动到云端感觉有风险只是缺乏对如何保护云端的工作负载的了解，而不能说是平台本身的根本缺陷。

　　“如果您查阅主要云提供商们的产品，您就可以，例如可以提供严格的网络和安全控制。您可以在存储数据时进行数据加密”，VMware的工程架构师斯科特·洛维(Scott Lowe)表示。“因此，只要设置正确，公有云中的安全性水平(与企业内部)大致相当。”

　　应用程序使用模式是稳定还是起伏?

　　工作负载的差异性也是选择公有云还是企业内部决策讨论的重要一环。确定应用程序使用模式，例如用户访问应用程序的频率以及该访问是稳定和可预测的，还是在特定时刻来得颇为剧烈。

　　Eastwood认为，例如移动式前端应用程序可能在企业内部难以管理，因为在任何特定的时间的负载结构实在是难以预测。

　　他说：“如果你是一位零售商，而且正要筹备‘黑色星期五’，那么系统在星期五的负载可能是平时星期五的五倍之多。对于每年只会遇到一次的情况来说，很难提前规划和建设。”

　　云端的可扩展能力以及自助服务性质可适应这些不可预测的应用程序使用模式。借助内置自动化功能，用户可以点击几个按钮，并在几分钟内启动某一实例，以快速响应工作负载的需求。传统流程要求开发人员向IT提供一项额外的服务器或虚拟机的正式请求，以证明CPU和内存资源的合法性——然后等待对方划拨资源。

　　不仅聚焦应用程序使用外，企业还必须追踪数据增长模式。通常情况下，组织每年的数据增长率将达到50%，但是如果您突然看到数据增长了四倍，就一定会产生的经济方面的影响，并应重新考虑您的基础设施以适应这一需求。

　　通常需要频繁更改的面向客户的应用程序也可能更适合云端。例如，IT团队每年只使用两次的应用程序应该保留在内部运行。但是对于需要频繁更新的应用程序，例如错误修复或新功能，云端部署可能是一个更好的选择。

　　Baillargeon说：“对于[某些]工作负载而言，我们希望尽可能快地实施变更。到目前为止，唯一的办法就是云端部署方式。”

　　云端部署会造成网络延迟问题吗?

　　如果不了解应用程序的通信模式，组织可能会选择不恰当的位置对其进行托管，并造成网络延迟问题。

　　Lowe说，与内部部署工作负载进行大量通信的云端工作负载，在公有云和企业数据中心之间产生更多的通信流量，这需要架构改进能确保充分的连通性。

　　IT团队必须评估复杂的网络架构情况。也许数据中心的南北方向的流量会产生大量的东西方向的请求。或者，您可能围绕需要频繁相互交流的应用程序构建了一系列微服务。

　　Lowe认为：“如果您把较大集群的一部分正在进行沟通的组件组成一个应用程序，并将其固定到公有云中，那么这样就完成了两件事情。您已经引入了部分延迟，您可能已经引入了具有10或15个不同的服务的点，需要与公有云中的一个或两个服务进行通信，您可能有相当大的流量需要处理—或许真正超过你所真正理解的部分。”

　　如果您决定将应用程序迁移到公有云端，请仔细选择其所属的区域以避免网络延迟问题。了解哪些用户将连接到该区域、从哪里连接，您需要多少带宽以及涉及哪些其他组件或工作负载。

　　Fidacaro表示，为云端工作负载创建一系列潜在的网络延迟问题，并确定多少量级的延迟是可以忍受的。

　　“如果它的容量很大，并且还需要大量的带宽，将通道中的所有数据运行到集中的公有云中是否有意义?”，他说。

　　如果没有意义，企业可以将计算能力和分析转移到边缘。使用边缘分析来压缩该数据，只传递您需要在网络间所保留的内容，并将其余部分推送到云端。

　　老旧设备或大型机应用程序是否值得迁移?

　　部分应用程序因为财务或技术原因而面临的迁移风险太大，但如何识别这些应用程序? 一些传统工作负载，例如在Unix机器或大型机应用程序上运行的工作负载通常属于此种类别。

　　“大型机工作负载通常是战略性的，并不一定容易卸载和迁移，”Eastwood说。“当您开始考虑风险以将它们留在的原有的位置时，就更加安全也更为经济。”

　　他认为，停机时间是大型机应用程序所面临的最大风险，特别是如果它们是高优先级并且对业务产生直接的影响的时候。这些包括直接连接到基本工作流的金融应用程序或移动端应用软件(apps)。

　　然而，Fidacaro说，这不仅仅特别是大型机应用程序，造成了这种风险。技术障碍可能阻碍将遗留应用程序移植到云端的虚拟化实例。如果它不是一个虚拟化或云端就绪的应用程序，组织往往会花费财务成本来实现现代化，以便能够有效地在云端运行。

　　他说：“当您考虑到这些环境情况时，您不仅必须将其移植到云端运行，还可能需要与其他应用程序进行交易的动作。”

　　Lowe说，不需要全局可见性的传统应用程序是相当静态的，不需要根据需要重新定位可能不值得卸载。大量定制和内部使用的应用程序(如组织的库存系统)也应留在企业内部。

　　有没有预测公有云的费用?

　　部分组织错误地相信，公有云总是比本地的替代方案更为经济。为了计算将工作负载移出企业内部，网络以及工作量差异性还有许多其他组件的财务影响应考虑在内。

　　例如，网络的延迟会影响云端与内部部署相比较而言在财务上的可持续性。组织可以轻松前后迁移低延迟且不需要频繁访问的低延迟工作负载，这些负载应进入公有云，而不应该在本地存储大量数据。

　　“公有云是相当便宜的存储，”Fidacaro说，“如果您现在不需要访问数据进行分析，您可以将数据从边缘或企业拉到公有云端。”

　　考虑工作量的利用率如何影响价格。Lowe表示，可持续的利用可能会降低运营成本，例如，突发或轻微使用的工作负载在公有云端是更为合适的。

　　了解应用程序的性质。例如，找到它通常消耗的内存和CPU的百分比，并根据这些数字确定需要的云端实例的大小，以计算出云端部署的潜在开销。

　　“如果您突然将应用程序移动到云端，您就会在该位置创建大量的数据，”Eastwood说。“许多云模型包括对数据存储的溢价，并且由于诸如网络税和费用之类的云端费用，将数据移回企业内部的花费是昂贵的。”

　　评估可能发生的云端中断带来的财务风险。例如，如果一家航空公司的负载平衡应用程序停机，其公司的整个业务系统就会受到影响。

　　“如果您可以集中注意力在某些方面，就能获得更好的回报，而不需要那些高价值应用程序，其中最大的风险是访问这些应用程序的损失和潜在的数据丢失，”Eastwood说，“这些东西对于企业来说是非常核心的，您无法承担其中断带来的后果。”

　　Lowe认为，随着应用程序变得越来越分布式，了解每个工作负载不同的外部和内部元素都是至关重要的。

　　“你必须了解应用程序间的依赖关系、相互连通性以及组件情况，以便清楚什么可以或应该迁移到另一个位置，”他说。

　　责任编辑：DJ编辑