围绕对象存储构建护城河

大多数开发人员、工程师、架构师和 DevOps 人员都知道 MinIO。但并非所有人都知道我们唯一做的事情是软件定义的对象存储。我们不做文件或块存储。我们不提供服务，而是自托管的。

我们的重点是单一的。

结果是，我们的对象存储在客观上，基于采用率、奖项和客户反馈，是世界上最好的。我们每天的 Docker 拉取量接近 100 万次。我们赢得了所有分析师奖项和 Datanami 的读者选择奖。我们还赢得了 Gartner 的 Peer Insights 客户选择奖.

但我们对对象存储的单一关注还有一个方面，那就是我们所做的一切外围工作，以增强开发人员体验，这些工作从未被分析师评级或在读者调查中被提及。

这些努力，其中一部分列举如下，共同构成了围绕核心对象存储的大量功能护城河。因此，MinIO 与行业其他公司之间的距离，尤其是那些将对象存储作为副业的公司，正在不断扩大。

这些“外围”组件对于卓越的开发人员体验至关重要，因为它们增强了开发人员可以做的事情，开发人员可以完成这些事情的时间以及开发的架构/基础设施的可维护性。

在许多情况下，如果这项工作没有正确实施，应用程序将无法正常运行。这需要故障排除、连接器、驱动程序等。如果编写代码的开发人员离职，这将引入另一套不断累积的问题。

以下是一些例子

操作系统工具和 SDK - 当我们最初开始将 MinIO 作为 AWS 的直接替代品进行开发时，我们显然花了大量时间使用 AWS SDK。不幸的是，它们是 AWS 的事后诸葛亮，从文档质量、可访问性和完整性方面可以看出来。我们认识到，这不仅会限制 AWS 的增长速度，还会限制 MinIO 的增长速度。

因此，我们决定投资编写自己的 SDK。我们正在构建一个最精良的服务器，我们需要SDK 和 API来匹配这种精良的工艺水平。

你可以在这里找到我们的工作。它包括 .NET、Golang、Haskell、Java、JavaScript 和 Python 的 SDK。Rust 正在开发中。 

这些 SDK 由于与 S3 兼容，并且优于 AWS 提供的 SDK，因此成为行业标准 - 即使对于那些仅在 AWS 的 S3 服务内工作的开发人员也是如此。

我们也将其精良的工艺扩展到操作系统工具。最值得注意的是类 Unix 的 mc 接口，但我们也为微软提供了工具。

最终产品是一套核心文档和工具，开发人员可以放心地使用。这相当于为 S3 作为协议的加速打开了氮气开关。我们继续在这一领域投入巨资，并将继续投入，直到不再需要为止。

身份和访问管理 - 有许多 LDAP 实现。Active Directory 当然是最受欢迎的，但还有 OpenLDAP、IBM Tivoli 和 Apache Directory Server 等等。还有 OpenID - 它也有数十种实现。

MinIO 对其对象存储进行了投资，以便所有这些都可以在云端或本地工作。许多这些解决方案不使用 S3 API 进行 IAM 或甚至 STS 令牌。MinIO 的 IAM以 AWS 身份和访问管理 (IAM) 兼容性为核心构建，并将该框架提供给应用程序和用户，无论其环境如何 - 在不同的公共云、私有云和边缘提供相同的功能。

MinIO 通过支持流行的外部身份提供商（如 ActiveDirectory/LDAP、Okta 和 Keycloak）扩展了 AWS IAM 兼容性，允许管理员将身份管理卸载到他们组织的首选 SSO 解决方案。

这是一个关键主题，将会重复出现 - MinIO 连接到外部世界，但拥有专为 MinIO 定制的启用技术，并针对高性能对象存储的需求而设计。你绝对可以使用市场上最广泛部署的选项，但我们致力于将这些最佳方案直接构建到产品中。

此外，MinIO 提供了多种方法来实现这一点 - 同样，以开发人员为目标，迎合他们的偏好。例如，MinIO 的 IAM 旨在支持手动（静态）和编程（动态）的应用程序为中心的身份管理。对于手动身份创建，客户可以使用 MinIO 控制台。对于编程身份创建，客户可以使用 MinIO 的 `mc` 命令行界面。

往往是小事才重要。例如，MinIO 建议每个应用程序创建一个用户，以减轻与泄露的长生命周期用户凭据相关的安全风险。因此，MinIO 不会限制可以管理的用户数量，用户数量对系统性能的影响可以忽略不计。

这个列表还在继续，我们强烈建议您访问我们的身份和访问管理页面，以真正了解这项工作的深度。

密钥管理和密钥加密 - 随着对象存储的普及以及存储在其上的数据的增加，遇到了某些挑战。其中一个挑战与密钥加密有关。传统的密钥管理服务 (KMS) 无法处理数十亿个密钥。在进行每对象加密时，这就是挑战所在。

虽然MinIO 支持所有主要的 KMS，但我们还开发了一个用于密钥加密的原生选项。MinIO 的密钥加密服务 (KES) 是一种无状态且分布式的密钥管理系统，适用于高性能应用程序。它旨在运行在 Kubernetes 内部，并将加密密钥分发给应用程序。它是 MinIO 服务器端对象加密 (SSE-S3) 所必需的。

KES 充当 MinIO 集群和外部 KMS 之间的中间人，根据需要生成加密密钥并执行加密操作，不受 KMS 限制的影响。因此，仍然有一个中央 KMS 保护主密钥，并在基础设施内充当信任根，但从开发人员的角度来看。KES 通过消除为每组应用程序启动 KMS 的需要，简化了部署和管理。相反，应用程序可以向 KES 服务器请求数据加密密钥 (DEK)，或者要求 KES 服务器解密加密的 DEK。

我们正在扩展 KES，使其成为一个完整的 KMS，敬请关注。同样，开发人员有选择权，MinIO 不会把你锁住，它只是提供选择。

负载均衡 - 现代应用程序堆栈可能出现问题的另一个领域。在现代数据处理环境中，通常会有数百到数千个节点同时访问存储服务器。传统负载均衡器，为跨互联网提供 web 应用程序而构建，在这里处于劣势，因为它们使用传统的 DNS 轮询技术进行负载均衡和故障转移。这些基于 DNS 的解决方案在面对现代需求时，扩展性并不强。

MinIO 与各种软件定义的负载均衡器协同工作，例如 NGINX、HAProxy 和 Envoy Proxy。这些负载均衡器功能齐全，可以处理复杂的 web 应用程序需求，但并非为高性能、数据密集型工作负载而构建。

现代数据处理环境在每次运行时都会在计算节点和存储节点之间移动数 TB 的数据。虽然负载均衡器不应影响性能，但它们通常会在这些环境中造成性能下降，因为它们的总带宽有限，并且会引入额外的网络跳转。

MinIO 开发了它的 Sidekick 负载均衡器，通过采用 sidecar 方法来解决网络瓶颈。它作为每个客户端应用程序旁边的一个小型 sidecar 进程运行。这样，应用程序可以直接与服务器通信，无需额外的物理跳转。由于每个客户端都在共享无状态模型中运行自己的 sidekick，因此可以将负载均衡器扩展到任意数量的客户端。

在像 Kubernetes 这样的云原生环境中，Sidekick 作为 sidecar 容器运行。将 Sidekick 添加到现有应用程序中相当容易，无需对应用程序二进制文件或容器镜像进行任何修改。

同样，这些是我们为开发人员创建的选项，因为我们本身就是开发人员，我们知道拥有一个经过深思熟虑、功能齐全的产品的力量。

构建护城河

虽然改进开发人员体验是我们不懈努力构建世界上最好的对象存储的主要驱动因素，但也有一些其他的影响。

首先，每次我们添加这些功能时，我们都会说明一点，即对象存储本身仅仅是一个优秀产品体验的开始。我们在这方面的精湛工艺有据可循（从我们的 纠删码 实现到我们的 加密），但作为一个数据存储，我们对世界有着更全面的看法，而这种看法体现在这些扩展中。

其次，每一个额外的功能或扩展都进一步将 MinIO 与那些仅仅想在对象存储上“打勾”的供应商区分开来。这类供应商太多了。他们的主要产品是 SAN/NAS。这个市场不仅竞争激烈，而且正在萎缩。因此，这些公司跳上了对象存储的潮流 - 但事实上，他们并不真正重视它，这从他们的产品中就可以看出来。他们可能提供一流的 SAN/NAS，但随后又叠加了一个三流的对象存储。他们可能会告诉你，这种“统一”的产品是同类最佳 - 但开发者知道真相，即使老派的 IT 或财务人员无法做出区分。

在我职业生涯的早期，我在国务院为国务卿詹姆斯·贝克工作。他曾经说过一句话，我至今记忆犹新。这句话大致是这样的：“当你在冰淇淋里掺入粪便时，它仍然尝起来像粪便。”他的措辞可能更生动 - 但要点仍然是。如果你将好的与坏的混在一起，你会得到坏的。

我们对对象存储的每一次抛光 - 从 KES KMS 到我们的 SDK，都会在我们产品周围建立更深更宽的护城河，使其他竞争对手更难与我们竞争。每一个功能本身都是他们“力所不能及”的。

总的来说，这些只是创造了两类对象存储 - MinIO 和其他所有。我们希望您能体会到其中的区别。

一如既往，我们欢迎您的意见。加入我们的 Slack 或给我们发邮件至 hello@min.io。反之，您也可以 订阅我们的时事通讯，确保这些类型的文章每月都能出现在您的收件箱中。