|
|
# 26 | 上云设计，融合云计算的未来
|
|
|
|
|
|
你好，我是乔新亮。
|
|
|
|
|
|
如果不考虑本周五将要更新的“结束语”，那么实际上，我们已经来到了整个专栏的最后一讲。在这一讲里，我打算和你聊聊有关“上云设计”的话题。
|
|
|
|
|
|
为什么要在这样的时刻聊起云计算呢？
|
|
|
|
|
|
这其实和当代 IT 产业的发展趋势有关，可以说，云计算产业的成熟，直接影响了很多问题的思考方式。
|
|
|
|
|
|
前段时间，我找到团队内的一位核心架构师，请他去调研关于企业上云的可行性，培养他做架构决策的能力和思维。其实，对于我来说，调研的结果并不重要，因为我早就在心里打算好了：我们一定要上云，彻底拥抱云计算。让团队去调研可行性，更多是为了做好团队的能力培养。
|
|
|
|
|
|
说到这里，你可能会觉得有些似曾相识。没错，在专栏里，我曾多次提起对云上资源的规划。
|
|
|
|
|
|
比如，在“高性能设计”一节，我们谈到拥有云上秒级扩容能力，会给运维工作带来哪些帮助；在“扩展性设计”一节，我们提议，对于非核心系统，在需求较为匹配的情况下，直接选择购买套装软件或云服务。
|
|
|
|
|
|
类似的例子还有很多，最终可以归结为一个结论：企业要上云，并且未来一定会上云。
|
|
|
|
|
|
当然，我不是一拍脑门或是收了赞助费，所以跑来建议大家上云。而是整个 IT 产业的发展趋势，迫使我们顺应时代。如果不能形成正确认知，与趋势为敌，一定会影响企业或者自己的发展。
|
|
|
|
|
|
所以接下来，我们要站在全局视角，尝试看透 IT 和云产业的价值与发展。
|
|
|
|
|
|
## 对 IT 技术和云计算的发展趋势判断
|
|
|
|
|
|
整个 IT 产业的发展历程，起始于硬件方面的发明创造。
|
|
|
|
|
|
1946年，英国剑桥大学成功研制出第一台冯·诺依曼机器： EDSAC 。近十年后，相关的编译程序和编程语言才出现。
|
|
|
|
|
|
但直到 1964 年 IBM 推出 System/360 以前，所有的计算机都是面向用户定制的，没有统一标准，设计上也没有连续性。IBM System/360 的出现，标志着计算机开始走向通用化、系列化和标准化。
|
|
|
|
|
|
1981 年，IBM 推出了世界第一台个人 PC，体型大幅缩小，是计算机走进千家万户的开始。站在历史的角度看， IBM PC 尤其有重要意义。
|
|
|
|
|
|
但如果让一个生活在 2020 年的程序员来看， IBM PC 无疑差到令人发指 —— 它的内存只有 16k，存储还要靠盒式录音磁带或 5.25 英寸软盘，售价却高达 1565 美元，真是又贵又难用，性能都不如现在一款价值几百元的老年手机。
|
|
|
|
|
|
当然，IT 软件的发展也没比硬件好多少。如果你是计算机软件专业出身，很可能学习过汇编语言，也就是面向机器的程序设计语言。现在看来，汇编语言非常难以理解，编码也很复杂。到现在，已经很少有软件公司，会用汇编来开发软件。
|
|
|
|
|
|
那时，人们很难想象，会有 Java、Golang 这样的语言应用在软件开发行业，极大降低研发成本，提升了研发效率。
|
|
|
|
|
|
从汇编语言到 Java ，从最早的 IBM System/360 到如今的计算设备，技术发展表现出了一个明显的趋势：底层黑盒化、价格亲民化。也就是说，**我们越来越不需要关注技术细节，同时技术的价格也越来越亲民。**
|
|
|
|
|
|
当这些技术或服务，被整合成产品，连入互联网，使客户可以按需购买时，云计算就出现了。
|
|
|
|
|
|
站在应用软件角度看，现在的 IaaS 软件已经非常成熟，PaaS 和 SaaS 软件也在迅速发展中。到目前为止，Salesforce 可以说是最成功的 SaaS 软件。
|
|
|
|
|
|
说了这么多，关于 IT 技术和云计算，二者的发展究竟呈现出什么样的特征呢？我将其总结为以下五点：
|
|
|
|
|
|
1. 形态产品化；
|
|
|
2. 价格平民化；
|
|
|
3. 自助服务；
|
|
|
4. 按需付费；
|
|
|
5. 网络访问。
|
|
|
|
|
|
在某种意义上，云计算可以理解为各类云服务的统称，而所有这些服务，都是通过产品来体现的。在今天，云产品仍然在向前快速发展，站在旧有产品的肩膀上，融合进旧有产品的生态里。
|
|
|
|
|
|
推动这种发展向前的力量，不是某家公司 CEO 的个人意志，而是“**技术基座不断上移**”的社会客观需求。
|
|
|
|
|
|
科技不与人争利，只有人与人之间才会争利。技术进步推动了社会的进步，因此自有其普世价值，也会越来越平民化。**看清趋势，拥抱趋势，在技术****演进早期，选择****恰当时间，积极应用，拥抱技术红利，****就****可以为企业赢得阶段性的领先优势**。
|
|
|
|
|
|
在经济学概念里，如何实现社会效益的最大化？答案是，专业分工。在数字化世界里，逻辑其实是同样成立的。最明显的特征是，对于云产品来说，只要客观需求存在，就一定会有人去尝试解决，并包装成产品售卖。
|
|
|
|
|
|
比如，DevOps、微服务框架、多云管理、深度学习训练服务、边缘计算服务、量子计算服务……只要你需要，基本就能找得到。
|
|
|
|
|
|
对于云计算厂商来说，只要不是企业核心的业务逻辑，所有“技术基座”都可以云化，让专业的人干专业的事，客户只需要付费购买就好。
|
|
|
|
|
|
对于**甲方企业来说，IT 投入是价值成本，需要持续加大投入，但迫于经济规律，****最终****不得不寻求公共技术的社会化**。
|
|
|
|
|
|
双方的深层需求是契合的，也符合让社会效益最大化的经济学原理。所以，关于 IT 技术和云计算的发展趋势，我一直认为有两大结论是非常关键的，分别是：
|
|
|
|
|
|
1. 数字化转型的结果是：云会吞噬一切；
|
|
|
2. 云不仅仅是技术，更是最好的商业模式。
|
|
|
|
|
|
明确了这两点，我们才能知道，该如何正确地看待这场“变革”，并寻找个人或企业的发展机会。
|
|
|
|
|
|
## 坚持拿来主义，不要和趋势为敌
|
|
|
|
|
|
我相信，至少有五点认知，你一定要关注，并多加思考。这些认知，既适合普通工程师，也适合 CEO/CTO ，区别是，站在何种角度去思考，以及如何做决策。
|
|
|
|
|
|
**第一，从业务发展的角度出发，倒推上云规划。**
|
|
|
|
|
|
你可能会想，老乔这个大忽悠，按你这么说，CTO 干脆啥也别想，直接上云就可以了。
|
|
|
|
|
|
当然不是了，上云是为了帮助业务降本提效，做任何事都要从目标出发。从前，我曾主导企业的 IT 设施上云规划，就在同云计算厂商的合同里，明确写道：
|
|
|
|
|
|
“完成迁云后，在同等资源下， IT 年度总支出费用相比 20xx 年降低 55%。20xx 年为迁云实施阶段，年度迁云总费用不得高于前一年 IT 相关基础设施、技术平台总费用。”
|
|
|
|
|
|
当然，云产品带来的价值，不仅是资源节省，还有人力节省、加速研发等，这些都可以换算成财务价值。
|
|
|
|
|
|
如果你上了云，IT 开销反而更大了，那说明整个规划和管理一定存在问题，先不要上云。
|
|
|
|
|
|
**第二，坚持“拿来主义”，不要在企业层面重复造轮子。**
|
|
|
|
|
|
其实在前面的内容里，我们有聊到过这一点，但很多做技术的同学，依然对此十分执着。
|
|
|
|
|
|
经常有同学找到我说，老乔，XX 功能我们自己完成吧，我们自己做得更好！做得更好，到底是怎么个好法呢？用我们前面讲的知识来理解，也就是要明确给“用户”的契约：“你要消耗多少成本，在多长时间内，实现一个什么样的产品，性能表现怎么样？”
|
|
|
|
|
|
大部分同学，可能并没有明确这个契约。有时，老板也会犯糊涂，仅仅是听研发负责人这么一说，就不假思索、大大方方地同意了。
|
|
|
|
|
|
通常，在项目刚启动时，在开源项目的加持下，可能只需要两个人参与开发，人力成本并不高。可一个季度后，负责人就会找到老板，要求将项目组扩充至五人。又过了一个季度，可能项目组就变成了十个人。老板这才发现自己上了“贼船”，该项目仿佛一个“无底洞”，自研成本早已远远超过购买云服务的开销。
|
|
|
|
|
|
当下，许多的 IT 研发工作都是重复造轮子，美其名曰为“沉淀企业 IT 基因”，实际就是浪费 IT 资源，对业务发展施加反作用。企业经营要务实，对于非核心业务，坚持“拿来主义”，不要过于理想主义；对于核心业务，坚持长期投入，建立团队推进自研工作。
|
|
|
|
|
|
**第三，别害怕上云，****和****乙方****一起****搞定障碍。**
|
|
|
|
|
|
很多技术管理者一提上云就如临大敌：顶层规划怎么做呀？云上架构怎么设计呀？应用怎么迁移呢？怎么把云用好呀？怎么选择云厂商啊？
|
|
|
|
|
|
还没正式见过服务商们，就先把自己吓了个半死 —— 这么多问题都不懂，我们团队可能支持不了上云改造，要不计划先搁置吧。
|
|
|
|
|
|
依据我在企业上云方面的经验，上云规划涉及的内容会非常多，包括：上云方案、现有系统评估、云平台成本优化建议、迁移方案、云主机的功能和指标、网络带宽指标、跨国专线带宽指标，等等。
|
|
|
|
|
|
在当时，团队也是第一次做上云迁移，很多内容都不懂。这份文档的内容，部分是我们根据自身需求提出的，部分来自于云厂商对自己亮点的介绍。最终，文档在不断地沟通和商业谈判中丰富起来了。
|
|
|
|
|
|
**第四，开放心态看待数据隐私。**
|
|
|
|
|
|
很多人对公有云比较抗拒，担心数据隐私泄露，担心竞争对手派系的企业盗用自己数据。其实我认为，大可不必担心。我个人的观点是，云厂商不会在公司层级盗取你的数据，但有可能因为管理不善而导致数据泄露。
|
|
|
|
|
|
可我们也要多问问自己，自己管理的数据就安全吗？比头部云厂商的管理更加安全吗？
|
|
|
|
|
|
我看未必。当然，如果实在不放心，大可以选择私有化部署，一样能解决问题。
|
|
|
|
|
|
**第五，正确看待云计算的“负面影响”。**
|
|
|
|
|
|
听到这里，你可能还是不太放心，老乔，云计算真的那么好，一点负面影响都没有吗？
|
|
|
|
|
|
肯定还是有的，但客观地讲，这些更多属于组织和文化层面的问题。最近几年，在和许多管理者朋友的交流里，我愈发明确了一个事实：技术基座的上移，最终会导致部分初级开发者失去工作机会。
|
|
|
|
|
|
听起来有点耸人听闻，但这是事实。以前，有许多人安于码代码，拒绝思考，同时也拒绝追求卓越，自嘲为“搬砖码农”。但“搬砖码农”的数量未来一定会减少，云计算的成熟会大大加速这一过程。
|
|
|
|
|
|
如果企业奉行的不是以业务为中心，以产品为核心的组织文化，不具备我们前面所讲的、优秀的组织架构，就很可能在上云问题上陷入多方扯皮。因为，这触动了部分人的“蛋糕”，打扰了部分人的浑水摸鱼。
|
|
|
|
|
|
所以上云，依然是个一把手工程。
|
|
|
|
|
|
以上五点，是在上云过程中，许多人都可能存在的困惑与实际问题，如果要将其总结为一句话，我认为是：坚持“拿来主义”，不要和趋势为敌。
|
|
|
|
|
|
我们要明确地意识到，未来，专业分工一定会越来越明确，技术基座一定会不断上移，每家企业都可以忘掉底层技术细节，聚焦自己的核心业务逻辑。因此，这条思考脉络最终也会回到出发点，形成闭环：对于大部分商业公司（非技术产品或云计算公司）而言，技术只有在成就业务时，才具备真正的价值。
|
|
|
|
|
|
## 结语
|
|
|
|
|
|
曾经，许多研发同学都喜欢找到我说，老乔，你看我做的这个软件，太厉害了，我技术厉害吧？
|
|
|
|
|
|
我经常打击他：有啥厉害的，你这做的就是个玩具嘛。
|
|
|
|
|
|
你可能会有点不解，怎么就是个玩具呢？答案很简单，真正厉害的技术，要能包装成产品，对外售卖或提供服务。用户愿意为之付费的，才是好东西。再多的夸奖，也不比金钱更有说服力。
|
|
|
|
|
|
我常常说，要站在未来看当下，用十年后的眼光看现在。由此出发，可见对于很多研发同学来说，个人成长路径其实只有两条：
|
|
|
|
|
|
1. 成为技术管理者，进入商业公司，采用技术产品或云服务，洞察业务，帮助业务成功，实现业务价值；
|
|
|
2. 成为技术专家，进入纯技术公司或云计算公司，设计开发技术产品，提供技术服务。
|
|
|
|
|
|
无论哪一条，其实都已经注定要和云计算的未来融合在一起，云计算会成为未来的水、电、燃气、交通工具。
|
|
|
|
|
|
一定要尽早形成对此事的正确认知，大胆地拥抱新的技术趋势和机会。等到大家都看清云计算的发展情况，全部开上“汽车”时，无论是我们的个人发展，还是企业的发展，也就谈不上什么先发优势了。
|
|
|
|
|
|
当然，很多企业没有认真规划过自己的技术平台，因此也比较难以上云。但如果在企业内部，就存在一个底层技术平台，那么，这就很接近企业级别“云平台”的概念了。与此同时，如果我们能保持开放的心态，那么外部平台就只是一个候选方，和企业生态内的云平台并无本质区别。
|
|
|
|
|
|
农业社会的核心生产力是农民，工业社会的核心生产力是工人，信息社会的核心生产力是码农。经济学原理告诉我们：个人价值是通过稀缺性来体现的。看清趋势、拥抱趋势，才会让自己变得稀缺，才能让自己越走越顺！
|
|
|
|
|
|
到此刻为止，我们专栏的正文内容，就全部结束了。感谢你一直以来的陪伴！
|
|
|
|
|
|
还有一篇“结束语”，马上会和你见面，我们下一讲再见！
|
|
|
|