Serverless,会将工程师带入“不归路”!

Stella981
• 阅读 417

Serverless,会将工程师带入“不归路”!

原创:小姐姐味道(微信公众号ID:xjjdog),欢迎分享,转载请保留出处。

别被标题吓尿了。

技术的发展,从来不以个人的意志为主转移,程序员的某些分工也必将随着技术的演进而消失。

在开始之前,我们首先来看一下Serverless是个什么概念。

Serverless直译为“无服务器”,并不是说代码运行就不需要在服务器上跑了。它的意思是,未来的开发,无需关注服务器这种比较底层的设施,代码将会直接跑起来。这些资源将变得不可见。

危险了!基础运维人员们。

Serverless,会将工程师带入“不归路”!

想象一个Java应用的开发过程。你需要经过开发、测试、部署,才能正常上线。如果是一个高并发的应用,就需要预估一个峰值,比如,需要100台服务器,才能支撑用户的请求。有产品经理脑袋一热,加了秒杀的功能,那么你的峰值,就需要按照秒杀的峰值进行设计,即使这个峰值过程持续了不到10秒,一哆嗦之后所有的资源都会被闲置。也就是说,服务器放在那里即使不用,你也要为此付费。

老板捂着心口说痛,猝死了。

事情会更加的复杂,服务器的数量一多,你需要考虑怎么快速部署;每台机器的配置,都需要进行精细的计算,包括JVM要分配多大的内存,网络的安全策略要如何配置,高可用,异地多活...,诸多细节需要大量的准备工作和基础设施。

这种现状,我们现在的很多程序员,乐在其中。

就拿基础组件和一些中间件来说,什么分库分表、缓存、数据同步、监控、虚拟化、CI/CD....。内容都相差无几,但每一个上规模的公司,基本上都会自己搞一套。这养活了大量的从业人员,但从整个社会的投入和产出来说,这不合理。

为什么面试要造火箭,因为现阶段这玩意有时候还真用得着。

事情在变化

一个公司在发展到一定阶段的时候,会有大量的内部系统。比如运维系统,财务系统,员工管理系统等。除了少部分的开发人员持续迭代这些系统,后续的使用人员其实充当了变相的“运维”角色。

你需要申请一台机器。ok,填个工单吧。工单审批完毕之后,“运维”人员,在后台点巴点巴,一台虚拟机就创建好了。

你需要拿一下系统的用户列表。ok,填个工单吧。审批完毕之后,“运维”人员为你开放一个令牌,拿着令牌到我们的微服务里去拉信息去吧。

这些抽象的服务器,用户接口,不需要你去准备硬件、准备网络,只需要填个工单,唾手可得,已经有了一点Serverless的样子了。不过是企业内部的,规模也有限。

在这里,我们就需要了解一下几个缩写的名词。

IaaS Infrastructure-as-a-Service(基础设施即服务)。此部分属于基础设施,比如服务器的购买、搭建,与虚拟化、容器等技术息息相关。

PaaS Platform-as-a-Service(平台即服务)。比如操作系统、虚拟机,以及在其之上,提供的与业务弱相关的基础组件。通常,一些耳熟能详的名词,如持续集成、中间件、公共组件、微服务等,属于此列。

SaaS Software-as-a-Service(软件即服务)。生活中,几乎我们每一天都在接触SaaS云服务,但一般是指集中式部署的服务提供者。在这种模式下,商业模式变成了租赁的形态,销售变成了运营,项目变成了产品。

这4个名词的第一个字母,既预示着某项从业环境的改变。比如,IaaS的完备,使得专攻基础设施服务的工程师,逐渐没了发展空间;PaaS的完备,使得广大平台开发工程师就业路子越来越窄。除了少部分能够享受平台的红利,大部分只能向更高层的抽象去过渡。

这三者大家耳熟能详,但还有两个缩写,这才是Serverless的关键。

BaaS Backend as a Service(后端即服务)。是指公司为移动应用开发者提供整合云后端的边界服务。

这个词非常可怕。按照我们上面的逻辑,等它普及的时候,大部分后端开发工程师将消亡。稳定了这么多年的后端技术栈,终于要自己搞死自己了。

FaaS  Functions as a Service (功能即服务)。可以广义的理解为功能服务化,也可以解释为函数服务化。使用FaaS只需要关注业务代码逻辑,无需关注服务器资源,所以FaaS也跟开发者无需关注服务器Serverless密切相关。可以说FaaS提供了一个更加细分和抽象的服务化能力。

这就可以想象到,如果各项设施完备之后,只需要水平一般的前端集成人员,就可以完成企业级的开发。

信息革命的本质就是自我升级然后自我替换,程序员能选择的路子将越来越窄。计算机技术将回归工具的本质,人人得而用之,不再是一部分人的专利。

Serverless,会将工程师带入“不归路”!

你可能觉得,这玩意,和现在的云环境有什么区别?区别还是有的,否则不会有这么多大厂趋之若鹜。现阶段,Serverless是云厂商的事,和普通开发者关系不大。但最后,这些新生事物,都会慢慢侵蚀我们传统的领地。

弹性!成本!

我们上面就已经举例了,现阶段的服务端软件开发,需要根据峰值进行设计。买了服务器之后,哪怕是云主机,大部分时间也是空跑。空跑也是要付费的,这也是为什么企业的IT费用居高不下,它要为很多压根用不着的东西一直花钱。

Serverless是按需收费的,用多少收多少。比如你的服务QPS在10w的时候,给你分配10台机器,降到2W的时候,给你分配2台机器,那就可以足足省下4/5的money。

这种弹性看似神奇,不过也是建立在一些目前的技术上的。比如kubedocker等。但这是云厂商的事,对企业来说,那就是服务拥有了巨大的弹性,节省了大量的成本。等老板们尝到这种功能的甜头,还养一堆眼里只有技术的人干什么呢?

时间!敏捷!

Serverless的形态,肯定是大的生态,也就是有非常多的完善的功能积木,开发人员进行组装即可。

云厂商会保证功能函数的正常运行,以及升级迭代,向后兼容等特性,企业压根不会再投入精力到一些既有的功能上来。

比如,建设一个直播的基础设施,是非常昂贵且漫长的。如果Serverless提供了这样的功能模块,企业就可以直接拿来用。

这种租用的方式,不仅便宜,而且快捷。以往需要开发一年半载的产品创意,到现在只需要几天就可以上线。这就是复用的魔力。

Serverless,会将工程师带入“不归路”!

一些变化

可以看到,在这种模式下,很多职业都将产生变化。

运维工程师?不再需要了,只需要操作配置后台,就能够获取稳定、安全、便宜的主机。

中间件工程师?需求变小了。企业不会再养这部分又贵又难找的人来做这些基础设施。只需要操作配置后台,使用云厂商暴露的功能函数,就可以漂亮的完成工作。

后台开发工程师?需求变小了。不再需要非常复杂的逻辑,做什么前后端分离,做什么复杂的分布式锁和数据同步等。只需要关注业务逻辑就可以了。

前端工程师?这个时候前端还叫做前端么?应该叫全栈。只要会玩乐高积木,就能根据图纸拼接零件,在功能模块足够丰富的前提下,这些都不是魔幻的。

程序员的API,不再是什么Kafka,Redis等,反而会是云厂商提供的一大批自定义的函数。

这对安于现状的工程师来说,真的是挑战。其实从最近几年的云主机普及就能够看出来,有些职业,真的是慢慢的变成了后台管理员。本质上,这与淘宝小二操作的后台,没有什么不同。

本质都是:了解平台的规则(函数),作出相应的推广(集成)。

面向Serverless编程,实在是无趣的多。

在时代的浪潮中,个体总是容易被抛弃的,我们毫无疑问已经进入了终身学习的年代---苦逼的程序员尤其如此。

Serverless,会将工程师带入“不归路”!

工具抽象程度高了,并不意味着工程师的素养要求就低了。由于Serverless并没有什么标准,它仅是一种理念,那么各个厂商的实现方式肯定不相同。

作为企业的老板,肯定会有这样的担忧:我不能把鸡蛋放在一个篮子里,受一个厂商的绑架。比如现在有的老板用了阿里云,还会考虑腾讯云、信仰云等等。

使用了A平台提供的功能函数开发的应用,是很难迁移到B平台的。厂商们都希望垄断,往往也不会这么干,那就会造成工程师的学习成本加大。

另外,Serverless厂商的能力毕竟有限,无法覆盖所有的基础业务功能场景。肯定会有厂商,采用开发者平台的方式,吸纳外部的功能组件。开发这部分工功能组件的开发者,也有较高的要求。

我猜测未来会有插件模式的云功能市场,用来丰富这个生态。

各种开源软件的版权也应该有所变化。就像现在的云主机,拿着开源的软件大赚特赚,白嫖了这么多年,而软件开发者却无法从中受益,这是严重不合理的。

那未来的程序员是什么样子呢?

平台开发工程师。搭建云Serverless平台,保证基础设施的完善。这是大厂才玩的事情。

插件功能工程师。按照平台的规则,开发相应的功能,享受售卖的提成;或者受雇于特定的公司,开发此类功能。这是相对头部的工程师。

业务开发工程师。从海量的功能组件中,寻找积木,搭建产品。这和现在在gayhub上寻找功能,集成到项目中是一样的道理。这也就是占比最大的人员。

Serverless一旦普及,就会把大部分工程师带入不归路。还好,由于各大厂商并不是铁板一块,它们相互竞争和攻击,会让建设过程持续非常长的时间。

当然,如果一家独大,也是不必担心的。有三个原因:

第一,天下大势,分久必合,合久必分。大厂的霸道会造成众叛亲离。造成一定程度上的技能回归。

第二,怀旧会让人如痴如醉,很多东西不会消亡。比如我现在还喜欢超级玛丽。

第三,等能活到那一天再说吧。可能和传说中的人工智能一块到来。

不多说了,我要研究AWS Lamba去了

本文分享自微信公众号 - 测试技术圈(SoftwareTesters)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

点赞
收藏
评论区
推荐文章
blmius blmius
3年前
MySQL:[Err] 1292 - Incorrect datetime value: ‘0000-00-00 00:00:00‘ for column ‘CREATE_TIME‘ at row 1
文章目录问题用navicat导入数据时,报错:原因这是因为当前的MySQL不支持datetime为0的情况。解决修改sql\mode:sql\mode:SQLMode定义了MySQL应支持的SQL语法、数据校验等,这样可以更容易地在不同的环境中使用MySQL。全局s
皕杰报表之UUID
​在我们用皕杰报表工具设计填报报表时,如何在新增行里自动增加id呢?能新增整数排序id吗?目前可以在新增行里自动增加id,但只能用uuid函数增加UUID编码,不能新增整数排序id。uuid函数说明:获取一个UUID,可以在填报表中用来创建数据ID语法:uuid()或uuid(sep)参数说明:sep布尔值,生成的uuid中是否包含分隔符'',缺省为
待兔 待兔
4个月前
手写Java HashMap源码
HashMap的使用教程HashMap的使用教程HashMap的使用教程HashMap的使用教程HashMap的使用教程22
Jacquelyn38 Jacquelyn38
3年前
2020年前端实用代码段,为你的工作保驾护航
有空的时候,自己总结了几个代码段,在开发中也经常使用,谢谢。1、使用解构获取json数据let jsonData  id: 1,status: "OK",data: 'a', 'b';let  id, status, data: number   jsonData;console.log(id, status, number )
Easter79 Easter79
3年前
ThreadLocal夺命4问
!(https://oscimg.oschina.net/oscnet/2f6fbfdeae82468caf24c544f39da9ec.gif)原创:小姐姐味道(微信公众号ID:xjjdog),欢迎分享,转载请保留出处。阅读本文需要首先大体了解ThreadLocal。不啰嗦,直接进入正题。标签:【各种级别】【Java】【源码
Wesley13 Wesley13
3年前
mysql设置时区
mysql设置时区mysql\_query("SETtime\_zone'8:00'")ordie('时区设置失败,请联系管理员!');中国在东8区所以加8方法二:selectcount(user\_id)asdevice,CONVERT\_TZ(FROM\_UNIXTIME(reg\_time),'08:00','0
Stella981 Stella981
3年前
Django中Admin中的一些参数配置
设置在列表中显示的字段,id为django模型默认的主键list_display('id','name','sex','profession','email','qq','phone','status','create_time')设置在列表可编辑字段list_editable
可莉 可莉
3年前
10条Linux命令锦囊,防你牢底坐穿
!(https://oscimg.oschina.net/oscnet/b9a8860b3b8e4b598f3918ada9facce9.gif)http://xjjdog.cn对200原创文章进行了细致的分类,阅读更流畅,欢迎收藏。原创:小姐姐味道(微信公众号ID:xjjdog),欢迎分享,转载请保留出处。任何不保留此声明的
Wesley13 Wesley13
3年前
MySQL部分从库上面因为大量的临时表tmp_table造成慢查询
背景描述Time:20190124T00:08:14.70572408:00User@Host:@Id:Schema:sentrymetaLast_errno:0Killed:0Query_time:0.315758Lock_
为什么mysql不推荐使用雪花ID作为主键
作者:毛辰飞背景在mysql中设计表的时候,mysql官方推荐不要使用uuid或者不连续不重复的雪花id(long形且唯一),而是推荐连续自增的主键id,官方的推荐是auto_increment,那么为什么不建议采用uuid,使用uuid究