写点什么

程序员需要关注的四大技术趋势

  • 2021-05-17
  • 本文字数:4167 字

    阅读完需:约 14 分钟

程序员需要关注的四大技术趋势

作者 | 刘尚奇

编辑 | Eva


大家好,我是来自 ThoughtWorks 的刘尚奇,今天跟大家分享的话题是技术世界的宏观趋势。


现在是一个技术发展非常快的时代,对于技术人而言,面对层出不穷的新技术,怎么跟上节奏?怎样去学习?很多人对此可能无所适从。不光是个人,公司和组织也是如此,如何让组织跟上技术最新发展,保证组织竞争力?这是在这个第四次工业革命时代每个组织都在面对的挑战。


所以今天跟大家分享的是通过技术雷达捕捉到的技术世界的重要趋势。我们今年 6 月 2 号在深圳有一个技术雷达峰会,会更深入地解析最新技术趋势,分享我们的洞见和观点,大家有兴趣可以关注。


技术雷达


ThoughtWorks技术雷达大家可能有所了解,每年会发布两期,也有一个在线网站。雷达的内容是对当前技术发展的快照,覆盖了技术、平台、语言框架和工具。雷达的输入都是来自于我们一线技术人员的观察和实践。


坦白讲,这类技术趋势分析的报告在业界有不少,比较著名的有 GitHub 和 Stackoverflow 的年终的总结、Gartner 的 Hypecycle 等。但这类传统的报告要么是对历史数据的总结回顾,可能没有办法预测未来的趋势,而且要么来自远离实际技术工作的分析师和观察家,对一线技术人员来说有些遥远。


相比而言,我们更加相信优秀的一线技术人员通过实际工作中获得的经验和判断。我们做技术雷达的时候很重要的输入是前线技术人的声音,了解技术在真实的世界中是如何被采用。


四个技术趋势


Browser Bulks Up, Server Slims Down(浏览器增强,服务器式微)


第一个主题趋势叫做 Browser Bulks Up, Server Slims Down,我们发现很多的开发工作的复杂度会转移到浏览器端,而后端的复杂度在逐渐降低或者说得到控制。这个趋势已经持续了一些年。


曾经服务器端为王的时代,大部分时间我们希望把业务逻辑放到服务器端上,给前端留一些轻量的页面布局和表单验证工作。技术雷达从 10 年提出将 JavaScript 作为一等公民语言,并在 13、14 年的主题趋势强调了 JavaScript 生态的爆发。人们开始越来越多的意识到 JavaScript 也可以做主力语言 (Atwood Law)。你会看见在前端社区生态涌现了了非常多的工具。如今国内的一些互联网公司有着非常大的前端团队,并且出现了前端架构师这样的职位去管理前端的复杂度,这在以前是不可想象的。前端相关的工具也开始从最早的简单的 ajax 类库,到 MVC/MVVM 框架到现在的组件化趋势,甚至发展出很多的细分方向,比如像 Redux、Flux 这样专门做 statement 的库。


一方面前端的复杂度在增加,另外一方面后端的复杂度也在减少。过去很多人会以自己是后端程序员为豪,因为后端需要涉及到服务器端开发方方面面知识,但是这几年随着容器技术以及 PaaS 相关技术的崛起,你会发现像认证授权、负载均衡、注册发现等越来越多的 cross concernerd 的逻辑,包括把我的软件部署到不同环境中的工作,都已经被 PaaS 平台本身接管了。


据我所知,很多公司正在建立一体化的数字化交付平台。这样的平台让代码从迁入到部署到生产环境变成完全一个自动化的过程,并且提供开箱即用的监控和运维支持。这个领域在自动化之上我们还看到了 AIOps 和 ChaosEngineering 等趋势。在有着一套非常完备平台的组织里面做后端应用程序开发,用微服务的架构方式写应用。你会发现你面对的都是一些 big clean 的业务逻辑,以 API 的方式呈现出来,输入输出都非常清晰明确。后端反而变成了一个相对比较简单的工作。


有人可能会问 Browser Bulks Up, Server Slims Down 这个趋势已经持续很久了,这个趋势还会持续下去吗?我个人看来,至少在未来的六到十八个月,这个趋势仍然会继续。


因为现在人们对客户端的用户体验有更多要求,现在浏览器也发展出来了很多 Native API,可以充分利用设备的能力,包括 mobile device 的一些 sensor。再如比如这期技术雷达观察到随着 WebAssembly 的引入可以进一步释放浏览器的潜力。


因此我认为在可见的六到十八个月内这个趋势仍然会继续。客户会持续要求更好的用户体验,产品的多设备、多平台战略会持续发展;而在后端开发上,你的数字化平台的自动化和 Devops 能力在持续完善和优化,后端开发会投入更多精力在业务功能本身。


Creeping Cloud Complexity


另外一个比较有意思的趋势,我们叫做 Creeping Cloud Complexity,意思是云的复杂度会增加。其实很久以来,当我们说到云,可能只把它当成一个 IaaS,但随着虚拟化技术崛起,以及容器化技术的崛起,我们逐渐觉得云的作用不仅仅是把软件搬到企业的机房之外,它更多的能够实现云当初给我们的一些承诺,它可以做到弹性伸缩,按需使用,自助式服务。然而在使用云的过程中,尽管会有像 Docker 这样的技术帮我们去 handle 云的复杂度,我们也看到,随着很多企业采用云,云也遇到了一些挑战和问题。


我们观测到的一个趋势是:很多的企业采用云的时候会选择 Polly Cloud,即混合云的一个策略。Polly Cloud 跟 Hybrid Cloud 是有区别的,Hybrid Cloud 是指公有云跟私有云相结合,但 Polly Cloud 是指你去选用一个公有云的时候,你会去考虑不同的公有云在特定领域的差异化能力。


AWS、微软的 Azure、Google 的 GCE、国内的阿里云,不同平台的通用能力是非常类似的,这个时候平台会去强调自己一些特有的能力,比如说 Google 的 GCE 会强调他们的 GKE 服务来帮你托管你的 k8s,如果你想要,或者你已经在这个项目里使用了 k8s,你可以很轻松迁移到 Google 的 paltform 上。另外像微软可能跟以太坊等 Blockchain 技术合作,建立起来一系列的 Blockchain as Service 服务。你会发现不同的云,其实在一些通用的能力之外,都在试图建立自己差异化的优点。


面对这种情况,一些企业采用多供应商策略,一方面不想被某种云绑定,另一方面也出于对某种特殊能力的需求。这个时候云的复杂度是在上升的,因为你不光是要去了解使用平台本身,你还要能够去合理地管理不同的云平台,我们技术雷达也推荐了相关的一些条目,讲怎样管理多个云平台。


Trust but Verify 和 things Evolve


我们接着讲两个话题,一个话题叫做 Trust but Verify;一个是叫做 things Evolve。


Trust but Verify 是苏联的一个谚语,意思是相信但是要验证。最初是用在美苏争霸核威慑的语境下,这里指的是企业的信息安全策略。很多企业的安全策略会把世界当成非黑即白,觉得在我的企业的网络外部,我不做任何信任,但是在我的企业网络的内部就是绝对安全的,不做任何的检查。而 Trust but Verify 就是说信任、但总是要验证。


比如 Google 前段时间提出 BeyondCorp,推行一个叫做 Zero Trust 的实践,员工在上网的时候,我可以不用在办公室,从一个未受信任的网络能够正常访问我的工作环境。这就意味着,这个用户可以访问哪些内容,有什么样的权限,并不由他所进入的网络决定。而不像传统的 IT 安全策略,不信任域外的任何东西。


第二个事情是说,任何一个进入网络的用户,他都需要经过非常严格的身份跟授权认证,就是说我虽然 Trust,我并不会区分你的网络在哪里,但是我一定会去 Verify 你的身份和权限。这跟传统 IT 安全策略的不同是,传统策略在域内几乎不会做任何验证,可以为所欲为。我们建议 Trust but Verify,而不是基于非黑即白的域环境隔离来建立你的安全策略。


还有一个主题比较有意思,叫做 Things Evolve,我姑且翻译成万物演进,此处的 things 是 IOT(Internet of  things)里面 things。


我们发现 IOT 相关的一些生态和实践正在变得更加成熟,比如我们最近发现一些 IOT 平台,以前你可能会选择自己去做 IOT,因为 IOT 除了设备本身,更多的需要一个中央的平台去管理这些设备,你需要去收集设备的信息,你需要去下发指令,你需要去做监控,今天你可以很好地利用阿里云的 IOT 平台、AWS 的 IOT 平台,你会发现云平台提供的 IOT 的能力足够管理你的设备,你只需在设备上装一个非常简单的 SDK。


今天你如果再想做一个智能家居,是一件非常容易的事情,另外随着硬件的发展,今天你可以看到非常多智能硬件。在今年年初的一个 hackathon 上,我们就用 IoT 加 blockchain 做了一个去中心化智能锁。锁是一个非常好的隐喻,它象征着对物理世界的所有权的访问控制。而通过 Blockchain,你在一个数字世界里可以对你财产的所有权进行声明和控制。


Block chain 跟一个物理的锁结合,你可以给这个锁创建一个钱包,跟这个锁进行绑定,当你向这个锁支付一些以太币的时候,在这个锁上会跑一个智能合约,你可以把这个锁打开,获得这个锁一段时间的使用权限。这个有点像有很多自动储物柜,只不过你把这个锁跟这个 Blockchain 的 smart contract 连到一块的时候有非常多的可能性,你把锁放到房间里,就是一个去中心化共享租房,你把锁放到一个自行车,它就是一个去中心化共享单车,很有意思。


今天的 IOT 的一些 Device、设备、工具链,包括它的一些平台发展的非常成熟,即使对硬件开发完全没有经验的技术人员,也能够通过一些 IoT 设备的 SDK 和平台,非常容易的 DIY 一些你想做的应用。


微服务、AI 和 Blockchain


最后讲几个大家比较关心的热点话题:微服务、AI 和 Blockchain。这几个技术目前热度非常高,但这次没有进入我们的技术雷达,我会讲一下没有进入的原因。


微服务很火,但我们对微服务的采用一直持比较谨慎的态度,记得 16 年左右,我们提出了一个条目叫做微服务的羡慕忌妒恨,意思是说,可能很多的项目和组织并不适合用微服务,微服务并不是银弹。


我在咨询工作中看到有些项目,采用微服务的力度并不够,可能拆分力度过细,或者虽然拆成了微服务,但是并没有从合理的微服务划分中获得足够多的好处,它只是看起来变成了一个个的服务,但是它的数据库有可能耦合在一起,以前你可能在一个系统里面写完代码,发布上线就可以了,现在你每次业务变更都需要改好多个服务,而且在服务之间你需要去处理容错。


这就需要回到本质,微服务是一个架构风格,你还得为自己的架构决策负责,要根据自己的实际情况去检测考虑,这不光是一个技术和工具的问题,因为技术跟工具已经不是门槛了,更多的是我们人对业务的理解,以及设计问题。


我们再去讲一下 AI 和 Blockchain,目前人工智能和区块链的话题很热,但也没有列入本期的技术雷达主题趋势里。其实我们在之前几期雷达趋势里做出对 AI 和 Blockchain 相关的主题趋势判断后,市场上很快迎来了爆发。但在目前非常大的喧嚣声下,我们并没有看到预期中那么多真正产生价值的应用。我们认为对 AI 和 Blockchain 的投入不应只炒热点,更应该是长期的对未来的投入。


2021-05-17 14:474894

评论

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

架构师训练营第 1 期第 2 周学习总结

du tiezheng

极客大学架构师训练营

架构师训练营第 2 周作业

netspecial

极客大学架构师训练营

监控应用,应该监控什么?

小清新同学

云计算 运维 监控

高难度对话读书笔记—认知篇2

wo是一棵草

关于Java 编译Servlet或者自定义Tag,引入包的问题

谷鱼

Java

项目实战,动态增删form表单

麦洛

jquery 克隆

RN运行项目报错:Unable to resolve module `./debugger-ui/debuggerWorker.js` from ``

凌宇之蓝

ios android React Native

虚拟卡兑换架构设计

孙志平

架构师训练营第 1 期第 2周作业

du tiezheng

极客大学架构师训练营

保留时序数据波动细节的一种采样算法

小清新同学

监控 时序数据库

刷爆朋友圈的字节跳动编码题,今天把解析思路分享下!

Java架构师迁哥

如何设计Go语言中的channel

soolaugust

channel goroutines Go 语言

架构师训练营第二周学习总结

尹斌

不一样的面向对象(二)

书旅

php 面向对象

如何快速制造OOM

Since

JVM OOM

Python 自动化测试全攻略:五种自动化测试模型实战详解

葡萄城技术团队

自动化测试

架构师训练营第 1 期第二周课后练习题

Leo乐

极客大学架构师训练营

上班路上也是一道美景

xcbeyond

生活 摄影 摄影征文

难得干货,揭秘支付宝的2维码扫码技术优化实践之路

JackJiang

支付宝

从大数据的角度来谈谈运维监控这件事儿

小清新同学

运维 监控

程序执行太慢?快来学习SIMD加速技术,这个案例下的加速效果我也没想到(附带动手实验)

Optimize-Lab

优化代码 优化技巧 开源社区 simd Go 语言

Go中的HTTP请求之——HTTP1.1请求流程分析

Gopher指北

HTTP Go web Go 语言

MySQL varchar类型最大值,原来一直都理解错了

架构精进之路

MySQL varchar

架构师训练营第二周作业

尹斌

什么才是“应用拓扑”?

小清新同学

运维 监控

2B还是2C,这真是个问题

MavenTalker

SaaS

自己动手写SQL执行引擎

无毁的湖光

Java MySQL 数据库 Linux 算法

java安全编码指南之:可见性和原子性

程序那些事

Java java安全编码 java编码指南 java安全编码指南

收藏+下载!Flink 社区最全学习渠道汇总

Apache Flink

flink

缓存解决方案-技术专题-Caffeine Cache

洛神灬殇

Dolphinscheduler系统架构设计

dll

Apache DolphinScheduler

程序员需要关注的四大技术趋势_语言 & 开发_Thoughtworks_InfoQ精选文章