专家分享选择开源和自研道路上的考量以及具体的业务案例,点击查看 了解详情
写点什么

多云弊大于利,开源或是唯一明智的应对策略

  • 2020 年 12 月 04 日
  • 本文字数:1634 字

    阅读完需:约 5 分钟

多云弊大于利,开源或是唯一明智的应对策略

编者按:在企业内部,一些员工为特定项目使用特定的云计算供应商提供的服务,而另外一些员工为另一个项目选择不同的云计算供应商。企业之外,越来越多的云技术提供商业开始大肆宣扬多云、混合云的优势,但是对于采用多云技术的企业而言,这往往意味着企业管理成本上升、控制访问或应用程序、数据保护都将变得更为困难。 


近日,某海外科技媒体刊发了 AWS 工程师对于多云策略的反对观点,并且提出企业/云厂商更加积极的拥抱开源,这可能是有效解决多云弊端唯一明智应对策略的看法。InfoQ 特别整理编译了该篇文章,供 IT 业界人士阅读。


大多数组织使用多个云,但是对于大多数公司而言,这与某些宏伟的战略无关。相反,正是由于缺乏战略,才导致了其组织内部运行了多个云。或者按照 Gartner 的说法,是公司为不同的工作负载选择不同的云,而导致的企业最终不得不被迫采购多云技术。


无论如何,多云的策略往往意味着更多额外的成本和复杂性,尽管其往往被吹捧为灵丹妙药,但事实是弊大于利。

多云只是理论上很棒


软件即服务(SaaS)是一种许可模型,在这一模型之下,企业可基于订阅向客户提供对应用程序的访问能力,而由第三方的云厂商服务机构提供控制访问并负责安全性,运维等服务。


在那里,一切听起来都非常完美,我们的业务完全建立在一个云端环境中,随着业务的发展,当我们决定将在 Cloud A 上的业务及相关内容转移到另外一家云提供商(Cloud B)上的时候,我们只需轻轻的按一下 Cloud A 的“关闭”开关,然后再轻按一下 Cloud B 上的“打开”开关,一切就可以以一种极其简单的方式完成切换。


然而,结果并不是这样的。事实证明,开发人员之所以决定将业务迁移到 Cloud B 上,而不是在 Cloud A 上构建业务,是因为 Cloud B 上拥有更多功能丰富的服务,这些功能在原来的 Cloud A 上并不具备,没有他们需要的东西。


随着时间的流逝,即使 Cloud A 填补了一些功能的空白,但是由于相似的功能在不同云厂商之间也会往往以不同的方式实现部署,曾经迁移出去的业务往往已经再也无法迁移回来,于是只能基于多云的模式开展业务。


事实证明,每个云都提供高度多样化的服务。即使是精通 Azure 的开发人员,也无法在 Google Cloud 或 AWS 上高效地工作。供应商正在通过出售多云扩大公司业绩,但客户往往会逐渐被沉重、低效的多云管理和高昂的维护费用所累。


建立可在任何云提供商或您自己的数据中心内无缝运行的工作负载的想法非常令人信服,但是,这与向开发人员说“只要编写没有错误的代码”一样,比看起来要难得多。因为,每个云都是不同的,具有不同的优缺点。


如果您想利用 Google Cloud 上出色的数据库选项,那么您将无法轻松地将该工作负载移植到任何其他云上。这不是因为云供应商在用邪恶的设计来锁定您,而是因为它们各自都在尝试构建客户想要使用的有用服务。


同样的情况是,无论您在怎样的云上提供服务,都难以完全将其关联的数据迁移到其他云上。

开源或许是唯一明智的应对之策

我不确定多云管理对于大多数工作负载是否有意义,但为了有效的解决多云带来的负面影响,开源或许是有效解决相关问题唯一明智的应对策略。


如果一家公司希望最大程度地提高自由度/工作负载的可移植性,则可以使用社区驱动的开源项目(例如 PostgreSQL 或 Kubernetes)来构建。这并不能解决所有问题,但是对于某些关键领域,它将是可行的。 


由于 PostgreSQL 或 Kubernetes 这一类开源项目的代码往往都被 Azure、AWS、Google cloud 等云厂商做了集成,而且企业可以免费学习、使用集成到自己的业务当中。于是,企业既可以选择在其自有的服务器上用这些开源技术管理自己的业务,同样也可以在任何云上对这些项目进行自我管理。以保证其工作负载的可移植性。


事实上,多云将与我们长期同在,企业也会持续的购买相关的多云服务。这不是因为某些宏伟的公司战略考虑,而是因为开发人员都倾向于选择适合自己的技术方案。考虑到开发人员更倾向于喜欢开源,因此,使用更多的开源技术,可能是唯一真正明智的多云策略。


作者披露:本人为 AWS 工作,但反多云是我的个人观点,这一观点在我进入 AWS 之前便已持有。

2020 年 12 月 04 日 17:561114

评论

发布
暂无评论
发现更多内容

别小看 Log 日志,它难住了我们组的架构师

Java架构师迁哥

高频量化交易机器人系统开发技术

薇電13242772558

区块链 策略模式

Java并发编程实战(2)- Java内存模型

技术修行者

Java 并发编程 happens-before 多线程

消失的同事

石君

时代发展 28天写作

大作业(二)

橘子皮嚼着不脆

架构师训练营 1 期:大作业(二)

piercebn

架构师训练营第 1 期

OOP: DIP与LSP

Iris

面向对象 架构训练营

Go的声明语法为什么是这样

Rayjun

Go 语言

HDFS SHELL详解(2)

罗小龙

hadoop 28天写作 hdfs shell

APICloud AVM多端开发 | 企业app开发解析:案例展示、加盟申请功能源码

APICloud

大前端 小程序flutter, 跨平台 APICloud

重学JS | 聊聊闭包

梁龙先森

大前端 编程语言 28天写作

MySQL慢查询(中):正确的处理姿势,你get到了吗?

架构精进之路

MySQL MySQL优化 MySQL架构 28天写作

DeFi去中心化DAPP系统开发的知识科普

W13902449729

去中心化金融 DeFi去中心化系统开发

面试大揭秘!从技术面被“虐”到征服CTO,全凭这份强到离谱的pdf

Java架构之路

Java 程序员 架构 面试 编程语言

独角兽余额宝(Java现场面试48题):性能调优+索引+Mysql+缓存+HashMap+GC

Java架构之路

Java 程序员 架构 面试 编程语言

强!腾讯老兵亲荐“从零开始学架构”教你如何成为出色的架构师?(整整2000页的笔记)

比伯

Java 编程 架构 面试 程序人生

[0/28]软件质量的那点事(1)———引言

俊毅

软件测试 软件质量

智能合约DAPP软件APP开发|智能合约DAPP系统开发

系统开发

同城快递系统架构

Jacky.Chen

价值 - 风险管理(二)

石云升

读书笔记 风险管理 28天写作 价值

京东T7团队技术4面:线程池+索引+Spring +分布式锁+Mysql+项目等

Java架构之路

Java 程序员 架构 面试 编程语言

多熟悉一门编程语言看法

superman

精选算法面试-链表(判断环)

李孟

算法 链表 28天写作

芯片破壁者(二十五):从全球贸易网络看芯片博弈

脑极体

大作业(一)

橘子皮嚼着不脆

惊艳!四份SpringSecurity笔记带你玩转金三银四的面试题集!

996小迁

Java 架构 面试 springsecurity 笔记

架构师训练营 第十二周作业

文江

面向对象设计总结

Iris

面向对象

面向体验的视频云-火山引擎增长沙龙

面向体验的视频云-火山引擎增长沙龙

多云弊大于利,开源或是唯一明智的应对策略_新基建_Matt Asay_InfoQ精选文章