不可复制的“去IOE”

“IOE”并不当代表IBM、Oracle和EMC三家国际品牌的IT厂商，而是特指：“I”是IBM的缩写，指的是IBM小型机;“O”是Oracle的缩写，指的是Oracle数据库;“E”是EMC的缩写，指的是EMC存储设备。这里的“IOE”架构为针对传统行业企业关键应用而设计，基于向上扩展(Scale-up)技术高端设备以及围绕着它们开发的大型数据库和商业中间件。

对于绝大多数企业来说，不仅要了解自身的技术需求是否合适采用“去IOE”技术，还需要拥有庞大的技术团队，并具有自我试验的精神和决心，但这只是效仿阿里巴巴“去IOE”的必要不充分条件。

一旦企业用户效仿阿里巴巴选择分布式+自行开发开源系统，就意味着它将从此迈入孤独之旅，软件的开发将没有可以借鉴的经验，也没有战略合作伙伴。此外，貌似通过开源社区讨论对技术可控，但软件的可控性实际上要低于硬件的可控性，一旦开发核心人员发生变故，整套系统的开发成果都将有付诸东流的风险。

“去IOE”到底是节省成本的命题还是成本转移的命题，也是值得企业用户推敲的。
最近，“去IOE”风声正劲。

阿里巴巴集团高调宣布今年“去IOE”成功，引发互联网行业甚至传统行业企业的热议：一、现在已经采用的IOE系统是否要效仿阿里巴巴进行替换?二、未来采用的系统是否不再优先考虑“IOE”架构?

企业用户要想获得这两大问题的个性化答案，其实还需要对这背后隐藏的若干潜在问题进行思路梳理。问题无外乎集中在如下几点：“去IOE”到底指的是什么?阿里巴巴为什么要“去IOE”?“去IOE”对于企业用户尤其是具有一定规模的企业来讲是否普遍适用?未来系统的选择是集中式还是分布式，商用系统还是开源系统?IOE系统的成本是否就高于非IOE系统，可控性是否就劣于后者?IBM、Oracle和EMC企业的产品是否代表的就是专有昂贵的集中式系统?

什么是“去IOE”

当业界热议“去IOE”时，首先需要给“IOE”一个相对明确的定义。实际上，“IOE”并不当代表IBM、Oracle和EMC三家国际品牌的IT厂商，而是特指：“I”是代表IBM的缩写，指的是IBM小型机;“O”是Oracle的缩写，指的是Oracle数据库;“E”是EMC的缩写，指的是EMC存储设备。这里的“IOE”架构是针对传统行业企业关键应用而设计的，基于向上扩展(Scale-up)技术高端设备以及围绕着它们开发的大型数据库和商业中间件。

因此，如果将“去IOE”简单地理解成去掉三家国际品牌IT 厂商无疑是误读。这三家企业作为商用产品提供商，在互联网普遍推崇分布式与向外扩展(Scale-out)技术、开源软件、云服务中也一直处于活跃的态势。比如EMC的VMware是x86架构服务器云计算的基础，其公有云存储服务也开展得风生水起;开源分布式数据库MySQL实际上隶属于Oracle;IBM一直是开源软件的重要支持者与贡献者，其Power服务器也不再仅仅是拥有强大Scale-up能力的专有小型机的代名词。PowerLinux开始强调Scale-out分布式能力和对开放的系统的支持，而近期成立的OpenPOWER联盟更是开放了POWER内核IP授权，Google的加盟也使得Power未来在互联网行业的迅速推进成为可能。明年POWER8芯片的问世或将使得业界对Power服务器的变身刮目相看。

“去IOE”的试验精神

阿里巴巴集团从2010年开始的“去IOE”运动耗时3年，经过1.7万名内部技术人员的努力，在今年高调宣布“去IOE”成功。据悉，除了支付宝完成了“去IE”目前依旧采用Oracle数据平台，阿里巴巴最大的现金流结算系统也完成了“去O”的工作，基本实现了“去IOE”的既定目标。

这里的一组数字值得关注，即耗时3年和1.7万名人员，阿里巴巴无疑将自身作为风险极高的“去IOE”创新试验品，下定决心才有了现在的成果。众所周知，在国外，Google、亚马逊等代表性互联网企业根本就不存在“去IOE”问题，因为它们构建系统之初从小规模起步日渐发展到超大规模，采用Scale-out的分布式系统是其“路径依赖”的结果。而“IOE”的系统架构则依据传统企业对IT的需求，基于Scale-up技术的高端设备以及围绕着它们开发的大型数据库和商业中间件。

阿里巴巴后来总结“去IOE”是“技术门槛很高、技术风险很大、水很深”的技术改革，敢冒如此风险的首要原因就是，考虑成本可控、技术可控等因素，不愿继续增加成熟商用系统以满足阿里巴巴特别是淘宝爆炸式业务增长的架构需求。由于其中的特殊性和特定性，这一过程虽然具有示范效应，但却有着太多不可复制的底层技术细节。比如互联网交易系统对数据一致性要求低于传统银行，但任何交易都存在数据复杂性与一致性的协调问题。因而虽然阿里巴巴采用分布式架构处理部分交易系统，但也需要对分布式开源数据库进行大量定制化改造。

一些具有一定技术规模的大型企业也曾经尝试“去IOE”，但在实施过程中出现技术反复，这其中甚至包括技术实力雄厚的电信运营商。因此绝大多数企业不仅要了解自身的技术需求是否合适采用“去IOE”技术，还需要拥有庞大的技术团队，并具有自我试验的精神和决心，但这只是“去IOE”的必要不充分条件。单凭这几点，企业效仿阿里巴巴将现在已经采用的“IOE”系统进行替换，就是风险极高的事。换句话说，阿里巴巴的“去IOE”运动是不可复制的。为此，多数企业对阿里巴巴“去IOE”运动思考落脚点开始集中在，未来将要采用的新系统是否不再优先考虑“IOE”系统?

“去IOE”的实质

阿里巴巴为什么要“去IOE”?因为集中式部署很难适应互联网大规模应用对扩展性的要求，与其说是“去IOE”，更不如说其实质是分布式架构+开源系统替代了集中式架构+商用系统。

众所周知，IOE架构有效地支撑着绝大多数非互联网企业的关键业务。但大型企业自身技术的逐渐成熟，尤其是技术团队自主开发能力的增强，使得部分企业认为对大型IT厂商依赖过多，成本偏高，技术上逐渐产生依赖感，如何在未来新系统中实现技术可控与成本可控成为“去IOE”思想产生的重要原因。

分布式架构+开源系统是否就意味着技术可控值得推敲。原来的软件设计使得早期的IT系统强调单机可靠性和单机性能，但随着云计算的崛起，软件层面的可靠性、可扩展性设计降低了业务对底层服务器单机的可靠性和性能的要求。为此，IBM Power服务器也在不断变化。在拥有强大Scale-up技术的基础上，Power开始逐步淡化小型机形象，强调其在Scale-out上的分布式能力。实际上，IBM引以为傲的“Wston”系统就是由90台Power 750服务器构建的处理平台。而在最新一期HPC500强排行榜，就有16套Power系统上榜，其集群能力与x86服务器相比并无伯仲之分。

在开源系统和商用系统的博弈之中，企业需要考虑方法论问题，即需要考虑一个系统的功能性需求和非功能性需求。在企业新业务新系统的创新中容易首先考虑功能性需求，即创新的系统是否能够解决当下的问题。但当其满足需求之后，企业将很快面临非功能性需求的压力，即如何构建一套稳定的系统。有多少人员能够维护好开源系统，不断进行开源中的Bug修改，按照系统的新要求加入新的功能并不断优化。

这恰恰就是商用系统存在的价值，毕竟系统从特定条件下的“可用”到能够向其他企业推广商用，这其中的门槛很高，商用软件用户可以通过与商用系统厂商的战略合作，了解其他类似用户的做法，获取经验防患未然。因此，一旦企业用户效仿阿里巴巴选择分布式+自行开发开源系统，就意味着它将从此迈入孤独之旅，软件的开发将没有可以借鉴的经验，也没有战略合作伙伴。而且，貌似通过开源社区讨论对技术可控，但软件的可控性实际上要低于硬件的可控性，一旦开发核心人员发生变故，整套系统的开发成果都将有付诸东流的风险。

成本可控是“去IOE”的另一重要原因，但实际发生的也许只是成本的迁移。企业投资购置成熟高端设备和商用中间件，可以只关注业务的创新，而功能的实现、扩展、优化、安全的保障等都由商用系统厂商交付。如果企业采用低端分布式设备和自行开发开源软件，确实降低了初始投资，但却转移了成本。

阿里巴巴在“去IOE”中就谈到，原来只需要几十台小型机，现在却要面临数千台x86服务器，必须重新架构全新的运维体系把这种复杂性对上层进行“封装”。 如果企业此时又选择了自行开发开源软件，固然再次节省了软件投资，但实际成本又将转移到自身技术人员队伍的建设上，比如阿里巴巴就拥有1.7万人的庞大技术团队。因此，“去IOE”到底是节省成本还是成本转移，也是值得企业用户推敲的。