工程师的未来

今天本来在睡午觉，突然感觉有种写东西的冲动，爬起来把最近一直在思考的事情记录一下。

如今开发软件的方式正在发生深刻的变革，回想起刚毕业的时候做软件开发工程师，和现在已经截然不同了。

最早运维工程师往往是公司里一个独立的团队，公司租用公共机房的机器，大一些的公司也会选择自建机房。上架新机器（俗称扩容）是个流程繁复的事情，从公司决定采购到物理机器到位这中间有很长的时间间隔。

在实际的业务开发过程中，开发工程师在项目结束之后需要正式的「移交」给运维工程师来处理后续的事情。然而全栈工程师的概念慢慢流行起来，推崇「You build it, you run it」。高级的工程师可以拿到线上本来只有运维才有的权限，自己写的代码自己考虑部署、监控、告警。

DevOps 也开始深入人心，运维团队中出现了很多自己开发的工具，上线系统、配置管理、监控告警平台等等。

但无论怎么变化，所有软件和硬件都还在自己的机房里，直到云服务的到来。

也就是我们目前所处的环境，软件和硬件都走上了云端，即使那些还在自己经营机房的大公司，本质上也是一个内部的云服务商。云服务的核心是虚拟化，任何人都可以很轻松的在几分钟之内申请到新的虚拟机器（将来可能是容器）。运维工程师进化为了可靠性工程师，以设计软件运行环境和管理软件配置为主。

说完现在，就要说未来了。

很久之前读过《代码的未来》，今天想讨论一下几类工程师的未来的工作方式。

无论是自建机房还是云服务，运维工程师一直无法避免要知道「什么东西部署在什么机器」。然而 Docker 和 K8S 的出现将彻底的改变这个情况，无论多庞大的集群，交给软件自动来编排。软件的标准化、部署、迁移的方式得到了质的变化。

运维工作需要更加深入到业务中，了解项目打包的过程，管理公司内部的镜像，提供标准化的持续集成的工具，提供各个项目的 docker 开发环境。

说到这个感触就更深了，因为我们数据仓库的基础设施刚刚完成从自建 CDH 到云上服务的迁移。

一直以来，我们已经习惯了离线数据和大量计算的需求使用其他工具来完成，比如各种 ETL 工具和 Hive。然而现在的趋势是将存储和查询引擎解耦开来，无论是什么存储，都使用同一套协议（比如 MySQL）来查询。

也就是说无论是分析师还是 ETL 工程师，只要会 SQL 语句就可以了，更重要的是代码层面完全统一。

开发工程师以后只关注生产业务逻辑即可，随着高级语言的发展，不需要懂底层的知识也可以开发出高效稳定的软件。

以 Go 语言为例，代码层面交互的只有 goroutine，背后是协程还是线程还是进程，语言的底层来帮你解决。越来越多的第三方库帮你做掉了大部分的工作，工程师只需要看着文档会调用即可。

Serverless 可能会成为主流，即写完业务逻辑不需要申请服务器，直接在云端运行。

总结

无论是哪个领域，计算机软件的生产都走向了「使用越来越简单，背后越来越复杂」的方向。

我认为公司需要的技术专家和架构师将大幅度减少，与此同时云服务使用专家将成为新的需求。

普通工程师也许真的可以变成简单培训即可上岗的职业，普通工程师的可替代性会进一步提高，核心技术掌握在极少数大型公司，尤其是云服务公司之中。

开源软件将走向「社区孵化，云服务商私有化」的道路，最终开源软件将被头部云服务商垄断，然后变成 SaaS 最终成为云服务商的现金流。

从企业家的角度来看，生产软件的成本可能会降低（尤其是人力成本）。但从工程师的角度来看，其实有点悲观的，要么努力成为顶部的技术专家，要么就会变得随时可以被代替了。