云原生精英的网络效应

从技术的角度来看，我们正处于一个有趣的时代。云，我们指的是一种做事的方式——而不是一个物理位置，它在云原生公司和传统供应商（其中许多是巨头）之间造成了巨大的鸿沟。

这些巨头中只有少数能够走到另一边。

原因有很多，他们缺乏改变的基因，他们希望保护那些看起来有利可图的旧收入来源，因为这些收入来源不再需要投资，他们错误地看待问题（例如他们与亚马逊之间的竞争）。这些原因单独或共同地削弱了他们做出关于其业务的创新和艰难决策的意愿。还有一个值得注意的原因——他们无法控制的原因。

云原生精英的网络效应。

我们所说的这是什么意思？首先，云原生公司会被其他云原生公司所吸引。这导致了集成、创新和新的最佳实践。它不是有意为之，而是在实践中创造了一个巨大的护城河，随着每次额外的集成而变得越来越宽阔和更深。其效果是排斥传统供应商，他们根本无法以足够快的速度将基于POSIX的接口重写为RESTful API以进行竞争——因此他们越来越落后。

前几天，当我们对Accel 的 Open100进行一些分析时，我们亲眼目睹了这一点。我们假设该列表上的许多公司都发布了与 MinIO 的集成。事实上，其中 75% 的公司确实如此。考虑到他们在语言框架部分有 6 家公司，这是一个非常高的比例。这告诉我们，真正的云原生公司以极高的速度与其他真正的云原生公司集成。

为什么？

• 首先，因为它很容易。RESTful API，特别是 S3，是云原生世界的通用语言，就像 SQL 是数据库世界的通用语言一样。这意味着摩擦力有限。MinIO 流利地使用 S3——因为我们对数万家公司使用它。是的，你没看错——因为 MinIO 是在 AGPL v3 下开源的，我们的采用率已达到数万家组织。如果存在 S3 错误——我们会听到，通常是立即听到。这让我们有信心说，我们的 S3 兼容性比 AWS 本身以外的任何人都要好。
  
• 容器化和编排也发挥着至关重要的作用。这些是云原生精英的基石，也是 MinIO 自诞生以来就一直所了解的。这是我们诞生的世界，因此，我们一直并且将继续不懈地投入，以使该功能无缝衔接。因此，容器化和编排是 MinIO 的默认部署配置。我们超过 64% 的实例都是容器化的，几乎 50% 的实例都是通过 Kubernetes 管理的。如果你不是软件定义的——你将永远无法达到这些水平，如果你是一个设备，你可以忘记它。
  
• 云原生世界共同优化性能和规模。这是云原生的一件事。大多数传统技术只优化其中一项。云原生世界寻求以规模化方式提供性能。SAN 和 NAS 供应商就是完美的例子。有些可以提供性能——但很少有可以提供规模。没有一个可以同时提供两者。
  
• 云原生世界是自动化的。我们上面讨论了 RESTful API，但自动化的概念在云原生世界中根深蒂固，云原生精英期望能够随意自动化。HTTPS/RESTful API 是 Kubernetes 世界中应用程序之间通信的基本方法。例如，Istio 和 Envoy 基于 RESTful API 端点管理服务发现和路由。传统的 SAN/NAS 系统不适合这种模型——它们的专有工具有意不与开放标准集成。
  
• 如果云原生有一个粘合剂类别，那就是可维护性——能够仅用少数（甚至只有几个人跨时区管理）人员来管理庞大的基础设施。云原生精英非常重视这一点，并寻求其他可以提供这一点的公司。你可以在一个多租户、PB 级、对象存储即服务实例中指派一个人负责，或者你做不到。如果前面提到的需要一个由 6 人组成的团队来负责安全、网络、驱动器、CPU、弹性、SLA、停机时间、升级等，那么对于云原生公司来说，该解决方案是“不可维护的”。该功能需要在不牺牲控制或粒度的情况下，具有操作效率、可管理性、透明性和简单性。
  

还有一件事值得注意——云原生世界越来越多地摒弃正式的商业合作关系，而选择工程合作关系。在云原生世界中，开发人员是核心驱动力——而不是业务开发团队。MinIO 仅与其集成的少数公司建立了正式的合作关系。我们，就像许多云原生精英一样，是开源的（GNU AGPL v3）。OEM 目的需要合作伙伴关系——但不需要创建集成、教程或文档。这些事情会自然而然地发生，没有摩擦，而且所需时间只是传统供应商之间建立“传统”合作伙伴关系所需时间的一小部分。这就是为什么真正软件定义很重要——因为你的网站上有一个下载按钮。

结果是一个拥有自身非常强大的引力的生态系统。它拥有的参与者和技术越多，其吸引力就越强。它只会越来越强大。
下载 MinIO 并加入云原生精英。