软件定义的真正含义

这篇文章首次出现在Container Journal 上。

“软件定义存储”一词被供应商社区广泛误解。虽然行业和金融分析师都知道软件定义是存储行业的现在和未来，但无法区分的客户可能会发现他们基于硬件或设备的解决方案并不完全符合他们的需求或帮助他们实现业务目标和组织目标。

Kubernetes 正在改变这个领域的一切，这使得理解真正由软件定义意味着什么变得很重要。

首先，商业模型和软件定义之间没有关系。他们完全没有关系。当一家公司声称其收入的x % 来自软件时，这是专为财务分析师设计的会计名称。而已。我们在“云收入”方面也看到了同样的现象；正如组织不是云原生的，只是因为它们与云有关，它们也不是软件定义的，仅仅因为它们从软件中产生收入。

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

软件定义意味着对硬件没有限制。要成为软件定义的软件，您的软件应该在多种设备上运行，而不仅仅是少数设备。不是每个人都有小于 100MB 的二进制文件并适合 RaspberryPi 或 5GPOP，但称自己为软件定义的要求是您在商品硬件上运行——而不是在“认证”解决方案上运行，这些解决方案必须由选择一组经销商或集成商。

“下载”按钮也不假定是开源的。您可以拥有这样的下载按钮并拥有专有软件。数以千计的公司这样做——存储行业也可以。话虽如此，开源是获得“软件定义”徽章的最佳方式——因为一个活跃的社区会通过将您的软件置于您无法想象的硬件配置中来扩展和推动您。

软件定义也需要简单的安装。如果您支持“下载按钮”，您需要确信您的软件在下载和使用时不会造成支持噩梦。这要求简单。存储应该与下载和设置 MongoDB 或 Cassandra 没有什么不同。VMware 认识到了这一事实，这也是数据持久性平台围绕单击和部署对象存储的概念构建的原因。事实上，这就是 Kubernetes 社区的全部前提：下载和运行——硬件选择仅反映用例的要求和约束。

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

现代软件定义存储还需要 API 优先设计，具有可选的图形用户界面 (GUI) 和自动化作为“一等公民”。如果 GUI 是唯一可用的界面（或唯一记录良好且功能齐全的可用界面），那么您可能不是软件定义的。

最后，软件定义的存储必须“容器化”以满足当今许多不同维度的基础设施需求。例如，软件定义的存储应该跨异构硬件类型无缝工作。这说明了硬件过时，但也考虑了经济性。软件定义的存储不应该关心这些依赖关系。操作系统也是如此。容器化软件定义存储在任何 Kubernetes 风格上运行——例如，边缘的 K3s 或数据中心的 Tanzu 或云中的 Azure AKS。

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

我鼓励您现在和将来仔细考虑这些要求。我的期望是，除了少数档案用例之外，几乎所有需求都需要软件定义存储提供的灵活性。反过来，这应该触发使用上述标准仔细检查任何潜在的存储解决方案。只有这样，您才能确定软件定义的术语是否得到适当应用。