Pure Storage PortWorx问答：为什么要为存储插上数据策略的翅膀

答者为Pure Storage旗下PortWorx云原生业务部门副总裁兼总经理Murli Thirumale。而这篇问答的核心，在于解读组织机构为什么不仅需要存储策略、更需要制定数据策略。

记者：目前市面上有很多厂商都在为容器提供存储支持。具体的存储实现大体分为两种方法：其一，就是Dell-EMC的解决思路，通过CSI接口接入一套外部存储阵列；其二则是把云原生存储设施引入Kubernetes，相当于把存储视为另一种特殊的容器，即系统容器。虚拟机与容器的混合应用似乎也有不少优势，但在某些场景下二者似乎无法兼容，只能通过居间的抽象层加以衔接。所以在实际应用当中，我们基本上只能从中二选其一，没有什么回旋空间。您是怎么看待这个问题的？

Murli Thirumale: 虽然身为供应商，但我更想从客户的角度来回答这个问题。存储技术本身一直在不断发展，越来越偏向数据管理、甚至更进一步开始思考企业该如何以新的方式靠数据占得市场先机。

让我们回到20年前，那时候云计算浪潮才刚起波澜。云计算带来的最大变化就是把运营体系从资本支出转化为运营支出。但技术的发展也会同步推动底层硬件基础设施的变化，所以整个过程不只是对硬件基础设施的云化、也是对硬件的全面升级——于是思科Nexus架顶式交换机出现了，HCI超融合基础架构也出现了。

趋势来到下一阶段，SAP等软件厂商开始脱颖而出，代表着应用的时代正式来临。这一时期内的价值核心变成了应用程序和软件即服务。时至今日，应用与数据开始高度强调自动化优势，而这种自动化的实现载体就是容器化。

现在，大家在市场上搏杀所依靠的不再是谁反应快、谁行动早。相反，各方开始利用数据智能展开竞争——这也就催生出“数据是新时代的石油，数据是新时代的货币”这类我们耳熟能详的观点。

所谓的智能化，当然不止要求我们能充分运用自己的数据——受篇幅所限，这里我们就不多谈HDFS数据湖的数据挖掘话题了。相反，真正的核心是把自有数据同外部数据混为一体。举例来说，我们的一家客户负责开发COVID疫苗，他们的目标就是快速建立起数据科学模型。为此，他们需要将公开可用的信息同内部测试进行比较。只有把二者混合起来，才能真正产生有益于业务的洞见结论。我们再想想Uber，他们的核心业务优势也差不多，就是把公开可用的GIS（地理信息系统）数据、司机所在位置、以及乘客目的地混合起来。

所以在这样一段发展之旅中，无论是存储厂商还是企业CIO，都开始将关注重点从基础设施云化推进到应用程序自动化这个全新阶段。这也还不是终点，接下来的方向在于数据挖掘。人们需要想办法以或实时、或批量的方式获取洞见结论，也就是发展之旅的下一阶段。

那作为缺乏宣传噱头的底层技术之一，存储技术该如何增加价值，避免被扔进阴暗的地下室中、老死不见阳光的悲惨命运？这个问题得结合现实来看——在现实中，新时代正全面转向应用、人与DevOps。所以要在这样的背景下从容生存，存储就得发展出自己的数据策略。

所以我们不能总把视野局限在机架、机柜、机箱上，对吗？

当然。存储到底是干嘛用的？不光是要存储数据，还要帮助实现数据管理自动化。我们现在要做的就是把这些集中存储的数据释放出来，用以支持多云架构和多应用协同。但终有一天，存储行业必将走出挖掘数据内容、获取洞见结论这一步。

这样的前景又将给存储行业带来哪些影响？最直接的影响当然在于基础设施。如今，软件定义存储的市场份额已经被Kubernetes存储所取代。

所以，像我们PortWorx或者Robin.io这样的数据存储与数据管理厂商，都在致力于建立自动化层。我们开始使用Kubernetes、将数据从存储阵列中释放出来，进而把数据资源交付给云端不同应用间的各个容器。但就当下而言，数据管理仍然是我们最重要的业务内容。

在说起数据这个概念时，很多人觉得这就是一件事。但在我看来，数据其实包含五大基本面。如今，应用程序已经开始把数据当成服务来使用，所以应用层肯定在最上。这就引出了我提出的第一个基本面，数据库——也就是决定数据存储方式的机制。第二个基本面是数据搜索，即Elasticsearch。我把这些都当作服务来讨论，因为现实应用就是这样。第三个基本面是分析，它可以体现为Excel电子表格、也可以是Tableau或者其他更为传统的分析方式。第四个基本面，就是当下最热的AI与ML。为什么？因为它们会借助GPU与TensorFlow等技术的力量对数据进行解析。最后一个基本面就是流式数据，其中也包含消息传递。流式数据本身其实就涉及分布式数据、物联网乃至各类传感器之间的消息传递，所以我把它也归纳进流式数据范畴。

这五个基本面，实际对应着五种数据服务，而且直接指向一系列现代应用程序解决方案，分别是MongoDB、Elastic、Cassandra、Kafka与Spark。如今我们生活的时代已经不再是曾经那个Oracle与Sybase老死不相往来的世界，现在的基础设施云化才是大趋势，数据则全部存在于容器化应用程序之上。这，就是云原生的新形态。除此之外，数据在这五个子领域中都是以服务的形式进行消费的。

这看起来就像是堆栈。Pure这样的供应商以往只处于底层区位，但Pure正在努力上移、尝试接触服务部分。从您的阐述来看，Pure Portworx是打算“更上一层楼”喽？

不只如此，Pure的目标是渗透进所有层级。其实这些层级之间并不相互排斥，而Portworx就是我们把各项服务拼接起来的典型案例。着眼未来，我们也完全有可能建立起稳定存在的垂直切片，甚至直通到应用层去。

但您应该是会选择携手合作伙伴的方式吧？毕竟如果全部原研，那代码开发工作量也太大了。

确实，所以我认为CIO应该从行业的总体视角理解这个问题。我们肯定没法独力做成这件事，必须得借势而行。就像人们一直觉得Kubernets只是容器编排器——这个观点没错，也确实是Kubernetes的核心定位所在。

但时至今日，我认为Kubernetes的第二阶段已经到来，它开始逐渐转化为基础设施控制平面。从借助CNI编排基础设施来看，Kubernetes明显是想发展成一种多云基础设施控制平面。我自己也会使用Kubernets的CSI扩展并编排存储资源。PortWorx、StorageOS乃至Robin.io都是这样的定位。另外，Kubernetes未来还会使用KubeVirt来编排虚拟机，这也是一种正在逐步普及的新兴技术。虽然暂时只能算是个前景不错的技术概念，但我越来越相信计算资源最终也将被纳入Kubernetes的编排范畴。

这可真是振聋发聩的观点。前面的内容我都能理解，但您说计算资源最终也要归Kubernetes编排，这个……

就拿刚刚提到的KubeVirt技术为例，这个云原生计算基金会的孵化项目其实就是在利用Kubernetes编排虚拟机。在创建了虚拟机之后，我们就能像管理容器那样轻松控制。只是实际编排的对象不再是容器，而是虚拟机迁移、在虚拟机内部转移容器之类的操作。

目前这波趋势还处于起步阶段，但我觉得它代表着未来的潮流。听起来确实比较大胆，但我真心相信Kubernetes未来会取代OpenStack。OpenStack将会转化成其中的一个抽象层，帮助人们跨基础设施管理存储、网络和计算资源。而单看存储层面，则是由Cinder与Swift扮演类似的角色。

我的观点是，现在的OpenStack已经太过复杂、效果也一般，想要继续发展恐怕困难重重。当然，那150多家使用OpenStack的企业倒是信心满满，也确实为制定行业标准付出了不少努力。但在我看来，OpenStack的时代已经结束了。OpenStack的核心目标就是要成为基础设施的通行管理方案，这一点已经在OpenStack通过多云方式与Kubernets的协同中得到了实现。OpenStack实际上扩展了Kubernetes的编排能力，具体成果就是CNI、CSI乃至KubeVirt。

那您接触过Kubernetes参与数据中心IT资源构建的真实案例吗？

有啊。上一个时代，我们的世界由机器来定义，那个时候VMware在基础设施领域占统治地位。但现在的重心已经转向“即服务”，人们已经不再关心基础设施——一切都以服务的形式交付。那么，我们要如何缩短这条消费服务所经由的路径呢？答案就是容器与Kubernetes编排工具。

PortWorx就是个很好的例子。我们的买家并不是存储管理员，而是DevOps工程师。而随着产品的发展成熟，PortWorx数据服务的买家终将转化为业务人员。

您的意思是，Pure为消费者提供的不再是硬件设备或者软件方案，所以在实质上就完成了向服务交付者的转型？

没错，消费者现在消费的已经是服务了。所以人们才会把Kubernetes视为一种应用组织框架，使它成为一种面向应用的可消费服务。现在我们已经接受了基础设施即代码、软件即代码，最终也会接受数据服务即代码、乃至“即服务”即代码。

但您不一定要走这条路吧？毕竟Pure是一家根红苗正的存储厂商，费力把业务堆栈向上推进到“即服务”控制平面并提供服务级应用，对公司本身到底有什么好处？

我并不打算放弃数据管理业务呀。数据管理才是PortWorx的主要收入来源，而且数额还在不断增长。只是我们在去年9月又推出了全新产品，PortWorx Data Services。总体来讲，它属于一键部署式数据服务解决方案，囊括一系列精选而成的数据服务。到明年，其中涵盖的服务项目将达到12项或14项。

我们的分析表明，这些数据服务能够覆盖当前现代应用中的75%到80%。孤岛式的基础设施布局已成历史，现代多云环境才代表未来。我们所提供的，也必须是一套一键式解决方案。

初一上手，客户们只需一次点击即可轻松完成部署。在产品设计中，我们精心规划出各类运算符，目的就是降低数据库规模调整的操作难度。我们把Pure多年以来积累下的经验心得融入其中，制定出能满足大多数客户需求的默认选项。用户则根据需求随意下载，可以是容器化版本的Couchbase，也可以是容器化版本的Cassandra。我们会初步开放一套开源版本，后续也可能采用供应商的其他合作许可。

您不打算推出自主开发的Couchbase、Redis或者Kafka替代方案吗？还是说，您打算把产品设计成能直接使用Couchbase、Redis或者Kafka服务的设施体系？

没错，我们要做的就是一套数据库即服务平台。再讲得夸张一点，我觉得这就是个数据库应用商店。当我们打开手机、点开应用商店时，苹果会在其中列出各种常用的移动端软件。这就是一种典型的围墙花园生态设计，而我们的产品就是专攻数据服务的围墙花园。

但我们还想做得更多。我们不只提供数据库配置选项，还将帮助用户优化数据库并把它部署在多租户基础设施之上。结合实际经历，我们发现用户虽然知道如何运行Redis，但却不太清楚该如何选择适当的实例大小来优化IOPS。另外，用户也不擅长处理容器技术故障、切换到其他云环境或者处理迁移工作，这些都是我们想在服务中解决的现实问题。

下一步，就是立足整个生命周期实现数据库的备份与归档。因此，PortWorx Data Services决定重塑Kubernetes并把它当作服务管理器。毕竟业务部门的用户并不关心底层设施到底是不是Kubernetes、甚至可以完全没听说过Kubernetes——越是让用户感知不到这里面是Kubernetes，使用体验才会越好。

所以我们不会反复强调“我们用的是Kubernetes，是Kubernetes！”相反，我们只会告诉用户，他们可以随意使用Postgres端点、可以使用Redis端点、也可以使用Elasticsearch即服务。只有这样，我们才能把代表五大基本面的五种数据服务融合进统一的自助服务模型，进而让受众群体从DevOps工程师转变为业务人员。