这是第10篇神扯：扯扯上云的那些「套路」。
过去这几年，「上云」绝对是最热的词儿，热到什么程度呢？烫手！
这朵云，“烫”到了企业决策者，他们把「上云」当成企业数字化转型的救命良药——
这朵云，“烫”到了IT管理者，「上云」成了他的建设目标，IT系统的「云化率」成了他们的KPI——
这朵云，“烫”到了运维工程师，他们觉得这锅更多更大了，以前烟囱要倒倒一个，「上云」以后，要倒全倒了——
当然，这朵云，也烫到了传统IT产品供应商，他们需要迫不及待的推出「上云」产品，顺应时代——
……
…
.
一顿操作猛如虎之后，很多人却发现，“上云一时爽，验收泪汪汪”。
于是大家纷纷怀疑，云的价值是不是被过度夸大了？似乎云没有传说的那么美妙…
其实，「上云」本身没有错，「上错了云」才是错！
关于上云，必须要明白两点：
第一，我们谈到的绝大多数云的价值和优势，都是「公有云」，而不是「私有云/专有云」。
小规模的IT基础设施，做个虚拟化、加个云管平台，只是微创新，仍然还是一个小水坑。
只有公有云才是“汪洋大海”，能够提供①真正意义的弹性②实时更新的最新技术栈③永远在线的能力和可信赖的SLA。
我们念念不忘、恋恋情深的所谓“云原生”梦想，并不是随便搭几个容器、改改k8s就能实现的，要实实在在的把根基立在云上。
第二，即便我们选择了公有云，也不是把所有业务一股脑全搬，要有取舍和选择。
每个企业的不同IT工作负载，需要不同的上云策略，确切的讲：道路千万条，上云有七条。
这7条路，被称为「7R」——
1、重新托管（Rehost），直接迁移
这种方式，无论原来业务运行在物理机还是虚拟机上，都可以基于自动化工具或者手动方式，“搬”到云上去。
“重新托管”后，业务的使用体验不会有本质提升，但可以从云上继承更好的稳定性和可管理性，并带来多达30%的成本节省。
2、平台更新（Replatform），迁移加更新
这种迁移方式，比Rehost要复杂一点，适用于相对核心又不希望“大改”的业务，部分直接迁移，比如计算需求，而诸如数据库、中间件等等业务，可以切换为公有云的PaaS平台。
这种“打补丁”的方式，不仅能带来成本大幅节省（比如不再需要买断型的数据库或者中间件授权），同时借助PaaS的弹性，还可以带来大幅的性能改善。
3、重新采购（Repurchase），转移至不同产品
适用于原来本地化运行的一些应用软件，比如财务系统、CRM、ERP，现在可以抛弃本地化部署，全部改用同类的SaaS软件，用订阅的模式付费。
4、重构（Refactor），重新规划应用程序的架构和开发方式
这是最复杂的一种迁移方式，适用于企业核心业务，希望享受云原生红利、全面云化的。
涉及到架构重新设计，比如集中式改为分布式、微服务化，甚至无服务器架构，代码需要重新开放，改造周期最长、代价最大，当然“改头换面”之后，对企业转型升级的影响也是最明显的。
5、清退（Retire），强扭的瓜不甜，扔掉
总有些老旧应用，拖累着IT资源、拖累着运维人员，在上云的抉择期，该抛弃的要果断抛弃。有时候“失即是得”呀。
6、保留（Retain），相时而动
企业中往往还有一类应用，要么无关痛痒，迟早被数字化大潮抛弃，但短时间内又能“凑合”着用，要么是传说中的“稳态”核心业务，架构变更代价过大。
针对这类情况，可以选择暂时保留，未来伴随技术和业务的发展，再考虑新的选择。
7、重新部署（Relocate），换个地方继续VMware
最近，AWS还推出了「上云」的第7种选择，因为很多企业中存在大量基于VMware虚拟化的工作负载，针对这类客户，可以采用VMware Cloud on AWS，一键迁移上云。
「上云」之后，还可以与云上的其他工作负载和服务打通，管理和服务的一致性更好。
企业上云切记一刀切，既不能破而不立，又不能立而不破，需要根据业务应用的实际状况，进行合理的选择和取舍。
Rehost、Replatform、Repurchase、Refactor、Retire、Retain、Relocate，7个R为我们指明了「上云」之路。
我们一起再来回顾下，企业业务迁移上云的完整流程吧——
疫情更像加速器，加速了企业云化的进程。企业IT需要更弹性和稳定的基础架构、更先进并持续更新的技术栈、永远在线的体验和有保障的SLA。
「上云」是不可逆转的趋势，但是，上云要找老司机，选择科学的方法和正确的步调。
上错了云，就像上贼船，下船可就难了。
别慌，这里有一本企业上云迁移的权威指南，由AWS原全球企业战略总经理Stephen Orban编著，详细阐述了云计算技术在企业的应用和实践，前面“7R”方法论只是书中的一篇文章而已。
这本书由AWS首席云计算企业战略顾问张侠先生亲自翻译，有个响亮的名字，叫做《剑指云端》，如果您正在摸索企业上云迁移方案，希望少走弯路的话，看完此书会有不少收获
