什么是真正的软件定义

这篇文章最初出现在 Container Journal。

术语“软件定义存储”在供应商社区中被广泛误解。虽然行业和财务分析师都知道软件定义是存储行业的现在和未来，但无法做出区分的客户可能会发现自己拥有一个基于硬件或设备的解决方案，无法完全满足他们的需求，也无法帮助他们实现其业务目标和组织目标。

Kubernetes 正在改变这个领域的一切，因此了解什么是真正的软件定义至关重要。

首先，商业模式与软件定义之间没有关系。它们完全无关。当一家公司声称其x%的收入来自软件时，这只是一个针对财务分析师的会计术语。仅此而已。我们在“云收入”方面看到了同样的现象；就像组织仅仅因为与云有关就并不一定是云原生一样，它们仅仅因为从软件中获得收入就并不一定是软件定义的。

真正软件定义意味着您的网站上有“下载按钮”。这意味着您的客户和/或社区可以在他们想要的任何硬件上下载并运行您的软件。“下载”这个词意味着您可以实际下载软件。在 Kubernetes 世界中，这意味着 YAML 文件和容器拉取，而不是 RPM 和 DMG。

软件定义意味着对硬件没有限制。要成为软件定义的，您的软件应该可以在各种设备上运行，而不仅仅是少数几款。并不是每个人都会拥有一个小于 100 MB 的二进制文件，并且可以安装在 RaspberryPi 或 5GPOP 上，但要称自己为软件定义的，您需要在商品硬件上运行，而不是在需要由特定经销商或集成商仔细配置的“认证”解决方案上运行。

“下载”按钮也不意味着开源。您可以在网站上提供下载按钮并拥有专有软件。成千上万的公司都在这么做，存储行业也可以。话虽如此，开源是获得“软件定义”徽章的最佳方式，因为活跃的社区会通过将您的软件放到您无法想象的硬件配置中来扩展和推动您。

软件定义还需要简单的安装。如果您支持“下载按钮”，则需要有信心，您下载并使用的软件不会造成支持噩梦。这就需要简单性。存储应该与下载和设置 MongoDB 或 Cassandra 一样简单。VMware 认识到这一点，这也是 Data Persistence 平台围绕点击式部署对象存储的概念构建的原因。事实上，这是整个 Kubernetes 社区的核心：下载并运行，硬件选择仅仅反映了用例的要求和限制。

真正的软件定义存储是可以在任何平台上跨任何企业运行的软件，无论是在云端、数据中心还是边缘服务器。有趣的是，当你仔细想想，Amazon S3、Google Cloud 和/或 Microsoft Azure 只能在他们自己的基础设施上运行。它们是存储软件即服务，而不是软件定义存储。这就是 Outpost、Stack 和 Anthos 在他们自己的硬件上或在严格管理的“认证解决方案”上运行的原因，而不是在商品盒子上运行。这也是它们不能在彼此的云或现有的硬件上的本地运行的原因。

现代软件定义存储还需要 API 优先设计，可选的图形用户界面 (GUI)，以及将自动化作为“一等公民”。如果 GUI 是唯一可用的界面（或唯一经过充分记录且功能完备的界面），那么您可能不是软件定义的。

最后，软件定义存储必须“容器化”，以满足当今基础设施在多个方面的需求。例如，软件定义存储应该可以跨异构硬件类型无缝运行。这考虑了硬件过时问题，但也考虑了经济因素。软件定义存储不应关心这些依赖关系。操作系统也是如此；容器化的软件定义存储可以在任何 Kubernetes 版本上运行，例如边缘的 K3s、数据中心的 Tanzu 或云中的 Azure AKS。

买家想要真正的软件定义存储，他们可以在任何地方、任何时间、针对任何工作负载、在任何硬件上运行。仅基于交付时间来混合和匹配硬件就具有巨大的价值。另一方面，传统的基于硬件或设备的存储供应商有动力推动专有系统和解决方案，并将客户锁定在他们的硬件和软件堆栈上。

我建议您仔细考虑这些要求，现在和将来都要考虑。我预计，除了少数档案用例之外，几乎所有需求都将要求软件定义存储提供的灵活性。这反过来应该促使您使用上述标准仔细审查任何潜在的存储解决方案。只有这样，您才能确定“软件定义”这个词是否被恰当地使用。