中年|危险了！基础运维人员们 |危险|人员|

别被标题吓尿了。
技术的发展，从来不以个人的意志为主转移，程序员的某些分工也必将随着技术的演进而消失。
在开始之前，我们首先来看一下Serverless是个什么概念。
Serverless直译为“无服务器” ，并不是说代码运行就不需要在服务器上跑了。它的意思是，未来的开发，无需关注服务器这种比较底层的设施，代码将会直接跑起来。这些资源将变得不可见。
危险了！基础运维人员们。

本文插图

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

事情会更加的复杂，服务器的数量一多，你需要考虑怎么快速部署；每台机器的配置，都需要进行精细的计算，包括JVM要分配多大的内存，网络的安全策略要如何配置，高可用，异地多活... ，诸多细节需要大量的准备工作和基础设施。
这种现状，我们现在的很多程序员，乐在其中。
就拿基础组件和一些中间件来说，什么分库分表、缓存、数据同步、监控、虚拟化、CI/CD.... 。内容都相差无几，但每一个上规模的公司，基本上都会自己搞一套。这养活了大量的从业人员，但从整个社会的投入和产出来说，这不合理。
为什么面试要造火箭，因为现阶段这玩意有时候还真用得着。
【中年|危险了！基础运维人员们】事情在变化
一个公司在发展到一定阶段的时候，会有大量的内部系统。比如运维系统，财务系统，员工管理系统等。除了少部分的开发人员持续迭代这些系统，后续的使用人员其实充当了变相的“运维”角色。
你需要申请一台机器。 ok ，填个工单吧。工单审批完毕之后， “运维”人员，在后台点巴点巴，一台虚拟机就创建好了。
你需要拿一下系统的用户列表。 ok ，填个工单吧。审批完毕之后， “运维”人员为你开放一个令牌，拿着令牌到我们的微服务里去拉信息去吧。

这些抽象的服务器，用户接口，不需要你去准备硬件、准备网络，只需要填个工单，唾手可得，已经有了一点Serverless的样子了。不过是企业内部的，规模也有限。
在这里，我们就需要了解一下几个缩写的名词。
1）IaaSInfrastructure-as-a-Service(基础设施即服务) 。此部分属于基础设施，比如服务器的购买、搭建，与虚拟化、容器等技术息息相关。
2）PaaSPlatform-as-a-Service(平台即服务) 。比如操作系统、虚拟机，以及在其之上，提供的与业务弱相关的基础组件。通常，一些耳熟能详的名词，如持续集成、中间件、公共组件、微服务等，属于此列。
3）SaaS Software-as-a-Service(软件即服务) 。生活中，几乎我们每一天都在接触SaaS云服务，但一般是指集中式部署的服务提供者。在这种模式下，商业模式变成了租赁的形态，销售变成了运营，项目变成了产品。
这4个名词的第一个字母，既预示着某项从业环境的改变。比如， IaaS的完备，使得专攻基础设施服务的工程师，逐渐没了发展空间；PaaS的完备，使得广大平台开发工程师就业路子越来越窄。除了少部分能够享受平台的红利，大部分只能向更高层的抽象去过渡。
这三者大家耳熟能详，但还有两个缩写，这才是Serverless的关键。

4）BaaSBackend as a Service（后端即服务）。是指公司为移动应用开发者提供整合云后端的边界服务。
这个词非常可怕。按照我们上面的逻辑，等它普及的时候，大部分后端开发工程师将消亡。稳定了这么多年的后端技术栈，终于要自己搞死自己了。
5）FaaSFunctions 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一旦普及，就会把大部分工程师带入不归路。还好，由于各大厂商并不是铁板一块，它们相互竞争和攻击，会让建设过程持续非常长的时间。
当然，如果一家独大，也是不必担心的。有三个原因：