AWS 和开源：很复杂

又是一年一度的这个时候了。不，我指的不是冬季假期，而是始于AWS re:Invent的公告的回响。很多时候当 AWS 做出重大举动时，IT 生态系统都会受到震动。今年，在数据库领域，在 AWS 宣布提供与 Cassandra 兼容的无服务器托管解决方案之后，影响集中到了Apache Cassandra。

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

这并不是 AWS 第一次做类似的事情。早在 3 月份，AWS 宣布推出 Open Distro，这是Elasticsearch的敌对分支，并发布了一篇类似的博客文章，其中该公司认为其行为的目的是阻止Elastic用专有扩展污染开源项目。

现在，随着 Cassandra 公告的发布，我有一种似曾相识的感觉。我并不打算在这里讨论任何商业影响，但从开发者社区的角度来看，似乎每次 AWS 基于开源项目宣布一种新数据库产品时，它都会觉得有必要重新阐述该公司是一名伟大的 OSS 公民，但反复的努力只是让我对云时代对开源项目的总体影响更加怀疑。公正地说，至少在 Redis 的情况下，AWS 确实向主项目贡献了一些东西。向 Redis 6 添加 SSL 支持是来自 AWS 和 Redis 的软件工程师（以及阿里巴巴和更多其他公司）共同协作的结果，正如antirez自己发推文所说的：

涉及到 OSS 时，并不是那么令人惊叹

虽然亚马逊员工军团 席卷 Twitter向所有人保证他们是善意者，但社区中的其他人想法则不同。特别是 ScyllaDB（Cassandra 的 C++14 实现）中的人们似乎非常关注（在此 博客文章中了解有关该公司的更多信息）。简而言之，亚马逊产品基于 Amazon DynamoDB，并且只使用部分原始 Cassandra 代码作为一种转换层，以允许 Cassandra 客户端进行 几乎完全透明的连接。

“几乎完全透明”，因为此实现不支持某些原始 Cassandra 功能。引用来自 ScyllaDB 的 Cassandra 专家意见

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

这是提供混合解决方案必然造成的结果。在我看来，这不是一个好的解决方案，因为它很可能会导致 Cassandra 社区分裂。我在 Redis 中看到这种情况的发生。亚马逊提供了一种名为 ElastiCache的托管 Redis 解决方案。顾名思义，它主要用于缓存工作负载，并且不支持使 Redis 成为可行的持久消息代理或甚至主数据库的一些关键功能。

情况很复杂，并非听起来那么直截了当在 AWS re:Invent，记不清有多少与会者来到 Redis 展位，他们不知道在 Redis 中，你确实可以调整持久性实现与任何其他操作或分析数据库相当的耐用性保证。一旦他们了解到这一点，他们就会问还能用 Redis 做些什么，我们就会谈到不同的数据类型，Redis 流（ElastiCache 支持Redis流，但使用强持久性设置后会变得更有用），以及如何使用 Redis 模块 将新的数据类型添加到 Redis，例如 全文搜索索引。我们还将涵盖 许多其他模块，这些模块是由 Redis开源社区编写的（包括redis-cell、redis-cuckoofilter 和 cthulhu）。

正如你可能猜到的那样，ElastiCache不支持任何模块，即使是来自社区的模块

ElastiCache 的普及在 Redis 用户社区中造成了分歧。仅通过 AWS 使用 Redis 的人看到  的只是开源项目方向和优势的不完整愿景。我认为如果他们知道这一点，更广泛的社区将会受益，是的，Redis 是一个很棒的缓存解决方案，但它还能做更多的事。

AWS 如何影响开源社区

我们见证了 AWS 分叉并从多个开源数据库中提取功能的情形。除了 Cassandra 和 Elasticsearch 外，AWS 还提供了一个兼容 MongoDB 的产品，该产品也尚未完成功能。功能差异可能看起来是一个细微的技术细节，但作为 Redis 开发者倡导者，我能看到其对社区产生的影响。就 Redis 而言，功能差异实际上将全球开发者最喜爱的数据库有效地降级为 AWS 希望其客户使用的数据库的缓存前端。

谈到开源，真正的问题不再是 AWS 是否会贡献代码，而是其行为对开源社区的总体影响。坦率地说，我看来所有这些博客文章、推文和精美的图标都像幌子。