有机会与EMC公司高级软件部门负责人Amitabh Srivastava展开对话，他同时也是ViPR方案的首席架构师之一。
Srivastava并非出身于存储技术——事实上他过去在微软公司中一直从事计算/服务器方面的工作——但借助在创建Azure云产品过程中积累到的经验，他已经非常善于解决存储及数据领域的难题。
创建一套动态且敏捷化的存储环境绝非易事，而且目前还没有成熟的标准化解决方案。存储机制以及由其承载的数据非常关键，而正如我的个人观点，其长效持久性则是重中之重。计算资源在规模上可以进行缩放，但数据却往往只增不减而且必须始终存在。数据分析机制的作用只是在证实用户对数据的长久需要程度，因此我们需要认清这一残酷现实：存储工作从来就不是一件轻松或者静态的工作……它本身跟敏捷特性根本搭不上边，我们能做的只是通过各种方式让它看起来更敏捷。
大家可以轻松转移计算工作负载，要实现这些迁移工作也不必涉及太高深的网络配置变更。但移动大量数据则非同小可，且无论采取哪种移动速度都必然让技术人员劳心伤神。
企业存储体系愈发复杂
大型企业存储环境属于异构环境，同时采用两家供应商的策略非常普遍。虽然有时候能遇到诚实守信的供应商，但通常情况下不同阵列在容量与用例方面都存在巨大差异。就在三到四年之前，我以为整个行业正在向通用型存储阵列迈进。
然而就目前的情况来看，我们正处于一个空前利基且闭塞的时代之下。随着全闪存阵列方案、商用硬件以及全新业务需求的出现，行业环境正变得越来越复杂。
存储技术团队需要一种通用的融合型方式对这些异构环境加以管理。
每个人都希望能以理想、廉价且快速的方式搞定工作，资金预算仍然相当紧张，员工人数也止步不前甚至有所缩水。有趣的是，通过与同龄人们的交谈，我发现阵列产品的发展速度似乎有所放缓、更新周期也开始延长。
EMC的ViPR正是希望解决以上这些难题。
大家能把新的存取协议直接部署在现有及持久性数据之上吗?大家能通过这种方式在不迁移PB级数据的前提下启用新协议吗?大家又能否确保现有应用程序与新应用程序在不涉及大规模重写的情况下使用原本的数据?
在上面的例子中，存取协议属于一种对象——对于某些人来说对象存储像是一种宗教。在他们看来，“所有存储内容都应该是对象，为什么要搞什么转换层?”遗憾的是，生活不可能像理想中那么简单。
如果大家手头有很多遗留应用在使用并生成数据，那很可能一方面出于保护投资的考虑而希望继续运行这些应用、另一方面却又打算利用新应用深入发掘数据价值。这种思维对于很多保守的技术人员来说无异于邪门歪道，但却又是当下现实的直接反映。如果大家从零开始进行规划，那么全面普及对象存储当然可行;不过对于已经保有大量数据的用户，想在短时间内将其转换为对象存储机制根本无法实现。
ViPR则能让大家的现有文件存储机制实现文件及对象访问。Srivastava也谈到了块机制，但我始终不能理解用户要怎么把一台原始块设备通过有意义的方式转化为对象机制。如果下次有机会，我一定详细问个究竟。
但在媒体与娱乐领域，我认为这种功能还是非常实用的;事实上，我预见到它能在给工作流带来的效率提升的同时保证资产可通过传统方式进行获取及编辑。这样我们就能将拥有丰富元数据的对象付诸播放，且无需对现有存储环境加以变更。
Srivastava还讨论了在现有存储机制中使用HDFS的可能性，例如允许分析工具在不移动数据的情况下完成工作。这个点子很有吸引力，但在性能、锁定等方面还存在诸多挑战——或者说颇具挑战性。
他勾勒出这样一个新时代：数据具备持久性，但却能以无需复制的理想方式加以使用，容量不够时直接购买更多存储硬件即可，这实在如梦幻般美好。但我认为永远不可能出现一套能解决所有难题的完美协议;多协议数据访问机制才是可行的方案。即使是在所有信息都成为对象的条件下，不同API与指令集之间仍然会存在竞争关系。
要说ViPR计划中比较现实的部分——我所谓的现实是指我自己目前能够看到的需求——在于控制层的抽象化以及使其具备与所有阵列相同的外观与操作方式。然而在Control Center引发恶评之后，我们还能相信EMC会给存储管理工作带来真正的便捷性、持久性以及可扩展性吗?
Srivastava当然听说过关于Control Center的所有情况，因此我希望他能了解我们的痛苦与绝望……尽管并无过硬的实证，但大家的意见同样足以说明问题。
难题接踵而至
EMC公司也已经承诺ViPR将采取开放式路线。我要问的是：如果有人借助你的API打造出比ViPR更优秀的ViPR类产品，怎么办?
Amitabh面对这个问题倒是神情自若。他声称EMC不会将API用于获取竞争优势，如果有人能比EMC自己拿出更好的方案，那么胜者为王并无不妥。很明显，他对于EMC技术团队充满信心，颇有舍我其谁的气魄。就我个人看来，可能会选择可插拔的模块化存储架构，这样就能在不造成中断的前提下进行设备更换。但愿他真能做得比我想象中还好。
ViPR将逐渐成为一套全新生态系统的中心，EMC公司也确信只要项目稳步进行、自然会有大量开发人员为其创建相关工具。他们也确实在积极为ViPR寻求开发商及新兴企业合作伙伴。
相对于编写工具来管理特定阵列，我们更应该可以编写一套足以管理数据中心内全部存储设备的工具。要实现这个目标，我们显然需要依靠EMC或者其它存储供应商推广对应插件来实现ViPR对特定阵列的管理。
其它存储供应商真会利用ViPR管理自家的阵列，从而提升ViPR的市场价值与用户认可程度?还是出于削弱对手的目的让EMC独力支撑这套新方案?这个嘛，至少NetApp已经站在了支持阵营当中。坦白讲，我还没时间研究OnTap版本，但这很可能会是ViPR碰上的头一个钉子。另外，ViPR控制层需要随着多种供应商的方案版本进行更新，这又是另一大难点。
不过已经有越来越多的存储供应商在考虑如何将自家存储方案整合至虚拟化堆栈当中，而控制功能的持久性与上市时间就成了获得成功的关键。EMC公司完全可以借助这个机会帮助ViPR铺平道路。
举例来说，如果我是一家新兴企业的管理者，那么ViPR能迅速帮我在新设备上实现管理能力。我可以将注意力集中在存储功能与设备容量上，而不必再为其它管理事务分神。
因此EMC的方案获得肯定的机率还是很高的，不过目前还没法保证其必然获得成功——而且其最终结果也要看其它供应商的态度。我们需要能帮助自己实现规模化存储管理、维持较低运营成本且无需从头创建的工具。
激烈而混乱的竞争态势
其它供应商到底会做何反应?从最悲观的角度看，我们很可能迎来一场史无前例的混乱竞争，最终胜出的则是能打造对第三方设备支持能力最强、范围最广的供应商。如果其它厂商尚未做出尝试，那么EMC先声夺人的战略也许能让他们知难而退、做出妥协。然而如果某家软件厂商已经推出或者公布了类似的方案，那么面对EMC的步步紧逼、出于市场平衡的需要，其它方案必然是不能上也得上了。ViPR的命运真可谓成也EMC、败也EMC。
EMC公司已经公开承诺了方案的开放性，这可能意味着短期内他们确实会以一定业务成本作为代价帮助竞争对手。我认为EMC必须以对待VMware的严肃态度对待ViPR;而且就目前看来，VMware与NetApp的合作关系似乎比二者同EMC的往来更加密切。
对了，EMC当然也得推出GA版本，或许再来个回炉精炼，这样其严谨的敬业精神与服务态度自然会令用户折服。
最后，让我们忘掉软件定义之类的话题，也别再讨论对现有条款的重新定义。一切术语都是虚妄，我们用户需要的是所谓BSM&C方案，也就是“更好的存储管理与功能方案”。别被绕晕了，请千万记住自己的本质需求。
