去IOE化

1、什么是去IOE，去IOE的本质；
操作系统、中间件、数据库、服务器、存储
2、为什么要去IOE；
Scale out和Scale Up的问题。现在的客户，就是想Scale了，但是他们很痛苦，因为他们要Up。Up意味着要一个更大的处理能力的问题，有人逃向更高处理能力的小机。但有人逃向MapReduce，他们希望未来能够Scale out
1）性能不一定要靠硬件和商业软件去提升；
2）维护费用；
3）依赖性；
4）架构的灵活性和扩展性。

3、去IOE的适用性分析、可行性、风险
互联网应用；查询类应用；
互联网公司去“IOE”，有他们的特点，适合展示型、以读为主、海量数据的应用比较适合。

阿里巴巴使用Oracle最多的子公司是大淘宝，启用了全亚洲最大的Oracle RAC集群，硬件是最好的IBM小机集群，冷热备，有80多人ORACLE　DBA团队在维护、调优，但象阿里B2B网站仍然经常CPU负荷98%。后来招聘了能修改MySQL源码和Hbase源码的人才，软件上将Oracle数据库以开源的MySQL和Hadoop替代，Oracle RAC以Hadoop集群替代，硬件上以工业标准的x86服务器替代IBM小型机和EMC存储设备，才改善了性能问题。但是象支付宝的核心应用，还在ORACLE上面没有动。
移动的大多数系统还是业务型，电信级运维的要求很高，开发人员紧缺，出故障的责任重大，恐怕还是希望有第三方厂商来解决，所以还要是一步步来。对于话单查询这类查询型应用，可以去IOE，通过云计算方式解决。其它省级业务应用一时半会还是不要去IOE。而如果要建全国级营业厅应用，恐怕想不去IOE都不行，否则就象12306了

非交易类；
4、去IOE的演进路径和策略

应该是对业务系统有选择地进行，以及迁移的步调要合理地控制，不宜过快过急，需要等待MySQL数据库DBA团队的壮大，技术与经验的积累。否则，可能出现迁移过去之后不久，发现对业务发展和支持出现严重的问题，大淘宝内部的信息分析，他们已经基本度过危险的阶段，也有很多遇难杂症，但是支付宝的业务具有特殊性，要比淘宝的业务系统要求更高，恐怕是一个非常大的障碍。


5、对现有技术架构和管理体系的影响