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

栏目: IT技术 · 发布时间: 4年前

内容简介:原创:小姐姐味道(微信公众号ID:xjjdog),欢迎分享,转载请保留出处。别被标题吓尿了。

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 去了。

作者简介: 小姐姐味道 (xjjdog),一个不允许程序员走弯路的公众号。聚焦基础架构和Linux。十年架构,日百亿流量,与你探讨高并发世界,给你不一样的味道。我的个人微信xjjdog0,欢迎添加好友,进一步交流。

近期热门文章

996的乐趣,你是无法想象的

魔幻现实主义,关爱神经衰弱

一切荒诞的傲慢,皆来源于认知

不要被标题给骗了,画面感十足的消遣文章

《必看!java后端,亮剑诛仙》

后端技术索引,中肯火爆。全网转载上百次。

《学完这100多技术,能当架构师么?(非广告)》

精准点评100多框架,帮你选型

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


以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

构建高性能Web站点

构建高性能Web站点

郭欣 / 电子工业出版社 / 2009-8 / 59.00元

本书围绕如何构建高性能Web站点,从多个方面、多个角度进行了全面的阐述,涵盖了Web站点性能优化的几乎所有内容,包括数据的网络传输、服务器并发处理能力、动态网页缓存、动态网页静态化、应用层数据缓存、分布式缓存、Web服务器缓存、反向代理缓存、脚本解释速度、页面组件分离、浏览器本地缓存、浏览器并发请求、文件的分发、数据库I/O优化、数据库访问、数据库分布式设计、负载均衡、分布式文件系统、性能监控等。......一起来看看 《构建高性能Web站点》 这本书的介绍吧!

HTML 压缩/解压工具
HTML 压缩/解压工具

在线压缩/解压 HTML 代码

URL 编码/解码
URL 编码/解码

URL 编码/解码

正则表达式在线测试
正则表达式在线测试

正则表达式在线测试