传统企业IT为什么对微服务叶公好龙的心态?(转)

这两年来,“微服务”、“云计算”、“大数据”、“人工智能”的概念在IT界成了新的宠儿:珠联壁合、声名远播、势如破竹、如日中天!从实践落地的情况来看:微服务诞生于互联网,当然是首先在互联网界遍地开花,高奏凯歌,所向披靡,到处布道。当传统企业刚遇到“微服务”,哇!这玩意真好啊,真是葵花宝典啊!业务隔离、独立部署、独立上线,高性能、高可用、弹性伸缩!我们公司要是也能实现这个该有多好啊!持续集成、持续部署,这不是我们整天喊整天吹的业务敏捷正需要的东东吗?然而在研究一翻之后,“洗洗睡吧!“ 抱着质疑的态度试试看的心态有之,唱反调嗤之以鼻的也有之,总之,进展不如人意!

去年有幸参与了一家国际巨头级大企业的微服务架构治理项目,在平衡了研发部门的一些阻力之后,通过坚持”适度自包含“的原则,还算成功!但“微服务”这个词,在火过一在段时间后,从这家公司的PPT中、公开演进中,基本不再提了,“微服务”这个词成了这个企业忌悔的东西。

下图的企业级IT采纳周期图,也说明了这个现实:

这里我们可能应该思考一下,为什么是这么个顺序?首先看互联网公司特别是巨头级电商,如阿里巴巴,从它的架构演进经历就可以看出,它是被业务复杂度、高并发、大数据逼出来的,从淘宝,到天猫,再到各类第三方渠道互联网产品,业务越来越复杂,周围聚拢的合作伙伴、合作伙伴的用户,企业用户、个人用户。不搞商品中心、店铺中心,不搞垂直切分,不搞微服务,不搞大中台,它就玩不下去了,所以是非常自然的。AWS也一样,本来是开电商卖书的,后来啥都卖,新的创意天天有,老板也OPEN ,云平台完全是一个意外的产物,所以它成了第一。亚马逊与阿里有一个共同的特征就是:老板不是IT人。而ORACLE,IBM,微软这些巨头就不同了,没有云计算、微服务之前,思考一下以前它们是靠什么赚取高额利润?商业套件+硬件服务器,这种组合方式,已经保证了ORACLE,IBM,微软近15年的高利润,它们当然不愿也不会轻易接受新事件的冲击了,它们属于不见棺材不落泪的类型,如果一直装鸵鸟,就会象诺基亚一样随风而去,中国联想也是一样,颓势愈发明显。而这些巨头的伟大之处就在于,虽然有质疑,但会敏感地关注,不断评判,往往在紧要关头,迎接挑战,最后扭转困局。比如微软是三巨头中最早一个看到危机的,所以Asure云平台现在市场占有率第二。

而对于企业来说,IT属于支持部门这个理念基本就没变过,三个月一上线周期是正常的,六个月也是有的,两个月一个大版本就是比较优秀了,两周一个小升级那就就是先进了。业务部门、销售部门对于企业来说永远是王者,其它部门都是支持部门,因为人家是直接看得到钱的。人怂志当然短了。对于IT研发、运维部门来说,少出事、别出大事、出了事与自己无关,那是绝对是自保基本三原则,那么对于IT新技术、新趋势的接受程度、落地速度,自然就是最慢了,如果没有顶层部门压下去,那是不可能跟上时代的。

大势所趋,趋之若鹜,再叶公好龙,再接受的慢,还是得拥抱"微服务"啊拥抱云!那么我该如何拥抱你呢?我的”微服务“。没别的办法,我们还要得思考,我们要用“微服务”改变什么?实现什么目标?

对于巨头级跨国公司,基本大并发高性能、大数据的需求都不迫切,大部分业务系统均为企业用户或内部员工,量级最多几十万,QPS1000基本就都可以打发了,数据量也不大,大量系统几年十几年了,数据库规模也是G级,一个ORACLE就装下了,它最大的诉求是什么,是直面激烈的市场竞争,和高压的销售任务,那么关键就找到了:如何在持复杂、持续变化的业务背景下,实现持续集成、持续部署、持续上线,实现真正的业务敏捷、随需而变。

在微服务化没出来的时候,这些企业的CIO也没少努力,可就是效果不大,或者压根不见效,SOA、敏捷、自动化测试,各种神器大展身手,那么败在了哪里呢?经过深度思考、分析,下面是它们的败点:

1、项目组织由不同部门组成,“部门墙”遗害无穷

2、项目组内是按技术架构分,而不是按业务,团队依赖严重、沟通成本高

3、SOA以最大复用为目标,层间依赖严重,未能隔离业务依赖,陷入依赖地狱

4、自动化程度差,开发、测试、试运行、生产环境的不同使QA质量不高

5、敏捷流于形式,未能有效隔离业务,工作量风险估计不足,敏捷不起来

各类神器既然都不见效,或者效果不明显,企业IT部门对新生事物当然会越来越抱着质疑的眼光,这玩意真的行吗?真能解决问题吗?还有,在大型企业特别是巨头级央企、私企, 无论IBM、ORACLE、微软、诺基亚、联想,都存在一个“尾大不掉”的问题,就是接受新事物慢、掉头慢、动作慢,对潜在挑战者的出现,往往在较长时间持鄙视的态度。如诺基亚对智能手机的三年鄙视,错失了追赶的时间,一败涂地,落个被收购的命运;IBM、ORACLE、微软之于云计算、AI,赶了个大早,起了个晚集,这里面微软省悟得还算快了一点,就这么一点也从AWS的云计算地位差了一大截。无法像阿里那样不断蚂蚁金服、菜鸟网络的涌现。所以领导人的思维很重要,领导人的换维眼光很重要,领导人的胆魄很重要,但如果象乐视贾跃亭那样只顾飞,不见陆地,有一天终会“啪”摔在地上。

那么我们回过头来继续思考,为什么传统企业IT负责人为什么对微服务有着叶公好龙一般的心态?,最根本的原因,仍是“尾大不掉:现有系统业务流程、应用架构、技术架构、产品UI经过多年打拼、打磨,付出大量加班和心血,已经稳定运行多年,可用性、稳定性已经到达一定高度,当然不忍打破了。因为打破之后的工作量风险、成本风险、质量风险、稳定性风险、周期风险,对部门业绩是一个挑战,因此在无上级部门强制要求,或者将架构重整当成考核指标的情况下,自然是稳定压倒一切,稳定压倒一切,稳定压倒一切.

没办法,大家首先要生存嘛,要生活嘛,不要风险!微服务的粒度细到一定程度,自包含很容易被打破,原有的强一致场景、一个SQL就解决的问题自然也被打破,UI交互甚至要重新调整、重新设计,服务层、数据层均要垂直切分,那么凭空会出来大量分布式事务,还要保持原来的强一致性(思维转变不过来),原来大量关联SQL很容易解决问题的,需要在数据库切分改后进行改造,数据模型不支持细粒度切分啊怎么办,加一个字段就可能影响许多点代码进行修改,重新测试,重构工作量不但大增,对系统原有稳定性也是一个打破和重建的过程,现有系统还要疲于奔命应付业务变化的情况下,“重构”成功了额外的工作,因此其重构的复杂性、工作量、风险都成了重大的阻力。

所以,以上才是传统企业IT负责人为什么对微服务有着叶公好龙一般的心态的核心因素。

所以无论是微服务,还是云计算,大型企业的接受肯定是排在最后,那么,如何转变呢?不是那么容易的,因为这是一个系统问题,微服务、DevOps、云计算,对大型企业的组织方式、管理方式、运营模式的冲击,是颠覆性的,我们看看有哪些颠覆性的元素:

1、微服务是对业务的垂直切分,那么对业务部门,也得垂直切分,方能实现业务隔离、业务敏捷,这是对业务部门动手术。

2、微服务是从需求-产品-开发-测试-运维的一体化,以细粒度的业务为单位,在大企业,这些环节往往由一个独立部门负责的,是对部门墙的打破。

3、项目团队按微服务团队,每个微服务要有业务持续性,有价值,这样这个团队才是活的,有价值的。

可以看到,这些颠覆性的元素,具有变革的性质,凡是变革,如果没有一把手的领导,没有顶层设计、监督、推进、执行,是不可能成功的。

原文地址:https://www.cnblogs.com/huanghongbo/p/9321148.html

时间: 2024-07-31 06:03:06

传统企业IT为什么对微服务叶公好龙的心态?(转)的相关文章

企业应用架构之微服务架构

微服务架构现在是谈到企业应用架构时必聊的话题,微服务之所以火热也是因为相对之前的应用开发方式有很多优点,如更灵活.更能适应现在需求快速变更的大环境. 本文将介绍微服务架构的演进.优缺点和微服务应用的设计原则,然后着重介绍作为一个"微服务应用平台"需要提供哪些能力.解决哪些问题才能更好的支撑企业应用架构. 微服务平台也是我目前正在参与的,还在研发过程中的平台产品,平台是以SpringCloud为基础,结合了普元多年来对企业应用的理解和产品的设计经验,逐步孵化的一个微服务应用平台. 目录:

有容云:微服务容器化的挑战和解决之道

注: 本文根据6月是18日七牛云微服务课堂-微服务容器化的挑战和解决之道演讲内容整理而成,演讲者:有容云联合创始人兼首席架构师马洪喜,与大家一起探讨了如何通过容器技术将微服务和 DevOps 落地. 嘉宾介绍: 马洪喜,此前担任 Rancher Labs 中国区技术负责人.Citrix 公司资深架构师.Oracle 公司虚拟化产品开发经理等职务,在容器云.IaaS 云.桌面云建设方面拥有丰富的经验. 单体架构 VS 微服务架构 传统单体架构存在各种各样的问题,如加载编译耗时长.代码管理复杂.横向

微服务容器化的挑战和解决之道

注: 本文根据6月是18日七牛云微服务课堂-微服务容器化的挑战和解决之道演讲内容整理而成,演讲者:有容云联合创始人兼首席架构师马洪喜,与大家一起探讨了如何通过容器技术将微服务和 DevOps 落地. 嘉宾介绍: 马洪喜,此前担任 Rancher Labs 中国区技术负责人.Citrix 公司资深架构师.Oracle 公司虚拟化产品开发经理等职务,在容器云.IaaS 云.桌面云建设方面拥有丰富的经验. 单体架构 VS 微服务架构 传统单体架构存在各种各样的问题,如加载编译耗时长.代码管理复杂.横向

理解微服务

当前微服务很热,大家都号称在使用微服务架构,但究竟什么是微服务架构?微服务架构是不是发展趋势?对于这些问题,我们都缺乏清楚的认识,本文基于作者在大型互联网系统的服务化实践和思考,和大家一起探讨微服务架构.本文主要内容包括: 1.   传统SOA架构 2.   新型SOA架构 3.   服务设计方式 4.   深入微服务 5.   微服务体系 6.   微服务系统架构 传统SOA架构 说到微服务,离不开SOA,两者经常放一起讨论,首先我们要了解SOA架构. 国外信息化起步较早,很多大公司先后建设了

从单体架构迁移到微服务,8个关键的思考、实践和经验

转载本文需注明出处:EAII企业架构创新研究院(微信号:eaworld),违者必究.如需加入微信群参与微课堂.架构设计与讨论直播请直接回复此公众号:“加群 姓名 公司 职位 微信号”.   随着微服务架构的持续火热,网络上针对微服务和单体架构的讨论也是越来越多.去年的时候,社区更多的关注点是在二者的区别以及优缺点辨析上,而今年,越来越多的人开始关注如何从单体架构迁移到微服务上.毋庸置疑,微服务的理念正在席卷整个开发者社区,像Netflix.Uber这样的公司都是非常成功的应用案例. 但需要注意的

基于微服务的软件架构模式(转载)

转载:原文链接 基于微服务的软件架构模式 [编者的话]微服务只是最近提出的概念,实际上很多巨头公司(FB.Twitter.AWS等)已经在亲身实践.微服务并不是银弹,但是我们可以参考它的 思想来解决自己遇到的问题.对于已经找准市场,业务即将或者马上就要急剧发展的创业公司,适合使用基于微服务的软件架构. 今天阅读了两篇关于微服务的文章,总结一些笔记,简单翻译了一篇文章.说明:并没有严格按照原文一字语句翻译,有部分自己的理解,还有部分是意译. 微服务(micro services)这个概念不是新概念

Re:从0开始的微服务架构--(二)快速快速体验微服务架构?--转

原文地址:https://mp.weixin.qq.com/s/QO1QDQWnjHZp8EvGDrxZvw 这是专题的第二篇文章,看看如何搭建一个简单模式的微服务架构. 记得好久之前看到一个大牛说过:如果单体架构都搞不好,就别搞微服务架构.乍一看,这句很有道理,后来发现这句话是不太对的,因为微服务架构的目的就是为了降低系统的复杂性,所以 微服务架构应该比单体架构更简单.更好实践才对. 这篇文章,我们就分享一下如何搭建一个 简单模式 的微服务架构. 什么是微服务架构的简单模式? 相对于大型互联网

微服务实践(七):从单体式架构迁移到微服务架构

迁移到微服务综述 迁移单体式应用到微服务架构意味着一系列现代化过程,有点像这几代开发者一直在做的事情,实时上,当迁移时,我们可以重用一些想法. 一个策略是:不要大规模(big bang)重写代码(只有当你承担重建一套全新基于微服务的应用时候可以采用重写这种方法).重写代码听起来很不错,但实际上充满了风险最终可能会失败,就如Martin Fowler所说:“the only thing a Big Bang rewrite guarantees is a Big Bang!” 相反,应该采取逐步迁

微服务的4个设计原则和19个解决方案

转载本文需注明出处:微信公众号EAWorld,违者必究. 微服务架构现在是谈到企业应用架构时必聊的话题,微服务之所以火热也是因为相对之前的应用开发方式有很多优点,如更灵活.更能适应现在需求快速变更的大环境. 本文将介绍微服务架构的演进.优缺点和微服务应用的设计原则,然后着重介绍作为一个"微服务应用平台"需要提供哪些能力.解决哪些问题才能更好的支撑企业应用架构. 微服务平台也是我目前正在参与的,还在研发过程中的平台产品,平台是以SpringCloud为基础,结合了普元多年来对企业应用的理