您可能已经错过了,但是Twitter上发生了一场宗教战争。 (不,是真的!)一方面是一系列数据基础设施公司(MongoDB,Confluent和Redis Labs)声称亚马逊Web服务正在剥离其开源代码以出售云服务,例如Amazon Aurora,RDS和MSK(用于Kafka的托管服务。另一方面,AWS的首席执行官Andy Jassy坚持认为其产品并非旨在“横扫所有人”。如果您查看我们正在做的事情,那么,顾客。”
这使我们想到了今天的新闻,即AWS正在推出Amazon DocumentDB ,这是一个与MongoDB兼容的数据库,“从头开始设计,可为客户提供大规模运行关键任务MongoDB工作负载时所需的性能,可伸缩性和可用性。” AWS非关系数据库副总裁Shawn Bice向我强调,“尽管像MongoDB的灵活数据模型和其他属性这样的客户,他们仍在努力从中获得所需的性能和可用性。”
对于客户而言,这基本上意味着他们可以从AWS作为云服务获取其MongoDB。 但是,对于AWS和MongoDB而言,它要复杂得多。 (我应该指出,几年前我曾担任MongoDB社区副总裁。)
卓:您的MongoDB蛋糕也要吃
根据DB-Engines的数据 ,尽管相对于PostgreSQL,最近几年它的流行度有所下降,但是MongoDB仍然是世界上第五流行的数据库。 鉴于开发人员可以轻松快速地使用MongoDB进行生产,这种受欢迎程度不足为奇。
但是,这种轻松的问题是MongoDB容易出错。 这是一个功能,而不是错误,但这确实意味着,今天Swift被黑客入侵的应用程序可能成为公司运营团队明天支持和维护的噩梦。
在确定其DocumentDB服务的原因时,AWS指出:“客户还发现在MongoDB上构建高性能,高可用性的应用程序具有挑战性,由于随之而来的复杂性,这些应用程序可以快速扩展到数TB的数据和每秒数十万次的读写操作。设置和管理MongoDB集群。”
从本质上讲,这并不是不正确的,但这还不是全部。
毕竟,MongoDB一直致力于通过其Atlas服务简化大规模操作数据库的工作 。 Atlas深受好评,每年以300%的速度增长,现在占该公司2.6亿美元年收入的22%。 这很棒,但这也是宗教战争开始的地方。 MongoDB不满足于在易用性方面的竞争,因此进一步尝试通过在2018年10月推出其服务器端公共许可证以阻止其他任何人(主要是AWS)出售竞争对手的服务,从而使MongoDB在运营方面更具效率。
从今天发布的Amazon DocumentDB来看,它不起作用。
好吧,Amazon DocumentDB与MongoDB不太一样
如DocumentDB新闻稿所述,“ Amazon DocumentDB通过模拟MongoDB客户端期望来自MongoDB服务器的响应来实现Apache 2.0开源MongoDB 3.6 API,从而允许客户将现有的MongoDB驱动程序和工具与Amazon DocumentDB一起使用。” 我要求AWS的Bice将其翻译成正常的用语,他回答说:“客户的MongoDB应用程序中的绝大多数可以与Amazon DocumentDB一起使用,而几乎不需要更改。”
当被问到“但是客户如何知道他们的MongoDB应用程序可以与Amazon DocumentDB一起使用?” Bice表示,这是每个企业的首要问题。 在启动时,AWS将提供最受欢迎的MongoDB服务。 然后,使用其内置的API监视工具,它将跟踪最抢手的功能以使服务更好。 客户可以阅读文档以了解所提供的服务。 他们可以将他们的应用程序指向DocumentDB,以从API可编程性的角度查看将起作用的内容。 或者他们可以使用AWS Database Migration Service迁移应用程序以测试其是否有效。 Bice再说一次,“如果DocumentDB不支持某些功能,我们将在遥测中进行选择并相应地更新产品。”
这意味着,对于大多数应用程序而言,大多数客户可以从AWS获取其MongoDB,而无需AWS在其服务器上运行任何MongoDB代码,同时将DocumentDB与他们使用的所有其他AWS服务配对。 正如Capital One副总裁Sunjay Pandey指出的那样:“ Amazon DocumentDB与AWS服务深度集成,并为我们提供了健壮,高度可扩展且具有成本效益的数据库服务,可以满足我们的运营要求。”
这提高了MongoDB Atlas的投入。 但是,这对于底层的开源项目意味着什么呢?
使用AWS进行开源战争的更大悲剧
想一想。 正如MongoDB在宣布SSPL时所说的那样:“过去十年来,我们在研发方面投入了约3亿美元,为每个人提供了一个现代的,通用的开源数据库。” MongoDB首席执行官Dev Ittycheria表示,担心的是,除非MongoDB能够通过货币竞争将货币排除在外,否则它将没有足够的资金来维持数据库的发展。
这似乎很有说服力,但不一定正确。 例如,开源项目Magento几年前改变了其与开发人员社区的合作方式,现在它看到60%的代码(包括一些最难开发的功能)来自未雇用的第三方开发人员由公司。 弄清楚如何与社区合作的公司实际上可以看到创新在加速而不是下降,而无论他们能够为产品收取多少现金。
即使您同意Ittycheria的观点,您也要问:如果AWS无意中止了其构建服务的项目,AWS会获得什么好处?
我问Bice,如果AWS能够成功地吸引数百万客户(而不是MongoDB(或Confluent或Redis Labs),而不是MongoDB)将这些开源项目作为服务进行管理,那么会发生什么情况。 毕竟,要使DocumentDB提供长期,有用的服务,它就需要MongoDB(而不仅仅是DocumentDB)才能生存和发展。 简而言之,它需要做出贡献。
比斯做出了多方面的回应。
他说,首先,亚马逊“对开源的贡献持续加快。” 尽管AWS肯定可以改善,但该公司多年来已经投资了各种项目,包括Xen(EC2的基础),Linux,Kubernetes, 机器人操作系统 ,各种Apache项目(Lucene,Hadoop,Spark等)。 。), 还有很多。
公司的贡献也没有保留给社区驱动的开源项目。 例如,在2018年初,AWS 在Transit for Redis中开源了Encryption ,这是一种“保护实时应用程序并加密客户端与Redis服务器之间的所有通信的方式”。 这个示例特别有趣,因为正如AWS开源负责人Adrian Cockcroft指出的那样 ,Redis Labs“重新许可了其代码以确保我们不做任何贡献。” 这些公司表示,他们希望AWS做出贡献,但是当云巨头这样做时,他们就会阻止它。
但是他们不应该。 Redis的这一贡献彰显了AWS的主要优势:它以极高的可用性和性能运行。 可以说,该公司最适合对开源代码进行压力测试。 因此,比斯毫不奇怪地说,它的许多贡献都与这一领域有关。 当然,不可能开源化所有用于卓越运营的要素,但是对于AWS与从中受益的开源社区之间进行更大的协作,这一领域已经成熟。
这使我想到了Bice的第三点:当AWS启动基于开源项目的服务时,“我们绝对会长期致力于该项目。” 考虑到客户对公司的痴迷程度,这很直观。 例如,AWS并不想维护Kubernetes或Kafka的专有分支,因为“维护项目的内部分叉版本会造成浪费。 我们知道这不是一件好事,因为它会减慢创新速度。” 因此,他说:“如果没有摆在我们面前的障碍,我们将为我们使用的开源项目贡献功能增强,错误修复等,因为我们希望这些项目蓬勃发展。”
不只是li行。 蓬勃发展 。
前进的道路:对开源的更大共同承诺
在与AWS的不同人员进行的多次单独对话中,我听到了同一件事:“我们对世界没有一个全胜者的看法。” 重点是满足客户需求。
可以说,这是最大的问题之一:与许多开源项目的商业开发人员相比,AWS更擅长于对代码进行操作。 这些公司希望获得通过开源货币获利的专有权(讽刺的是,这不是很开放),但他们的客户只是希望能够大规模运行开源代码来解决实际的业务问题,从而减少花费在修补补丁程序上的时间,升级等
根据Bice的说法,“我们投资于这些开源社区。 我们认为我们可以吸引很多客户使用我们支持的任何API。” (而且,是的,正如MySQL数据库专家Mark Callaghan指出的那样 ,AWS可以而且应该做更多的事情。)这种支持不仅是工程上的,而且是市场上的。 是的,这意味着我们很可能会看到AWS试图使更多人对MongoDB 和 Amazon DocumentDB感兴趣。 AWS可以在MongoDB周围增加用户数量越多,最终可能会希望使用DocumentDB大规模运行的人越多。
Bice坚持认为:“公司和学术机构之间的开源合作带来了一些世界上最有趣的突破。” 这是AWS想要培养的,而不是杀死的。
AWS与开放源代码项目的商业提供商之间的紧张关系主要归结于谁应该能够满足客户需求。 一个可以解决某些问题的地方是,AWS和这些提供商都需要开源项目才能成功。