AWS 和开源：情况复杂

又到了每年的这个时候。 不，我不是指冬季假期，而是指 AWS re:Invent 发布公告的回响。 通常，当 AWS 采取重大举措时，IT 生态系统会受到震动。 在数据库领域，今年的重点是 Apache Cassandra，此前 AWS 宣布推出与 Cassandra 兼容的无服务器托管解决方案。

除了 公告，AWS 还发布了一篇 博文，解释了它的产品将如何通过增加对类似 Cassandra 的解决方案的需求以及允许 AWS 将改进贡献回开源社区来帮助 Cassandra 生态系统。

这并非 AWS 第一次这样做。 早在三月份，AWS 宣布推出 Open Distro，这是 Elasticsearch 的一个 恶意分支，并发布了一篇 类似的博文，该公司在其中辩称，其行动旨在阻止 Elastic 通过专有扩展污染开源项目。

现在，随着 Cassandra 的公告，我有一种似曾相识的感觉。 我来这里不是为了解决任何商业影响，但从开发人员社区的角度来看，似乎每次 AWS 宣布基于开源项目的新数据库产品时，它都觉得有必要重申该公司是一个伟大的 OSS 公民 - 但重复的努力只会让我对云时代开源项目的整体影响更加怀疑。 公平地说，至少在 Redis 的情况下，AWS 确实为主项目贡献了一些东西。 即将添加到 Redis 6 的 SSL 支持是 AWS 和 Redis（加上阿里巴巴等）的软件工程师之间合作的结果，正如 antirez 本人发推文说：

在 OSS 方面不太棒

虽然大批 AWS 员工 在 Twitter 上发动攻势 以向所有人保证他们是好人，但社区中的其他人则有不同的看法。 特别是，ScyllaDB（Cassandra 的 C++14 实现）的人似乎非常关注（在此 博文 中了解更多关于该公司观点的信息）。 简而言之，AWS 产品基于 Amazon DynamoDB，并且仅使用一些原始 Cassandra 代码作为翻译层，以允许 Cassandra 客户端 几乎 透明地连接。

“几乎透明”是因为此实现不支持某些原始 Cassandra 功能。 引用 ScyllaDB 的 Cassandra 专家的话

深入研究，功能差异很大。 没有多区域支持、没有 UDT、没有 ALTER TABLE、没有计数器——所有这些对于 Cassandra 用户来说都非常基本。

这是提供混合解决方案不可避免的结果。 我认为这不好，因为它很可能会导致 Cassandra 社区的分裂。 我在 Redis 上看到了这种情况。 AWS 提供了一种名为 ElastiCache 的托管 Redis 解决方案。 顾名思义，它主要面向缓存工作负载，并且不包含对某些关键功能的支持，这些功能使 Redis 成为可行的持久消息代理甚至主数据库。

情况很复杂，不像听起来那么简单。 在 AWS re:Invent 上，我数不清有多少与会者出现在 Redis 展位 却不知道在 Redis 中 你确实可以调整持久性 以实现与其他任何操作或分析数据库相当的持久性保证。 一旦他们了解到这一点，他们就会问他们还可以用 Redis 做什么，我们会谈论不同的数据类型、Redis Streams（ElastiCache 支持，但在强大的持久性设置下变得更有用） 以及 Redis 模块 如何让你向 Redis 添加新的数据类型，例如 全文搜索索引。 我们还将介绍 Redis 开源社区编写的许多附加模块（包括 redis-cell、redis-cuckoofilter 和 cthulhu）。

你可能已经猜到了，ElastiCache 不支持任何模块，即使是来自社区的模块

ElastiCache 的普及在 Redis 用户社区中造成了分裂。 仅通过 AWS 体验 Redis 的人正在看到开源项目方向和优势的不完整愿景。 我觉得如果更广泛的社区知道，是的，Redis 是一个很棒的缓存解决方案，但你可以用它做更多的事情，这对他们来说是有好处的。

AWS 如何影响开源社区

我们现在已经看到 AWS 分支并从多个开源数据库中剔除功能。 除了 Cassandra 和 Elasticsearch 之外，AWS 还有一个与 MongoDB 兼容的产品，其功能也不完整。 功能差异似乎是一个微小的技术细节，但作为 Redis 的开发人员倡导者，我可以看到它可能对社区产生的影响。 在 Redis 的情况下，功能差异实际上将 全球开发人员最喜爱的数据库 降级为 AWS 希望其客户使用的数据库的主要缓存前端。

说到开源，真正的问题不是 AWS 是否会贡献代码，而是其行为对开源社区的整体影响是什么。 坦率地说，所有这些博文、推文和金属胸针在我看来都像是转移注意力的东西。