云计算开辟修罗战场

从中学老师张鹏的故事出发。这位 40+ 的中年人有着中产流行的焦虑，这种焦虑推动他去学 Python，既是技多不压身的初心，也伴随工作中无法与 IT 供应商高效沟通的为难。

他举了个例子，工作需要他每年统计年级里的教学经费。起初，他是用 Excel 做每年的经费统计，花费时间长、而且数据很难留存下来。后来，找了个小公司来开发系统，基本一个应用上线要花个半年。很多时候，当这个应用上线的时候，最早启动这个应用的需求已经解决了。

今年疫情期间，在女儿在家上课的钉钉软件上，他捣鼓翻出一些简易开发应用的平台，看了两个小时教程后，他打开了电脑。第一个应用就是用来统计教学经费，上手摸索了两天就建了起来。原本这个应用，那个 IT 供应商报价是 10 万元，2 个月开发周期。

「忽然就兴奋了，半夜一直想着怎么拉流程，睡不着就起来弄一点、弄一点。」他最终捣鼓出了十几个应用，基本把那个 IT 供应商给炒鱿鱼了。最近，其他年级也开始复制他的应用，陆陆续续又「炒掉」了一些 IT 供应商。

另一个相似故事是一位政府公务员。他所在的单位涉及自然灾害应急，台风一来，上级要求十里八乡的受灾情况要每两小时报一次，这点时间，甚至不足以将各乡镇汇报来的数字「加减乘除」。

今年，上下游各级机关都开始在钉钉上办公，他也捣鼓了一下，做了一个统计应用，等着台风再来，拉个钉钉群，把应用发在群里，十里八乡的负责人直接在应用上填写数字，受灾情况就自然明了了。

提供一个简单的应用开发平台，允许使用者自己开发应用，解决了两个问题。

(1)速度。原本，开发应用的链路是：使用者(老师、公务员、职员)有需求 - 领导允许提需求 - 联系信息部门 - 信息部门联系供应商 - 供应商对接使用者 - 开发或调整应用。且不说开发本身花费几天，光是这些对接，少则一星期，多则数月。

现在的链路是：使用者有需求 - 自己开发，结束。快的话全程半个小时搞定。

(2)准确性。经过上文提到的层层对接，最终开发应用的程序员对需求的理解已经很模糊，应用未必能满足使用者需求，经常要重复 2. 3 次才能改准确。当然也有情况是不改了，然后因为不好用，这个应用就被闲置了。

这两个问题解决，会直接提升企业应用的数量。本来，应用开发的速度和准确性都不达标，极大降低了人们使用应用的欲望，往往就用回了纸本、Excel 和 Word，回归「非数字化状态」。

一旦两者达标，用户使用欲望提升，应用数量会快速增长起来。

虽然这些小应用还无法和庞大的 ERP、CRM 等大规模企业办公软件抗衡。但小应用如同毛细血管，密密麻麻，解决了「最后一公里」需求，让许多没有接触过 IT 技术的人员和业务，第一次实现了数字化。

而且，在云底座连通的条件下，这些小应用们为整体的 IT 系统带来了「最后一公里」能够提供的原始业务、经营、人员、财务数据——而这恰恰是整体 IT 系统梦寐以求、往往求而不得的。

进一步推想，这些最原始、实时的业务记录，那些云服务厂商们提出的数字化下的「智能决策」、「智能流程」种种设想，才能有条件实现。对于企业来说，那些设想才不会停留在画饼阶段，而是真正变成「降本增效」的数字化工具。

对于云服务商来说，那个成为全社会(而不仅仅是互联网)的数字底座的愿望，才有机会真正达成。

所以说云计算正在进行「扩圈运动」，行进在普及的拐点上，大概因为上面这些原因。

02 云走到了一个什么样的路口

讲到行业的拐点，还是要讲下这个行业过去经历了什么。

众所周知，十多年前，在云计算刚刚落地应用时，关于云的构想有无数个，真正走通的只有一个：以亚马逊和阿里云为首的 IaaS 模式，也就是服务器虚拟化，提供弹性算力。

这和当时的环境密切相关。那时正是互联网向移动互联网转型的时间节点，2008 年到 2018 年被称为移动互联网的黄金 10 年，大大小小的互联网企业拔地而起，流量激增，每一家对算力都嗷嗷待哺。

IaaS 成为最符合当下需求的 IT 模式，算力比传统 IT 便宜、且更强大，标准化高。一个 4 核 2G1M 带宽的云服务器，足以满足一位开发者的网站使用需求。如果需求更多，那就购买更多云服务器，反正是按需付费，不用的时候不花钱。

（编辑：我爱故事小小网_铜陵站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!