深入解读“去IOE”背后的本质原因与技术价值

王晓征 2017-12-12 10:49:49

作者介绍

王晓征,Oracle 9i OCM(2003年),中国移动通信集团浙江有限公司信息技术部副总经理兼云计算中心主任,中国移动技术咨询委员会IT专家组副组长。

 

浙江移动的去IOE之路已经走了几年,从答卷单上看也是成绩满满:云化比例可观,I基本快去完了(无技术瓶颈,少量老旧设备按计划逐步下线罢了),E剩下也不是太多了(还有少量技术瓶颈),O基本控制在CRM核心交易库了,而且彻底实现了CRM核心数据库承载x86化。核心CRM应用容器化微服务化了,企业级微服务平台初具规模了,开发运维模式敏捷转型持续推进中了。现在,是时候回过头来重新盘点和反思一下去IOE。

第一个核心问题:去IOE是什么?

 

IOE不是洪水猛兽,IOE和我们也没有仇,去IOE不能从字面上去理解,不能为去而去。IOE在历史上发挥过关键作用,今后一段时间内也未必没有合适的应用场景,即使谈到技术发展,也有一句话叫做老兵不死,只是慢慢凋零,没有一蹴而就非黑即白的事情。

 

国家安全信息安全?层次太高,上头决策我们基层执行就是,我不评论不讨论该不该的问题,我这个层面只需要说清楚技术改造的代价和方案,同时做好预案就行。我们把技术问题转化为经济问题,上面只要花得起代价,咱确保有执行能力就是。

 

去IOE本质是阿里提出的一种营销口号,技术上并不严谨。

 

不严谨的背后是阿里IT架构的整体改造,这种改造以底层基础设施的改变明修栈道,实际上在应用架构的重建上暗度陈仓。一方面形式上去掉(至少大部分去掉了IOE),也为阿里云业务的建设奠定了技术基础;一方面推动应用的云化和微服务化,推动全面的架构解藕、敏捷转型、组织转型,推动小前台大中台的企业IT转型,为业务创新插上翅膀,重新定义了企业IT和业务的边界。

 

阿里去IOE很好地诠释了IT的价值在于创新,在于让你干以前干不了的事情,而不是仅仅在于节省成本。IT的价值是进攻而不是防御!

 

阿里为什么会进行这种应用架构重建呢?看看几年前阿里的技术人士分析阿里实施去IOE的原因:

  • 每年的GMV都高速增长(业务增长太快)

  • 每年的基础设施投入增长远超GMV增速(基础设施投资增长速度超过GMV增长速度)

  • 集中式核心数据库存在的困局:
    – 不稳定(宕机)会影响全网访问(集中式数据存放导致故障发生时影响面大,无法隔离)

    – 扩容成本高昂(小型机和商业数据库太贵)

 

(数字来自网络公开资料)

 

通过以上资料和数据,我们可以看出,阿里“双十一”的业务量在短短的8年内翻了3360倍。阿里对企业IT系统进行去IOE改造的最重要原因,是因为原来的集中式商业数据库架构无法满足越来越巨大的业务要求。我们虽然不低估阿里在去IOE过程中所做出的巨大努力和成绩,但也不能完全把这件事拔高到关乎国家信息安全的角度去解读。

 

在部分传统企业内部,对去IOE的看法千人千面,这么多年了主流看法还停留在两个方向:一、阻力大,不敢去,不想去,不愿意去;二、助力大,但助力却往往是被认为去IOE属于节省成本的创新范畴。

 

苍天啊,我的内心是崩溃的......

 

第二个核心问题:去IOE省钱吗?如果不省钱,是否值得做?

 

为什么去IOE绝不可能明显节省成本?如何让各路神仙弄明白这一点?我一直在思考。最浅显的例子是不是可以这么举:世界上没有免费的蛋糕,没有银弹,不可能只记吃不记打。

 

拿造房子举例吧,IOE基础设施是坚实的水泥,应用是建设在水泥上的高楼大厦,很安全很稳定。有人说水泥太贵了,而且被寡头企业垄断了,严重影响了大厦的可扩展性(太高了造不上去了)甚至稳定性,现在你们必须把靠谱的水泥去掉,必须把房子建设在不靠谱的黄沙上,黄沙便宜而且没人能垄断。好嘛,建筑师绞尽脑汁如何在不靠谱的地基上建设靠谱的应用呢?核心思路是不能建设向上的高楼了(scaleup),改为建设水平平房(scaleout);这样容量无限扩展了,而且一旦楼垮掉不会整体倒塌只会影响一幢平房;然后,为了做到这一点,建设模式(开发模式从瀑布到敏捷),楼房架构(IT架构从单体到分布),建材(从IOE到去IOE),物业(运维从苦逼操作转型为sre,运维开发,综合运营,逐步实现AIOps......),方方面面全部推倒重来。

 

本质上,必须意识到,既然要在不靠谱的建材上建设靠谱的房子,一定有另外的地方必须靠谱!上面那些方方面面都是必须转型加强的,都得花钱,尤其是成本!技术上说,一切都变为软件定义,没有稳定的基础设施只有稳定的架构。那软件定义不就是钱吗?架构不就是靠钱堆出来的吗?

 

这里面只有建材更换(硬件,主要是去IE)是省钱的,而且省的是投资不是成本。或者说,去IE以后直接维保成本随之大幅度降低了,但随之而来的架构和软件重定义的间接成本很大。IE由于远离应用,这一点还不算太严重,靠近应用的O这一点显示得特别突出,所以说去O是去IOE里最难的嘛。

 

TCO角度,由于统计口径不统一,我无法给出详细数字,但从经验角度,个人以为去IOE整体明显投资节省,但成本上升至少翻倍以上,综合TCO持平或略降低。主要节省在IE,而在O的角度很可能TCO不降反升(看怎么统计,如果按卖全了算综合TCO应该还是降低的,如果按和帝国主义耍流氓算肯定是更贵了。此外不管怎么算,纯粹的成本角度,一定大幅度上升的,翻倍都是保守了)。

 

总结:

 

一、去IOE本身是口号,但去IOE背后的创新才是真正值得借鉴的;

 

二、去IOE绝对不省钱,但一定程度值得做!核心原因如果操作得力,可以使你做到之前做不来的事情:应用架构、组织架构、开发模式全面转型,具备敏捷支撑业务的能力,从防御型支撑型IT走向进攻型创新型IT。培养出一批新一代的能创新、能思考的技术团队,加强核心能力内化,为后续业务快速迭代创新奠定IT基础。而这一切,都意味着更大的IT投入。用富人思维而不是穷人思维来看去IOE,用广义视角而不是狭义字面视角来看去IOE,一切迎刃而解。

 

本文未完待续,更多关于去IOE的深刻思考敬请期待……

最新评论
访客 2023年08月20日

230721

访客 2023年08月16日

1、导入Mongo Monitor监控工具表结构(mongo_monitor…

访客 2023年08月04日

上面提到: 在问题描述的架构图中我们可以看到,Click…

访客 2023年07月19日

PMM不香吗?

访客 2023年06月20日

如今看都很棒

活动预告