
很多人都熟悉前三大云计算供应商,它们是AWS、Azure和谷歌云平台。
公共云领域的其他参与者是像Rackspace、Linode、Heroku和其他各种供应商。他们有区别于前三个主要参与者的服务。
本报告的其余部分将重点介绍迁移过程和AWS在其最佳实践白皮书中制定的7R策略。
迁移事件的考虑因素
当一个组织发生迁移时,这是一个极其重要的事件,不仅对组织本身,而且对组成该组织的人也是如此。以下是关于何时可能触发迁移的一些考虑。

这些触发因素的一些例子是像你的数据中心的租约。你的组织可能希望重新考虑续租,这取决于成本以外的其他因素和考虑。
其他考虑因素可能是对你的老化硬件进行升级,也可能是许可,也可能是由于行业变化或政府法规变化而导致的合规性。
此外,可能还有其他新的机会,可能需要考虑迁移到云端。
有些事情是额外的资金流,或其他一些机会,这里没有列出。
除了可能触发迁移事件的机会外,还要考虑到可能有内部或外部的威胁,这些威胁可能导致组织考虑迁移到云端。
云迁移的步骤

AWS已经制定了一个双管齐下的云迁移方法,那就是以其7R策略进行云迁移,以及更大的迁移过程和工作流程。
黄框中列出了7R,它们是。 Retain(保留)、Retire(退休)、Relocate(搬迁)、Rehost(重新托管)、Replatform(重新架构)、Repurchase(重新购买)或Refactor(重构)。
迁移和过程的工作流程从规划开始,决定是否将应用程序迁移到云端,进行实际的迁移,然后验证迁移,测试它确保它满足你的业务需求,最后部署到生产中。这是一个持续的过程,需要对你的业务组合或你的业务部门组合中的每一个应用都进行测试。
在我继续之前,我想谈一谈不一定需要迁移到云中的两个R。它们是由你是否真的要把特定的应用程序迁移到云中的问题决定的。
如果你选择不这样做,你有两个选择。你可以问自己另一个问题,这个应用程序对你的业务来说是否需要。
- 如果不需要,那么一个非常有效的方法是将该应用程序全部 "退休",然后停止这个特定应用程序的进程。
- 如果该应用程序需要用于任何商业目的或业务流程,那么你可能想考虑保留该应用程序,然后重新审视它是否需要在未来某个时间点迁移到云中。
对于所有其他将要迁移到云端的应用程序,你有五个不同的选择:你是否要重新定位,你是否要重新托管,你是否要重新格式化,你是否要重新购买,或者你是否要重新调整。
现在让我们来看看其中的一些选择。
重新安置

你可能想考虑的第一个选项是搬迁选项。
现在,这是相对较新的,因为AWS已经与VMware建立了强有力的伙伴关系。由于这种伙伴关系,AWS和VMware非常有信心,你可以使用裸机实例直接在云上启动你的vSphere工作负载。
这样做的一个好处是,你可以使用你现有的企业内部的许可,直接迁移到云端。这是一个机会,你可以从你可能需要管理的、你可能需要租赁的物理数据中心中脱离出来,转到云上,在那里,很多管理的开销已经被解决了。
重新托管

你有的下一个选择是重新托管你的应用程序。
这被称为提升和转移。提升和转移过程可以是手动或管理的迁移。
提升和转移的好处之一是,它不仅可以为你提供更快的迁移,还可以根据你迁移的工作负载,让你的团队迅速上手,在迁移方面有大量的学习和发展经验和专业知识,以便未来的应用可以在较少的开销下进行迁移。
这种策略允许在未来业务需求决定的时候进行云优化。
Rehost - AWS应用迁移服务

AWS的应用迁移服务提供了一个自动提升和转移策略的例子。
它的要点是你在你的源服务器上安装一个代理,然后你将自动启用复制,然后从仪表板上,你可以选择将你的实例启动到云中,之后你将执行你的测试,然后最后执行切换,做你需要做的其他事情。
这是一个非常好的方法,可以照顾到相对现代的硬件和相对现代的操作系统,并以自动化的方式进行迁移,以这种方式简化你的工作流程。
再平台

另一个可能对应用程序可行的策略是重新平台。
这也被称为提升、修补和转移。它与重新托管非常相似,也就是提升和转移,但你是为一些云原生功能进行优化。
这方面的一个例子是数据库迁移到云原生平台。
作为一种策略,复制平台的直接好处是你从云平台得到的容错性,比如多AZ的东西。
此外,更新和自动备份已经为你处理好了,使你的团队可以专注于其他业务目标。

正如你所看到的,通过使用AWS的数据迁移服务,将Oracle数据库从你的内部工作负载中迁移出来是相对简单的。这将为您的数据库创建一个亚马逊RDS实例。
其他数据库也被支持,如MySQL数据库到Aurora数据库。再一次,好处是直接的;容错、更新和自动备份。
重新购买

接下来,我们将进入回购选项。
这个选项基本上是将你的自我托管的内部工作负载转移到软件即服务或商业上现成的应用程序。
与重新平台类似,这也将释放你的团队,让他们专注于更直接的业务需求,并卸载常用应用程序的管理,如办公套件、通信平台、票务平台或视频会议平台。
这使你的团队在迁移期间有更大的灵活性和更多的能力来关注业务需求。
重构

现在我们进入重构策略。这也被称为重新构建应用程序。
对于团队中的一些成员或企业来说,这可能是很有趣的。在这里,你和你的团队可以重新设计应用程序,并确保它能以云原生格式运行。
其中的一个注意事项是,企业必须明白,重构一个应用程序,无论是现代的还是遗留的,往往比预期的要复杂。
企业通常会发现,为了将应用程序完全重构为云原生格式,需要在时间、资金和团队开发方面进行大量投资。
你不仅要采用完整的软件开发生命周期,而且还要确保它与现有的业务流程相整合,无论这些流程是传统的还是现代的。
重构 - 迁移中心重构空间

AWS最近推出了一项被称为AWS Migration Hub Refactors Spaces的服务。
这允许你的团队把你的遗留应用程序,重构成一个更容易管理的云原生类型的服务。这样做的目的是,它允许你确保你能以最少的开销和对很多外部因素的控制来迁移你的遗留应用程序。
你和你的团队将需要有三个账户,其中第一个账户负责处理遗留的应用程序。第二个账户将托管新的微服务。而第三个账户是重构的环境。
正是这个重构环境提供了一个统一的网络、中转网关协调,它提供了VPC协调和资源访问管理器协调,所以你的传统应用程序将像传统的方式一样行事,然而,它将被容器化为一个微服务。
这是AWS服务的一个非常令人兴奋的新内容,如果你能利用它,你的云迁移经验将更加顺利。
总结

总结一下,这些是云迁移策略,也被称为7R。
它们是保留、退休、迁移、重新托管、重新平台、重新购买和重构。在这七种策略中,保留和退休并不适合云工作负载。
然而,如果一个应用程序不再需要了,在这种情况下,你要让它退休,它们是非常有效的选择。而如果一个应用程序目前正在使用,但目前没有必要迁移到云中。
迁移过程从你的组合发现开始,然后是优先级的确定。这是在一个规划周期的背景下。
然后,一旦你决定是否要去云端,你就可以从以下五个选项中选择,即迁移它、重新托管它、重新平台化它、重新购买它或重构代码,此时你将进入设计周期和验证周期,你和你的团队将为云端重新设计,并确保它能像以前那样工作,从而满足你的业务需求。
如果一切顺利,好的,你将把它投入生产。一旦一个应用完成,你的团队已经建立了知识,你的团队已经建立了经验,然后下一次的迭代,下一次的迁移会更快。
参考资料
下面是我在为你做这个演讲时使用的参考资料清单。
你会注意到,它们都是AWS的资产。我鼓励你阅读其中一些,了解什么最适合你的业务,什么最适合你的应用,在你迁移到云端之前。所以,照顾好自己,有一个美好的一天,我会在下一个视频中看到你。暂时告别。