头图

Serverless 背景下,一部分“前端工程师”会转变为“应用交付工程师”

杨成功
English
本文来源公众号:程序员成功

大家好,我是杨成功。

这是我的 2022 年第一篇文章。一直在想写些什么比较好,既然是新年,新年新气象,写点技术展望的想法是不是更合适?于是这篇文章的标题,也就是本文的核心思想出来了:

Serverless 背景下,一部分“前端工程师”会转变为“应用交付工程师”

这里有三个名词:

  • Serverless
  • 前端工程师
  • 应用交付工程师

下面就从这三个方面,聊一下我对 2022 前端的展望。

Serverless

什么是 Serverless?

单从意思理解,非常明显,就是很少的服务

我觉得这个理解就很好。因为现在大家对 Serverless 的翻译是 无服务,真正无服务吗?也不是,我们先来看一下它的具体概念:

【Red Hat】Serverless 是一种云原生开发模型,可使开发人员专注构建和运行应用,而无需管理服务器。

听不懂?大白话翻译一下。就是说以前的服务啊,比如说我们前端要对接的接口应用,它们是要部署在 服务器上 的。后端同学要开发一套接口,首先得申请一台服务器,然后将应用部署到这个服务器上,用域名解析一下,才能给到前端接口 URL 地址,供前端调用。

但是 Serverless 出现以后,即便没有服务器,不懂运维,在线上部署应用也成为了可能。

关键点就在:没有服务器,也能部署应用

那怎么部署呢?先看一下 Serverless 的两种形式:

  • BaaS:全称 Backend as a Service,译为后端即服务。
  • FaaS:全称 Function as a Service,译为函数即服务。

BaaS 是指一个服务端应用,也叫云应用。举个例子,我们常用的阿里云的云数据库对象存储,都属于 BaaS。事实上不管是数据库还是静态资源存储,我们完全可以自己在服务器上搭建。但是因为有了像 云数据库 这类的产品,我们可以绕过服务器,直接使用一个云端的数据库。

这就是 “无服务” 的第一层概念:淡化服务器,直接接触服务端应用

注意:这里是淡化服务器,并不是真正的没有服务器。只不过是云厂商已经将服务器进行了抽象封装,暴露给开发人员的直接是应用,因此对开发人员来说好像是无服务。

BaaS 最广泛的应用在后端,因为后端好多基础设施(如数据库,日志等)不用手动搭建了,有云厂商标准稳定的支持,可以把精力集中到业务逻辑上。

但是随着前端的快速发展,以及后端的云原生化,有些奇思妙想的大佬就这么想了:“前端调用后端接口,都是在前端的一个函数中发起请求,这样的话就必然需要后端提供一个接口服务。那我们是不是可以这样,直接将这个函数部署在云上,变成云函数,供前端直接用,是不是就不需要后端的接口了?”

大佬一拍大腿,这想法竟然如此绝妙。这么干的话,前端岂不是要翻身农奴把歌唱?于是大佬们将 server 继续 less,于是 FaaS 就出现了。

FaaS 是一种面向函数的构建和部署软件的方式,也就是云函数。FaaS 是对 BaaS 的又一次升级,在淡化服务器的基础上,又淡化了应用,直接向前端暴露函数。以前我们前端的函数都是本地声明,本地调用。现在云函数是单独部署在云上,供我们前端远程调用。

这是 “无服务” 的第二层概念:淡化服务器,淡化应用,直接接触函数

事实上,Serverless 在发展到 FaaS 阶段,才真正对前端产生了变革式的影响。

前端工程师

什么是前端工程师?

早年的前端工程师更像是“页面工程师”,绝大部分人的工作就是用“三驾马车”将设计图做成一张网页,直到现在还有很多后端开发对前端的印象就是如此。

但是近几年大家发现,前端工程师仿佛一直在“外卷”,不断的拓展边界。虽然还是顶着“前端工程师”的帽子,但是干的事情早已经超出了传统前端范畴。

从”拓展边界“这个事情来说,大致分两个方向:

  • 向前:往产品和设计靠
  • 向后:往后端和运维靠

向前表现为,一部分前端开始对自己做的东西,会更多的思考“为什么”?

以前是产品确定到设计出图,前端只需要还原设计图就好了。理想如此,但实际情况是有些地方产品和设计考虑不到,等落实到前端这才发现不可行,于是呢就只能“改需求”或“推倒重来”,这是前端最反感的事情。

这种情况一多,就会倒逼前端们不得不思考:这个页面设计合不合理?交互方面有没有问题? 如果有问题,那这个需求我们就不接,产品先回去捋清楚了再说。这样大大减少了前端的无用功,提升了开发效率,也渐渐培养了前端的产品思维。

除了产品思维,前端也在思考,如何在设计层面让“图”变成“代码”更容易。于是近年来出现了很多设计图转代码的方案,比如蓝湖,还有阿里的 imgcook。这些实践方案让一个应用从设计之初,就有了前端的影子。

而向后发展的表现,典型是 Node.js 出现以后,以 Express 为代表的超轻量框架,因为相对简单又是 JS 语言,因此在前端圈掀起了一股 “全栈开发” 的热潮。这不是没有原因的,有些小应用就是适合用 Node.js 写,速度快效率高用过都说好。

但是在一些大型生产应用上,前端就够不着了。特别是云原生出现以后,后端的门槛蹭蹭的上来了。我相信有很多优秀的前端工程师,用 Node.js 接个数据库,写一些业务逻辑的接口,完全没有问题。但是如果让你搞一些后端的高级玩法,做一些服务器运维的事情,你可能就整不来了。

哪些算高级?之前在网上看到对后端大佬的描述挺有意思,是这么说的:左手高并发,右手高可用,头顶中间件,脚踩微服务,怀抱云原生,这就是大佬的全套战甲。

所以你看看,后端围墙高筑,把妄图横插一脚的前端挡在了门外。至此后端深耕,前端也在不断的尝试中找到了自己的方向,大家各自干各自领域的事情,互不纠缠。

但是 Serverless 特别是 FaaS 出现以后,这个平衡开始出现了微妙的变化。

应用交付工程师

什么是“应用交付工程师”?

首先声明一点,这个不是官方概念,是我在思考前端向后发展时萌生的。

我们上面说了,传统前端工程师的职责,就是把设计图做成网页,但随着 Node.js 出现,前端开始有更多的机会接触到后端。对于某些小应用,一部分优秀的前端可以靠自己完成前端和接口,然后上线,不需要后端参与。

这部分人我们可以称作是“全栈工程师”。所谓的全栈要么是一端深一端浅,要么是两端都浅(当然超级大牛忽略),所以开发小应用可以,大型生产应用就没全栈什么事了。

而现在随着 Serverless 云函数横空出世,屏蔽了服务器和后端应用的部分,使后端开发门槛大幅降低。前端仿佛又看到了希望,我们可以不用写接口,只需要编写云函数,也能实现生产应用的后端开发。

以前有高墙,前端卷不进来。现在墙拆了,你说我们进不进?

典型的例子是微信小程序云开发。前端在微信开发者工具上编写云函数,一键上传与部署。然后在小程序代码中获取并调用这个远程函数,相当于整个流程前后端都是自己实现自己调试,直到应用开发完成。这就是一个典型的“前端工程师”转变“应用交付工程师”的例子。

使用 Serverless 云函数不光能轻松实现后端的业务功能,而且监控,并发,负载这些由云厂商统一实现,一应俱全。因此在稳定性可靠性上也非常有保障。

还有一点,目前可能是大家的观念问题,认为单独的云函数服务需要自己付费,还不如自己直接在云服务器上部署应用。事实上函数计算是按照调用次数,访问流量计费的,比云服务器要更节约资源更省钱。

这个观念我认为 2022 年会在大厂推动下逐步放开,越来越多的 web 应用也会接入 serverless,因此更多的前端开发工程师会转变为应用交付工程师。

以前前端要实现一些自己的想法,必须要有后端的接口配合,而且还需要后端或运维帮忙在线上部署。但是现在不用了,我们有机会自己搞定这一切。我觉得这对前端来说是巨大的机会,一个可以将产品和自己的想法,直接产出一个应用的好机会。

除此之外,前端的协作模式可能也会发生变化。以前的一个大应用,前端组是分模块开发。但是现在有了 Serverless,再加上去年已经逐步成熟的微前端,前端协作模式很可能由 “一个模块一个模块开发” 变成 “一个应用一个应用开发”,这是一件非常酷的事情。

还有向前拓展时培养的产品思维,前端未来可能是最了解整个应用的人,所以前景不必多说。

加油吧,前端人们!2022 祝大家升职加薪,再攀高峰!

我想学更多

为了更好的保护原创,本文会首发微信公众号  前端砍柴人。这个公众号只做原创,每周至少一篇高质量文章,方向是前端工程与架构等实践与思考。

除此之外,我还建了一个微信群,专门提供对这个方向感兴趣的同学交流与学习。如果你也感兴趣,欢迎加我微信  ruidoc  拉你入群~

阅读 3.2k

程序员成功
分享工程与架构,前端边界探索等实践
avatar
杨成功
前端架构师

分享小厂可落地的前端工程与架构

3.5k 声望
11.9k 粉丝
0 条评论
avatar
杨成功
前端架构师

分享小厂可落地的前端工程与架构

3.5k 声望
11.9k 粉丝
文章目录
宣传栏