“多云”真的有必要吗?

最近总是在各种渠道看到关于“多云”架构的一些思考,正好周末无事,整理整理自己对这件事情的看法。

一、是什么在驱动企业“多云化”?

目前市面上多云架构主要是分为两大类:

第一种是因为各种原因诞生的混合云需要进行多云管理,比如本地私有云(或专有云)与1个或N个公有云打通并混用。

第二种是单纯的公有云之间进行混用,由2个或以上的公有云来共同负担业务的云资源开销。

无论是什么方式的多云,大致是以下的几种原因在进行驱动:

1.数据归属的问题,因为数据不能离开特定数据中心,同时又因为部分业务在公有云上,所以需要通过多云的方式来进行混合管理,将数据放在私有云,而将部分非敏感业务放到公有云,从而实现业务云化。

2.云产品质量导致的差异化部署,比如A云厂商的数据库更优秀,而B云厂商的存储服务或大数据服务更优秀,则企业可能通过多云的方式去部署产品,从而实现“博百家之长”的效果。

3.同样的产品质量、同样的服务质量,但是因为某些云厂商的产品价格更优惠,则成本敏感型的企业同样可能选择多云方式部署产品。

4.最后一部分企业,从可靠性角度出发,业务部署在多个云平台上,从而实现冷热备、异地多活等高可靠架构。

二、多云带来的复杂问题有哪些?

1.运维难度直线上升

每个云平台的产品操作、运维API、运维产品、底层差异都会让运维人员在进行运维时受到更多挑战。

为了提高运维效率,一般会使用一些“多云管理平台”来进行集中维护,但是其只能实现资源级的互通,而且“多云管理平台”也需要部署,增加了单点故障风险,一旦“多云管理平台”出现故障,则很可能出现所有云产品无法正常运维的情况,所以这是典型的为了解决问题而制造了另一个新的问题。

2.产品研发过程中需要额外考虑网络因素导致的业务抖动。

在原本的的单云模式下,业务部署在A云上,只需要考虑几种有限的网络情况就可以了,主要是以下的2种情况:
在A云部署的应用/服务的内部互通链路。
在A云部署的应用至用户的互通链路。

如果业务分布在A云及B云上,情况会变得大为复杂,变成了5种情况:
在A云部署的应用/服务的内部互通链路。
在A云部署的应用至用户的互通链路。
在B云部署的应用/服务的内部互通链路。
在B云部署的应用至用户的互通链路。
在A云部署的应用/服务与B云部署的应用/服务内部互通链路。

一旦参与的云越多,则业务的网络架构会变的更加的复杂,一个业务如果网络架构越来越复杂,则出现故障的风险将会大幅度放大。

最后,即便你解决了网络差异导致的互通链路可靠问题,你还需要解决多云差异带来的网络延迟问题,这同样是一个让人很挠头的问题。

3.多云带来的安全性问题。

由于网络差异及各个云平台层次不齐的安全水平会导致新的安全问题,一方面因为网络环境的差异,多云数据一旦需要交互,则必然带来安全问题的考量,目前主流的方式更多是通过以下几个角度来解决:

1.通过拉专线去互通多个云,好处是相对可靠和安全,延迟也低,但是带宽会非常的贵。

2.通过软交换的方式去互通,比如通过VPN、高速隧道这些方式去互通两个云,好处是相对便宜且业界方案较多,缺点是数据毕竟要从公网走,一方面延迟较高,同时即便是加密了数据也不能保证过程中不会被篡改、窃取、污染。

三、多云是否有必要?

我个人的感受是,混合云多云有其存在的必要性,但是公有云的多云架构其实是伪命题,因为想要真正的玩好公有云多云架构,付出的精力和成本可能远远高于其带来的片面好处。

即便你是想做灾备,我也更倾向于灾备的问题应该由云厂商作为底层基建去实现,而不是我们笨拙的通过多云去构建一个虚假的高可靠。当下的这种多云灾备模式更像是一种妥协,在云厂商大战还未收官之前,对所有云厂商都不信任,从而衍生出来的一种过渡方案。

如果是因为产品差异、价格差异去使用多云,那我觉得这也是阶段性的痛点,因为云厂商总会成长到满足你需求的时候,并且随着云计算产业和5G产业的壮大,云产品价格也会越来越低,这些差异总会被时间抹平的。

所以我认为公有云多云架构这件事是为了解决一个问题而创造了一堆新问题,是时代的过程,而不是结果。

本文仅代表个人对行业的思考,没有商业目的,请勿转载,谢谢!