上云没错，上错了云，才是错！

本文来源：特大号

本文作者：小黑羊

过去这几年，「上云」绝对是最热的词儿，热到什么程度呢？烫手！

这朵云，“烫”到了企业决策者，他们把「上云」当成企业数字化转型的救命良药——

这朵云，“烫”到了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。

「上云」是不可逆转的趋势，但是，上云要找老司机，选择科学的方法和正确的步调。

上错了云，就像上贼船，下船可就难了。

文：小黑羊

~END~

免责声明：本文内容由21ic获得授权后发布，版权归原作者所有，本平台仅提供信息存储服务。文章仅代表作者个人观点，不代表本平台立场，如有问题，请联系我们，谢谢！