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

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

内容简介:原创:小姐姐味道(微信公众号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,会将工程师带入“不归路”!


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

查看所有标签

猜你喜欢:

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

Types and Programming Languages

Types and Programming Languages

Benjamin C. Pierce / The MIT Press / 2002-2-1 / USD 95.00

A type system is a syntactic method for automatically checking the absence of certain erroneous behaviors by classifying program phrases according to the kinds of values they compute. The study of typ......一起来看看 《Types and Programming Languages》 这本书的介绍吧!

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

在线压缩/解压 HTML 代码

RGB转16进制工具
RGB转16进制工具

RGB HEX 互转工具

在线进制转换器
在线进制转换器

各进制数互转换器