Migration2.0 云原生迁移的路径思考总结

同样，可以看到云原生的去迁移路径，是有三条路径；

3、GO NATIVE

2、EVOLE

1、Llift & Shift

第一条路径；lift & Shift （升降），直接高速通路到达IAAS，也就是今天的各类主要的公有云厂商，里面提供的各种服服务，这里仍然可以理解为就是云服务器，云数据库等等，这与6R策略中几乎一致，都是为了走向将‘承载’更换为云的IAAS底座。

‘基础设施的底座更换是为进一步应用云化（解耦）提供土壤，这是在既有历史债务的战略转型中的基础’

‘此类的迁移技术，如上篇提到了，有完整且成熟的工具帮助你进行迁移，所以往后的发展云厂商的迁移工具将更加的完善’

工具已经非常成熟，其实回过头来去看，也就半年的时间各大迁移服务商的价值就已经被厂商补齐，但国外和国内始终有个巨大的区别，国外虽让官网补齐了，仍然迁移的生意会委托给伙伴来完成，并支持伙伴从中获得更多的收益。相关国内就是反过来的，所以国内市场相对比较无序

阿里云：https://help.aliyun.com/document_detail/414831.html

腾讯云：https://cloud.tencent.com/document/product/659

华为云：https://www.huaweicloud.com/product/sms.html

微软云：https://docs.azure.cn/zh-cn/dms/

亚马逊：https://aws.amazon.com/cn/server-migration-service/

谷歌云：工作PCXX被墙

优刻得：https://docs.ucloud.cn/usmc/introduction/concept

所以第一条路径，不难理解，只是在Cloud2.0，Architecture2.0，这条路径仍然是首问的标准节奏。只是这里格外提到了关于云上大量的COST的忧虑与担心。

第二条路径；EVOLE，（进化），从终点来分析，基础设施的底座进一步做了细分：1、不变的IAAS 2、Docker尖塔 3、PAAS写字楼 ，顾名思义，这是一个改造的思考总结，但这里值得注意的是这里有承上启下的作用，这里切记不要忽略，也是需要特别注意的（在第一次看这个图的时候就出现了忽略的情况）

我们可以借助工具的使用更快速的达到这一目标，工具举例如下所提及：

• 使用Terraform等“基础设施作为代码”工具来管理云着陆区和应用程序基础设施的配置
• 使用Puppet等“配置为代码”工具可靠和重复地配置基础设施和应用程序配置。这里的目标是“不可变的基础设施”。
• 建立CI/CD管道，使基础设施和应用程序代码的部署快速简便，并保证安全、有效的结果，这要归功于测试自动化作为管道的一部分
• 利用平台即服务（PaaS）解决方案托管您的应用程序和数据，摆脱以服务器为中心的托管策略。PaaS服务通常节省大量费用，并改善了可伸缩性和可用性。
• 利用Docker Containers等新技术托管您的应用程序，最好是在云供应商提供的容器解决方案中，如Azure/AWS Kubernetes服务。

注释：这些工具已经有非常不错的实践来证明可行性，你不妨动动手测试下，就会有特别深的感触。这类工具的学习是决定你理解云原生的重要过程，所以理解devops，工具使用是不可或缺的经历。

第三条路径；GO NATIVE（‘直接上云原生’），这在过去是一种极其不现实的理想目标，因为国内大多数应用都是以“改造”“优化”为出发点引入新的技术，所以这也一定程度上说明了，改造技能职位的需要（如：公有云/私有云迁移工程师）。该路径旨在应用从立项之初，开发就完全使用云的各类基础设施组件（注意，这里重点不在于云服务器、云数据库），例如：函数服务、容器服务、无服务器服务等等

所以这里会有一堵大墙：如何容器化？，这个问题我放到后面，大家来先看几个我经历过的例子。

例子一：原来应用都是传统开发架构，新的要求是直接全部采用结合云的开发架构，这里就是区别最大的地方。你在用声明式API管理所有的基础设施，不再担心OS里面有环境问题，而是在CI/CD和不变的一致性上立刻销毁错误环境重新起一个新的环境出来进行替换。这或许就是最大的差别（关于运维）

例子二：原来应用总是都会考虑很多预留，厚重的平台和业务，解耦程度不高，也就代表了容错率也低。新的要求则是将一切可以解耦的、异步的服务进行拆除，短信（不再使用运营商接入，直接利用云服务接入），关于小型服务新要求则是直接用无服务器架构（如Lambda）完成，文件存储分别落在对象和块上，业务架构中（又抽象出一张服务全局的架构图：网关、RPC等等）。

我们常常说上云，都只是在“on cloud”上做一些Cloud1.0里的事情，比如云化，但并没有使其业务智能化，所以在过去大多数业务场景中经常几类价值：降本增效、无硬件故障，这些都是在1.0中大家能明白也能接受的价值输入。但这仅仅是“on cloud”的结论。那所谓Cloud2.0其实就是将on变成了in，顾名思义生长与Cloud中，开发架构，技术架构均是完全利用了Cloud能提供的XAAS的设施情况来完成的。

IN/ON，一字之差，截然不同的理解。目前这个概念虽然诞生于华为云云原生全景图，生于云而长于云。这也是我想接着表达的，过去说多云都立足于IAAS，趋势已然是常态化现象，从资源互通、资源管理，再到业务的云间的业务调度。

“如果条件允许，大家可以去找下华为在去年年底发的云原生白皮书，里面提到几个我很赞同的词，比如这里说的in/on，再比如：黑土地”

2023年，让我们扎实的学习容器平台，学会yaml，学会从容器平台去理解应用的解耦与容器的灵活运营。为什么这么说，容器平台（K8S）发展至今已经趋于成熟并已经没有了其他分支，这将意味着有更成熟的商业化应用将诞生，而且越来越快。所以这可能是Cloud2.0的新底座，从过去云服务器的底座变换为K8S的底座，也侧面说明了技术迭代的更靠近业务了。

所以，学吧，干饭人！

让我们来一起看看CNCF为想all in 云原生的企业提供的指导图纸

表达下个人的感受，这里的第一步就是容器化，那请问大家真的懂容器吗？原理的理解，运用的理解，还有基础容器安全的理解。第二个就是大家经常听到的CI/CD，第三步是定义应用，后面还有很多。但一般在目前接触的人群中，大多数人就仅仅到了第三步就不知道下面的发展了，预期说不知道更不如讲是不会了。

‘所以经常问自己一些话，技术路线上该如何学习云原生，这就是官方答案！！’