Graph + AI 中国峰会火热报名中,点击探索图分析更多可能! 了解详情
写点什么

当中小企业决定上云,真的像你们说的那么简单吗?

2019 年 10 月 14 日

当中小企业决定上云,真的像你们说的那么简单吗?


第四季度历来是公司员工一年中最忙碌的时期, 辛苦了一年,各项工作都在收官,千头万绪、环环相扣,再加上绩效考核的开展,不但烧脑,而且还烧心。


同时,最后一个季度又肩负着为来年开局而打基础的艰巨任务,所以各项规划都会紧锣密鼓的开展起来。


做为企业的 IT 部门,讨论内容的自然离不开 “硬件预算” 与 “人员结构” 这两大固定话题,但今年有些特别,我们在 “上云” 这个话题上,前前后后,反复讨论了近几个月。


为什么?


和其他金融类企业不同,为了获得最好的效率,最大的自控力,我们在系统建设之初,无论应用、中间件,还是测试与运维自动化,都坚持走自研的道路。随着业务的累计与架构的演变,整个系统与团队逐渐趋向于成熟。


但在过去的两年里,由于业务模式的转型(从线上转线下),公司对信息技术的投入开始缩减,这让我们在 “上云” 这件事情上遭遇了一连串的困难和挑战,甚至略显尴尬。对于我来说,也开始明白作为一家中小企业,想要上云,并不像之前想的那么简单。


于是,我们不得不停下脚步,静心思考下一步该如何调整。


阿里云都成立十年了,你们还没上云?

这几年,只要和朋友聊起上云的话题,都会有人跳出来怼,说阿里云都成立十周年了,云这东西,既不是啥前沿科技,又没什么技术门槛,居然还没有企业没上云?


上云,多简单的一件事。


是啊,都 2019 年了,与五年前相比,上云的确变得简单多了。但我还是不得不抛出一个老掉牙的灵魂拷问:企业上云的核心价值是什么?


或许有人对这样的问题嗤之以鼻,说云服务不就是为了降低企业成本而诞生的吗?尤其对那些具有明显错峰流量要求的业务场景,有了云服务,企业再也不需要为了那短短几分钟的尖峰流量而囤积大量的硬件,你用多少,付多少钱,合情合理。


再说了,在业务驱动型的企业里,IT 团队被归属为成本中心,因此,“成本”“质量” 与 “效率” 被称为衡量技术能力输出的三大要素。也就是,谁的成本更低,谁的质量更好,谁的效率高,自然能帮助价值中心(比如销售、运营、市场等)在有限的收入中获得更多的利润。


客观的讲,只要你的企业应用是跑在云服务上的,撇开质量不说,成本一定更低,效率一定更高。


虽然这些理念许多在互联网圈混的小伙伴能说出个大概,但我还想进行一些补充。


很多人容易把 “云服务” 和 “企业上云” 混为一谈,但其实这是两个概念,一个是技术理论,一个是技术行为,合在一起才能为企业创造价值。


关于企业上云的价值,我想再从 “微观” 和 “宏观” 两个角度多说几句。


先说微观,对大部分企业而言,之所以选择上云多是因为 IT 中后台系统的更新换代,以及成本居高不下、资源利用率低、资源管理困难、安全程度低等原因。所以,任何一家企业在决定上云之后,都会根据公司未来发展战略与 IT 系统的现状来制定实施线路图,尽量避免不要为了上云而上云。


再说宏观,上云之后,从此就算是搭上了技术快车,可以不断获取由技术更新迭代所带来的红利,可以有效地帮助企业将信息化建设迅速推进到位,缓解中小企业资金不足的压力,使小企业的大梦想成为可能。


也就是说,无论大公司还是小公司,不管你有经验还是没经验,都会为上云描绘一张宏伟的蓝图。



五年前,我们为了向老板交差,一群没经验的臭皮匠花了整整半年的时间折腾出了一张实施路径图。


在之后的五年里,我们始终在这条路上艰难的前行。但很可惜,这条路走到今年,我们突然发现走不下去了。


云服务是很好,但你的中/后台准备好了吗?

先来澄清一个概念,这里指的中/后台是什么意思?


这些年,凡事自认为自己是互联网的企业,无论规模大小,都在学习阿里的前/中/后台理念,为了与其匹配,有不少人也习惯把 IT 系统划分为 “前、中、后” 三层。


我们也不例外,从三年前开始就开始往这个方向进行转型。我曾在 《命保住了!五年时间,我们也搞了一个技术中台》中提到,我们把为业务部门开发功能的技术团队叫做“技术前台”,如果是 ToC 的业务,交付物必须贴近终端用户,如果是 ToB 的业务,交付物需要满足商家的需求。脑海中必须时刻牢记 “小步快跑,快速试错” 的理念,业务说啥,就是啥,业务要怎么做,你就怎么做。


而“技术中/后台”,说白了就是强调资源整合、能力沉淀的平台体系,什么中间件、自动化测试工具及 DevOps 等都包含在内,当前台团队需要实现业务功能的时候,为他们提供底层的技术、数据、工具等资源和能力的支持。



但与前台不同,中/后台的建设不仅需要有很强的前瞻性,而且初始化投入有点大,这有点类似于造房子之前打下的地基,人人都知道它很重要,但一旦与业务价值等同起来,一时间,你很难说出加大投入的必要性。


当然,如果你运气好,遇到个老板够豪爽,不仅不安于现状,面向未来,而且立志要和互联网死磕到底,那你只要把上面的一番理论跟他一说,自然加人,加机器都不是大问题。但如果你的运气不好,遇到个既没有互联网背景,又稳健谨慎的老板,那就有点麻烦。


因为你很难仅靠一张嘴,就让他认同 “IT 投入是价值成本,和一般的成本不同”。


好吧,有钱有有钱的玩法,没钱有没钱的活法,人和服务器多一些少一些都不致命,性能挖一挖总会提高的,效率用加班顶一顶总会上去的。


但问题是,咱们搞 IT 的,无论你是研发、测试,还是运维,玩的是规模效应。如果业务复杂了,数据变多了,那就要上系统解决,于是技术团队也变大了。如果业务形态以 online 为主,那就搞个网站,折腾个 APP。业务规模越大越复杂,与其配备的技术团队也就越大,硬件投入也会加大。反过来,如果没有达到一定的规模,或者以线下传统业务为主,很多时候搞个 Excel 比啥系统都好使。


现在有不少中小企业,在规模效应上会处于两种尴尬的处境:


  1. 以线下传统业务为主,有 APP,也有网站,不愿意外包,对效率极其敏感,自建研发团队,有自己的运维和 IDC,但受限于规模,技术投入相当有限;

  2. 原先以线上业务为主,技术团队也有一定的规模,研发、测试、运维、安全等工种一应俱全,但在某个时间点突然转型线下,于是开始大范围缩减技术投入、裁员。


简单说,无论是 1 还是 2,因为缺人、缺钱、缺经验,再加上一些客观条件的限制,不少中小企业在中/后台建设上只能摸着石头过河,既没时间试错,也没试错的本钱,但需求在,只能要一点,做一点,坏一点,修一点,进入疲于奔命的恶性循环,也是常有的事。


渐渐地,IT 系统及团队陷入到最可悲的结局 —— 系统和人都活了十几年,虽然没死掉,但也没长大,有经验的人没留住,技术投入也越来越小。


就这样,日子一天天的过去,直到某一天,从某处传出一个声音 —— “面向未来,降低成本,咱们上云吧!”


军令如山倒,中/后台的小伙伴闻风而动,开始联系各家云厂商,服务商也心领神会,这家拿出 TPC-C 记录,说自己的数据库性能有多牛逼,那家拿出了高可用报告,说自己的稳定性能达到 6 个九。我靠,听上去贼溜,似乎只要把系统上到这个平台上,就能一步升仙。


啥?怎么上云?协助你们上云?那跟咱们没关系,这是你自己的事,我们只卖产品。


回到公司,一群人掂量掂量自己的技术实力,盘算下自己的那些现有工具,用极其附有科学依据的公式推演了一下上云过程中要付出的代价(比如机房切换、SDK适配、混合云模式下的中间件运营、伪双活等等),再看看手上这些人力和物理,内心顿时升起一股拔凉拔凉的感觉……


怎么样?是不是特别有画面感?很凄凉,但很真实。


所以我觉得,云服务是很好,但不少中小企业在成本、人才方面顾虑亟待突破,从而导致在中/后台的建设上,还是组织效能上,都不具备上云的能力。


最终,企业上云这事会演变成一场旷日持久的拉锯战,渐渐地,马太效应起作用了,你越在短时间内看不到收益,你就越难说服老板加大投入,投入越小,越看不到……当然,如果你能够说服老板把系统重构,似乎也是一条出路。


毕竟,对家里有矿的人来说,这个世界一切都变得瞬间简单了。


在选云厂商时,你们考虑过 “政治” 立场吗?

“如果回到五年前,你还会选择中/后台自研的模式吗?”


“如果回到五年前,你会选择哪家云厂商?”


这是我们在讨论中最常提起的两个问题,答案也非常一致:


  1. 不会选择自研,直接选择一家靠谱的云厂商;

  2. 不用想,直接阿里云


很显然,如果没有上文提到的那些 “历史债”,中小企业应该把有限的技术资源投入到业务研发中,至于中/后台,只需要交给一家靠谱的云厂商就行了。



那什么叫靠谱?很简单,云计算这东西,规模越大,适配的业务场景越多越深,能提供给客户的福利越丰厚,产品成熟度也越高。


一般来说,Amazon或阿里是最好的选择,但也有一些非技术原因会导致我们无法选择他们。


比如,你是腾讯的被投企业,还和腾讯的某某部门有合作,如果你选择阿里云,那就相当不合适了。设想下,你打算把腾讯的数据放到阿里云上去吗?当然,理论上这没啥问题,只不过触碰了某些政治敏感区域。


将来,或许,会给公司带来意想不到的致命灾害。再比如,很多企业都拿过风投,而且还属于某些强监管领域(比如金融),如果你选择像 AWS 这样的国外云厂商,似乎就不太合适了。


当然,包括证监会在内,从来没有谁对这些灰色地带有过明确的说明,但纵观业内,也没有哪家敢第一个吃螃蟹的,你想强出头吗?还是算了吧。


是的,我知道你在想什么,如果选择其他云厂商,在某些产品和服务上质量会有所下降,该怎么破?


什么怎么破?只能 “矮子里面拔大个”,选择一些能够提供更灵活解决方案的中小型云厂商,至于他们那些不足的地方,自己慢慢补就是了。至少,先政治立场摆正了,再谈技术的那些事。


如果不上云,会不会死?

每当陷入激烈讨论的时候,我都会问自己一个史诗级问题:“为什么非要上云?不上会不会死?”


对中小企业来说,虽说想要构建私有云有点痴人说梦,但公有云随取随用的特点天然满足需要,不仅不需要企业购买硬件设备,软件的初期投入成本也大大降低,而且如果企业应用并不复杂,甚至人员的成本也可以节省下来。


不过,就像我上面所说的那样,对不少中小企业来说,从传统架构或 “半吊子” 互联网架构(虽然技术栈与互联网公司用的差不多,但组织模式与业务模式还是以传统为主)切换到公共云上的代价实在太大,所以,这会使他们犹豫不决。


再说了,在这类公司担任 CTO 的同学,有不少年级偏大,而且相对保守的顽固派(这也不奇怪,有点闯劲,心怀憧憬的人,早就去互联网公司闯荡了,机会多,场景多,且空间大),除非迫不得已,不是老板施加压力,或者人、机器扛不住了(比如不让你自行采购),要不然多一事不如少一事,何必呢?


啥?万一做砸了咋办?那就跑呗,这也是一贯采用的计量,只要能保住乌纱帽,能熬一天是一天。


但也有不少朋友,虽说不上云并不会对现有业务造成影响,甚至在很长一个阶段中保持稳定,但还是抱着面向未来的心态,试图上云?


不愿意失去机遇,又害怕面对挑战,是很多传统企业或 “半吊子互联网企业” 的通病。


当然,有一颗积极进取的心态自然值得鼓励,但企业上云毕竟不是儿戏,除了前面所谈到的硬核原因之外,对企业,对团队,对个人,有没有额外的收益?


答案是肯定的,我觉得一共有以下几点收益:


  • 对企业:冲击陈旧的传统思想,打开人们昨天的思想,抛弃对未来的无知、对未来的不拥抱的恶习;

  • 对个人:一定程度上解决了 “面向简历开发” 的诉求,能在实际的过程中学到知识,解决技术人普遍的焦虑症;

  • 对团队:能对吸引人才提供微薄之力,至少你可以告诉候选人 “咱们用的也是互联网架构,系统也跑在某某云上”。


说到这里,可能有人会问:“如果我就是安于现状,死活不上云,那又如何?会死吗?”


不会,绝对不会,你会活得很滋润。


但你要接受一个现实,用不了几年,你的这家公司就会变成 “一群老家伙,一脑袋的陈旧思想,守着一堆老系统,不仅招不到人,而且也找不到工作” 。


这就是抵制科技发展步伐的下场,够惨的。



这篇文章写到这里差不多也该结束了,因为是讨论中提炼出的内容,所以整体上有些凌乱,而且感觉还有不少话没有说完,但算是把核心观点给表达完了。


总而言之,当中小企业决定上云的时候,会遭遇到很多意想不到的困难,并不像某些云厂商或某些大厂的大咖们说的那么简单。在这些困难面前,有人选择逃避,有人选择迎面而上。而我,肯定是后者。但什么时候才是终点呢?谁知道呢,走着看吧。


本文转载自吃草的罗汉(ID:kidd_wyl),由王晔倞授权转载。


作者介绍

王晔倞,好买财富平台产品部总监,TGO鲲鹏会上海分会会员。


原文链接

https://mp.weixin.qq.com/s/KU9QLD-WoHCU9xI9f9GWRQ




TGO鲲鹏会,是极客邦科技旗下高端技术人聚集和交流的组织,旨在组建全球最具影响力的科技领导者社交网络,线上线下相结合,为会员提供专享服务。目前,TGO 鲲鹏会已在北京、上海、杭州、广州、深圳、成都、硅谷、台湾、南京、厦门、武汉、苏州十二个城市设立分会。现在全球拥有在册会员 800+ 名,60% 为 CTO、技术 VP、技术合伙人。


会员覆盖了 BATJ 等互联网巨头公司技术领导者,同时,阿里巴巴王坚博士、同程艺龙技术委员会主任张海龙、苏宁易购 IT 总部执行副总裁乔新亮已经受邀,成为 TGO 鲲鹏会荣誉导师。


2019 年 10 月 14 日 11:071732

评论

发布
暂无评论
发现更多内容

同态加密

soolaugust

学习 加密 同态加密

理论 | 三天两夜,万字长文,吃透TCP/IP

简爱W

Java TCP

netty案例,netty4.1基础入门篇零《初入JavaIO之门BIO、NIO、AIO实战练习》

小傅哥

Java Netty 小傅哥

netty案例,netty4.1基础入门篇八《NettyClient半包粘包处理、编码解码处理、收发数据方式》

小傅哥

Netty 小傅哥

性能优化-技术专题-并发编程

李浩宇/Alex

Java 多线程

netty案例,netty4.1基础入门篇六《NettyServer群发消息》

小傅哥

Java Netty 小傅哥

netty案例,netty4.1基础入门篇九《自定义编码解码器,处理半包、粘包数据》

小傅哥

Java Netty

没有亮点的简历,要用详历来弥补

escray

学习 面试 简历

netty案例,netty4.1基础入门篇二《NettyServer接收数据》

小傅哥

Java Netty 小傅哥

netty案例,netty4.1基础入门篇三《NettyServer字符串解码器》

小傅哥

Java Netty 小傅哥

netty案例,netty4.1基础入门篇十一《netty udp通信方式案例Demo》

小傅哥

Java Netty

探测mysqldump详细过程

Simon

MySQL

MySQL线程状态详解

Simon

MySQL 线程状态

LeetCode题解:11. 盛最多水的容器,for循环双指针,JavaScript,详细注释

Lee Chen

LeetCode 前端进阶训练营

世界很大,我想去看看

escray

学习 面试

netty案例,netty4.1基础入门篇一《嗨!NettyServer》

小傅哥

Java Netty

在java中使用SPI创建可扩展的应用程序

程序那些事

Java spi 可扩展程序 可扩展应用

[租房]刚步入社会的小萌新,休想坑小妹妹,安排!

我是程序员小贱

Stream 流

HeGuang

Java

netty案例,netty4.1基础入门篇四《NettyServer收发数据》

小傅哥

Java Netty 小傅哥

netty案例,netty4.1基础入门篇七《嗨!NettyClient》

小傅哥

Netty 小傅哥

一把年龄,技术一般,怎么去面试

escray

学习 面试

netty案例,netty4.1基础入门篇五《NettyServer字符串编码器》

小傅哥

Java Netty

netty案例,netty4.1基础入门篇十二《简单实现一个基于Netty搭建的Http服务》

小傅哥

Java Netty

Golang领域模型-开篇

奔奔奔跑

Go 微服务 领域驱动设计 架构设计 后端开发

JVM-技术专题-管程技术分析

李浩宇/Alex

JVM 管程

API 中签名的使用

架构精进之路

接口安全

lower_case_table_names参数详解

Simon

MySQL

PHP浮点数精度损失问题

架构精进之路

php 弱类型语言

实战 | Vue + Element UI 页面创建

简爱W

Java 架构师

netty案例,netty4.1基础入门篇十《关于ChannelOutboundHandlerAdapter简单使用》

小傅哥

Netty 小傅哥

当中小企业决定上云,真的像你们说的那么简单吗?-InfoQ