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

小姐姐养的狗 2020-08-31 14:06:48
​别被标题吓尿了。

 

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

 

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

 

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

 

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

 

 

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

 

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

 

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

 

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

 

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

 

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

 

事情在变化

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

 

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

 

弹性!成本!

 

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

 

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

 

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

 

时间!敏捷!

 

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

 

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

 

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

 

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

 

 

一些变化

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

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

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

 

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

 

作者丨小姐姐味道
来源丨小姐姐味道(ID:xjjdog)
dbaplus社群欢迎广大技术人员投稿,投稿邮箱:editor@dbaplus.cn
 
最新评论
访客 2023年08月20日

230721

访客 2023年08月16日

1、导入Mongo Monitor监控工具表结构(mongo_monitor…

访客 2023年08月04日

上面提到: 在问题描述的架构图中我们可以看到,Click…

访客 2023年07月19日

PMM不香吗?

访客 2023年06月20日

如今看都很棒

活动预告