北京科技新闻网移动版

十二年前，存储软件对硬件的依赖性很强。现在，存储软件与存储硬件既可以集成一体化，也可以完全解耦合实现软件定义的方式。针对用户TCO整体的变化，戴尔易安信可以提供一体化的软硬件方案，也可以提供基于开源或容器的创新方案。

企业用户只需要关注数字资产的本身价值，针对数据的存储、访问、安全等方面，戴尔易安信可以基于用户需求提供统一、高效、创新的数据管理与数据存储整体方案。

值得关注的一个趋势是，现在的企业用户针对云原生的技术需求越来越多。

Pivotal Container Service (PKS) 针对云原生的用户需求，在针对用户存储需求上可以提供更为敏捷的现代化方案。这都源自用户自身开发方式、运维方式的转变。

2018年末，AWS在也第一次改变了它多年以来对于混合云的态度，联合VMware推出了AWS outposts。

展望ECS的未来，戴尔易安信也会迅速跟上这一大趋势，发布基于Kubernetes的全新架构，这样ECS的存储引擎就会完全摆脱对于硬件限制，成为企业用户的存储核心部件。

从对象存储到流式存储，戴尔易安信早已开始研究和布局物联网下的全球存储技术领域的创新与走向。从2017年开始，在戴尔易安信中国COE的发展上，滕昱带领着一个新的团队，开始了全新的征程。

计算是原生的流计算，存储更需要原生的流存储与之匹配。这一切必然驱动着开源分布式流存储Pravega从诞生逐渐走向不久后的成熟。

Pravega取自梵语，意味“Good Speed

Pravega采用了分层存储架构，在分布式文件、对象存储基础上，提供了一层针对Stream的抽象。实现了冷热数据的分离，从而有效降低了数据存储成本，并与以Flink为代表的新一代流处理大数据处理平台无缝地完美结合。如下图：

在这样一个混合云、多云的时代背景下，ECS、Pravega、PKS等与时俱进的创新产品和平台，终究成为了云时代企业用户的存储基石。

在这十二年的职业生涯里，滕昱亲身经历了戴尔与EMC并购并真正融合在了一起。当初的坚定，也让他在戴尔科技集团的整体发展中得到了更大发挥。

目前来看，作为戴尔科技集团的重要业务群之一，戴尔易安信拥有行业领先的融合基础架构、服务器、存储和数据保护技术，助力企业实现现代化、自动化以及数据中心转型，为通过建立混合云、开发云原生应用和大数据解决方案实现业务转型提供了值得信赖的基础。

戴尔易安信为遍及180个国家不同规模的客户提供服务—从全球财富500强至中小型企业—并为客户提供业界全面的从客户端到数据中心、再到云端的创新产品组合。

也就是说，滕昱团队负责的ECS对象存储和最近发力的流存储，已经成为了戴尔科技集团旗下戴尔易安信在面向用户的混合云、多云，IoT等更为复杂的创新场景下重要的存储选择之一。

企业开发模式的整体思考

在混合云、多云之下，开源开发方式的发展，产品创新迭代的加快，这一切必然倒逼着企业开发模式必须不断变化。

尤其在踏上开源流式数据存储的新征程后，更需要对企业开发模式有着全面的整体思考。在滕昱看来，互联网开发更看重to C的敏捷开发，强调个人用户的体验，以用户试用来实现开发迭代的快速更新。但是，企业级的开发针对医院、银行、证券等行业用户，强调新技术、功能、工具等开发必须具备安全、可靠、稳定为前提，需要立足企业用户具备足够的承诺。

针对新技术的日新月异，企业级产品的开发也不得不面向敏捷开发，实现更多开发测试上的创新与进步。

其实早在2011年，戴尔易安信中国COE开发团队就开始全面转向了使用开源开发工具，对于Pravega这样的开源产品，则完全采用GitHub来管理托管开发的整套代码和流程。

更重要的是，针对企业级产品的子模块不绝对区分开发与测试工作，而是整合在一起成为一个工程师团队，在开发过程中就强调及早测试和测试覆盖率。在模糊了开发人员和测试人员分工之后，产品测试的人员也会涉及到对设计和代码审核，更高质量针对新功能设计测试用例，从代码产生的第一天就保证其质量。

所以从戴尔易安信的企业开发模式来看，在小范围上保持了敏捷开发的优势，在大范围上保证了企业开发的质量和整体的开发路线。实际上就是针对企业用户组织需要的质量、发布节奏和创新方面，可以用下面以“汽车、火车、轮船”三种开发模式来进行比喻。各有各的用处，也各有各的道理。

►►在“汽车开发模式”上，属于汇总修补升级程序，要求以最短的时间，针对产品软件打补丁、针对固件做优化。目的是一个稳定发行版本供所有用户升级使用。

►►在“火车开发模式”上，主要针对新功能的发行发布，需要在每年当中实现大的版本更新。

►►在“轮船开发模式”上，针对更为复杂的基础架构的改变，必然需要一个更长的时间与规划。当准备测试充分后，和“火车”计划做一个同步。

然后具体到每个功能模块，先做好本模块的质量控制，等达到设定的质量标准以后，由“火车”车长根据发布计划去选择在下一次“发车”时候可以搭上火车的功能。然后再针对性地做更大范围内的集成测试和“混乱”(Chaos Monkey)测试。