云原生精英的网络效应

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

这些巨人中只有少数会到达另一边。

有多种原因，他们缺乏改变的 DNA，他们想要保护看起来有利可图的旧收入流，因为他们不再需要投资，他们错误地看到了问题（例如他们与亚马逊）。这些原因单独和共同削弱了就其业务做出创新和困难决策的意愿。还有另一个值得注意的原因——一个他们无法控制的原因。

云原生精英的网络效应。

这是什么意思？好吧，对于初学者来说，云原生公司被其他云原生公司所吸引。这导致了集成、创新和新的最佳实践。它不是有意而为，而是在实践中创造了一条巨大的护城河，随着每一次额外的整合，护城河变得越来越宽。结果是排除了遗留供应商，他们根本无法以足够快的速度将基于 POSIX 的接口重写为 RESTful API 来竞争——因此他们越来越落后。

前几天我们对Accel 的 Open100进行一些分析时，我们亲眼看到了这一点。我们假设该列表中的许多公司都会发布与 MinIO 的集成。事实上，他们中有 75% 的人这样做了。考虑到他们在语言框架部分有六家公司，这个数字非常高。这告诉我们，真正的云原生公司与其他真正的云原生公司的整合速度非常快。

为什么？

• 对于初学者来说，因为它很容易。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 系统不适合这种模式——它们的专有工具有意不与开放标准集成。
  

• 如果云原生有一个胶水类别，那就是可维护性——只需少数几个人（甚至几个人就可以跨时区管理）管理大规模基础设施的能力。云原生精英非常看重这一点，并寻求其他可以提供这一点的公司。您可以让一个人负责多租户、千万亿次规模的对象存储作为服务实例，也可以不这样做。如果上述需要一个六人团队来照顾安全、网络、驱动器、CPU、弹性、SLA、停机时间、升级等，那么该解决方案对于云原生公司来说是不可“维护的”。该功能需要高效、可管理、透明且简单——同时不牺牲控制或粒度。
  

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

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