很奇怪的是,在经历了十多年的云迁移行业经验后,我们仍然觉得有必要大声呼吁云升移;一种将云简单地视为托管解决方案的实践,导致在云中复制现有架构、安全实践和IT操作模型。这并没有实现云的敏捷性和数字创新的承诺。云迁移需要跨多个轴向云原生状态进行有意的更改,并且根据独特的迁移环境,每个组织可能最终会从云提升到云原生状态。例如,系统架构是交付敏捷性的支柱之一,并且经常需要更改。简单地将现有系统提升和移动为集装箱要云可以强。虽然这种策略可以加速云迁移,但在创建敏捷性、交付特性和价值方面还不够。云中的企业安全与传统的基于边界的安全(通过防火墙和分区)有着根本的不同,它需要一个通往边界的旅程零信任体系结构.IT运营模式也必须进行改革,通过自助自动化平台安全地提供云服务,并授权团队承担更多的运营责任和获得自主权。最后但并非最不重要的一点是,组织必须构建一个基础来支持持续的更改,例如创建管道,并将应用程序和基础设施的持续测试作为迁移的一部分。这将有助于迁移过程,产生一个更健壮、更合理的系统,并为组织提供一种继续演进和改进其系统的方法。
随着越来越多的组织选择在云中部署应用程序,我们经常发现IT团队浪费时间试图在云中复制他们现有的数据中心管理和安全方法。这通常以防火墙、负载平衡器、网络代理、访问控制、安全设备和服务的形式出现,这些设备和服务无需重新考虑就可以扩展到云中。我们已经看到一些组织在云提供商面前构建自己的编排api,以约束团队可以使用的服务。在大多数情况下,这些层只会削弱功能,带走迁移到云的大部分预期好处。在这一期的雷达中,我们选择了重亮云升移作为一种避免的技巧。相反,组织应该更深入地研究其现有安全和操作控制的意图,并寻找在云中工作而不会产生不必要约束的替代控制。对于成熟的云提供商来说,这些控件中有许多已经存在了,采用云的团队可以使用本地api来进行自服务的供应和操作。
随着云应用的增长,不幸的是,我们看到了一种趋势,即把云当作另一个主机提供商。云升移不幸的是,大型供应商将现有的主机产品重新命名为“云”。它们很少提供任何真正的灵活性或按使用付费定价。如果您认为无需重新架构就可以迁移到云,那么您可能做得不对。