简介：试想，如果未来的应用开发，开发者通过函数计算、弹性容器服务等能力去承载自己的业务逻辑，存储、数据库、消息等中间件能力通过 Backend as a Service 的方式去获取，即未来使用云计算的开发者能够无需关心云计算的基础底层概念，直接聚焦自己的业务开发，以近乎无感的方式获得云计算的帮助。基于这样的趋势的预判，本文作者开始在云原生的路径上探索，并致力于为云时代的原住民开发者提供一个理想的一站式的开发工作环境：云原生 Serverless 开发者工作平台。
缘起，为了心中的“云+端”
2015 年，一个偶然的机会，我从淘宝来到了阿里云。
那个时候正是阿里云全面商业化的前夕，我当时正在淘宝前端技术部，与 @圆心 @元彦一起，跟手淘客户端的同学共同完成了前端代码 “Write once, Run anywhere” 的 POC（概念验证），前端 All in 无线的序幕即将拉开。
一天，@叔度找到我，跟我分享了他眼中的云计算未来与现在的痛苦（其实就是想拉我过去帮他做控制台 [手动狗头]）。我和叔度是在做性能对赌项目中结下的友谊，而且对于推崇颜值即正义的我来说，叔度也是近乎男神的存在，我愿意继续往下听。后来我们一起再跟 @老石头聊完后，我心里有了一个大概的概念，云计算正在开始改变中国，而基础设施、阿里云的用户入口、控制台，还停留在内部孵化的状态，无论是从效率还是用户体验上来看，对阿里云接下来的商业化都是个巨大的阻碍。
最终我决定加入阿里云的思考是这样的，云计算如果是未来社会和商业的基础设施，那未来的应用开发应该都会是基于 “云 + 端” 的模式，服务在云上，应用和交互在用户侧，这对前端行业来说，是一种开发模式的演进，对一个前端同学来说，是充满了想象与挑战的，我们需要开始去探索这个领域。现在眼前的机会不正是前端和云结合的契机吗？我跟 @圆心沟通后，很快得到了支持，并且给了我很多建议，我想，这大概就是英雄所见略同吧。
让云计算开箱即用
为了引导团队的方向，也为了不被现实的困难压力以及执行过程的琐碎导致迷失，我带领我团队的同学共同确定了我们团队的使命，让云计算开箱即用！
初心很简单，让用户能高效地在云计算的入口完成他们的任务。
随着规划的推进，我们逐渐收敛了阿里云的控制台技术体系，不仅成功支撑了阿里云一方、二方产品在 7 大市场渠道的极速扩张，也逐渐统一了用户体验，这就是今天阿里云的 OneConsole 控制台中台体系。OneConsole 的诞生初期，我们曾做了一个决策，所有控制台的功能透出，只接受开放的 API，也就是说，我们官方做的控制台，理论上，我们的客户也是完全能基于同样的 Open API 去实现的。也正是这个决策，我对 “让云计算开箱即用” 有了新的理解。
当我们自己用阿里云的 Open API 做控制台开发的时候，我们遇到的第一个问题就是，我们没法快速弄清楚某个云产品有哪些 API，每个 API 是什么功能，输入输出是怎样的；第二个问题是，我们没法调试这些 API，因为我们使用的 Open API，都是真实线上服务的云产品，每个参与开发的同学都需要有帐号，都需要购买。为了解决这些问题，我们孵化了 API Explorer，孵化了 API Mocks。
当我们的产品从十几款扩张到两百多款，曾经的几个大产品也变成了几条大产品线，大家又面临一个问题，面向端的开发要聚合越来越多的云产品原子 API 才能拼接出一个 UI 所需的数据，同学们迷失在了 Open API 的海洋，虽然后来我们又孵化了一个新的工具，逻辑编排去解决这个问题，但这也让我再次思考。
什么是云计算的开箱即用？
要回答这个问题，先要对 "谁用" 保持一致的理解。之前刚做控制台业务的时候，我会认为，这个 “谁”，是使用控制台的用户，但是自从我们开发控制台要用云产品的 Open API 之后，我发现，开发态的我们，才是这个 “谁”。可以将阿里云控制台理解为我们基于阿里云的能力创造出来的一个 SaaS，在控制台操作使用的用户其实是这个 SaaS 的客户，只不过，这个 SaaS 背后管理的也是阿里云的资源而已。
我目前所理解的，云计算的开箱即用，面对的应该是广大的开发者。他们希望利用云计算去更好地创造自己的技术价值、公司的商业价值、社会的普惠价值，而云计算正是可以帮助他们做的更好的载体。
说到云计算应用的现状，在撰写此文的时刻，我一直有一个类比，就是计算机的 DIY 时代。
人类和其他物种的重要区别就是能够制造并利用工具。计算机作为一种高科技的技术产品，极大地改变了人类的工作和生活方式，今天，它以不同的形态渗透在人类世界的方方面面，医生看诊、教师备课、商人经营、工厂生产，每个行业都在利用计算机帮助自己更好地工作。
普遍情况下，人们要做的就是买一台预装了操作系统的电脑，动手安装上自己需要的软件，就可以开始工作了。而在二十年前，这个过程是这样的：人们去到电脑城，从学习采购配件开始，然后再组装、安装操作系统、安装应用软件、开始工作。
- 电脑有主机和外设
- 主机有：主板、电源、CPU、风扇、硬盘、光驱、内存、显卡、声卡、网卡、数据线、电源线、机箱这么多配件构成
- 外设有：鼠标、键盘、显示器、音箱、打印机等等
- 把这些配件逐个安装连接起来
- 通电，期望不要听到主板报警音
- 进入到 CMOS Setup 做一些硬件的配置，比如系统启动引导顺序之类的
- 开始安装操作系统，又是一个专业领域，学会了以后，又多一个征服小姐姐、小哥哥又或是长辈邻居的硬核技术 [手动狗头]
- 开始安装自己真正想要应用的软件
- 开始工作？再装几个游戏先玩一下吧 [手动狗头]
我也经历过 DIY 电脑的年代，那个时候是一种什么感觉？自己开始只是想买台电脑学编程，结果选配电脑的时候就想进入了一个新的知识的海洋，不断接触和学习着新的知识，CPU 要怎么选，超频要怎么做，对应的散热要怎么做，等我最终确定了采购清单，一个月已经过去了。因为学的太认真，有一段时间我甚至在电脑城帮人打起了暑期工，帮忙组装电脑，我想知道有跟我类似经历的同学吗？[手动狗头]
回过头来看今天的云计算，和二十年前 DIY 电脑的年代何其相似。人们期望借助高科技云计算帮助自己更好地工作和生活，于是，大家不得不开始在云计算的知识海洋努力地学习：
- 阿里云原来有这么多云产品啊，数一数，两三百款
- 服务器、存储、数据库，每个类型下面又有十几款产品，得好好想想选哪一个
- 同一个产品还有不同的规格，不同的规格我能看到价格不一样
- 所以，我到底该怎么选呢？还是随便买一台服务器，然后把我的应用、数据库、文件都塞里边吧
这就是刚接触云计算的开发者的普遍真实写照。
作为云厂商，我们的愿景是成为社会和商业的基础设施、水电煤、成为普惠科技，但我们离真正普惠还有一段距离，至少要做到跟今天的计算机之于社会，人们不再需要去学习了解电脑的构成，只有跨过了 DIY 这个阶段，让真正想通过云计算去创造价值的开发群体能够无需关心云计算的基础底层概念，可以聚焦自己的业务开发，在业务中需要云计算帮助的时候，我们能以近乎无感的方式提供服务，这就是我心中认为的云计算的开箱即用。
这看起来很难，直到函数计算的升温，CNCF 为代表的云原生概念的普及，让我看到了希望，我开始了持续的搬砖。
在云原生的路径上探索
星星之火，可以燎原。随着诸如 LeanCloud 商业化、阿里云函数计算的发布，让我内心的热火彻底被点燃，类似 LeanCloud 背后的 BaaS（Backend as a Service，虽然后端即服务的概念早就有了，但现在 BaaS 已经被更多人认为是 Blockchain as a Service，真是世风日下 [手动狗头]）概念，让我看到了云计算开箱即用的可能；函数计算的支持不同开发语言的自定义运行时，支持函数的实时弹性，让我看到了云计算开箱即用的可能。
试想，如果未来的应用开发，开发者通过函数计算去承载自己的业务逻辑，计算、存储、数据库等能力通过 Backend as a Service 的方式去获取，是不是就意味着开发者已经大致具备我们所设想的云计算的开箱即用模型呢：让真正想通过云计算去创造价值的开发群体能够无需关心云计算的基础底层概念，可以聚焦自己的业务开发，在业务中需要云计算帮助的时候，我们能以近乎无感的方式提供服务！
基于对这种趋势的预判，我开始在云原生的路径上探索。
1 自身业务领域的探索
2018 年作为阿里云控制台发展开放元年，越来越多的控制台后端统一到 OneConsole 的同时，我们也发现很多业务定制化要求高，部分功能没办法使用 Open API 开放出去，比如 HOME、阿里云 APP 等，而这些非标、强定制化的应用，开发者一般都对云上商业化流程不熟，对云上运维不熟，只能负责好自己的应用逻辑，这正是一个很合适的 Serverless 平台场景。我们对 OneConsole 进行了 Serverless 微应用升级，让 OneConsole 可定制，让上云更容易。在前端，我们也进一步扩大逻辑编排在的控制台前端开发的价值，形成了一套[控制台 SFF（Serverless for frontend）的研发模式，进一步解放前端生产力，让前端从某些繁重的、低水平的重复劳动中释放出来，能够有更多的机会和时间深入到业务中和前端领域的深水区，做出世界一流的产品和技术。
2 集团前端委员会的探索
2018 年初，@圆心带领集团前端委员会及部分 P8 同学共创，我们共同去看到和布局未来的前端发展方向，我分享了对 “云 + 端” Serverless 方向的理解和看法，随后也得到了大家普遍的共鸣，大家一致认为，这是前端应该去提前布局的方向，从此，由我来牵头，正式开启了集团前端委员会 “云 + 端” Serverless 的技术方向建设之路。
3 巧妇难为无米之炊
项目启动后我们发现集团内根本无 Serverless 资源可用，于是我们花了大半年的时间在集团内布道，推动阿里云 ECI、Function Compute 部署到集团混合云环境，推动 CSE fn 的诞生以及 Aone 底座的改造，直到 2019 年上半年，我们才正式 KO 了阿里经济体前端委员会 Serverless 研发体系共建项目，并在 2019 年的双十一，伴随经济体核心业务 100% 上云，经济体前端实践 Serverless 研发模式升级也经历了它的第一次大考，全部试点业务都稳稳地经受住了考验，验证了项目组的共建成果，而接下来就是展示资源利用率以及研发效率提升的关键阶段！
4 开放社区的布道
2018 年至今，我一共参加了大概 10 场开放社区的分享，相对经济体内的 Serverless 资源匮乏，开放的社区生态完全可以拥抱阿里云等公共云资源。
5 开放社区我们看什么
看开发者关注什么，看雇主关注什么。在普遍的 web 应用开发中，一个最精简的研发团队都需要前端工程师、移动端工程师、后端工程师、运维工程师，按照 2018 年 Stack overflow 做的全球开发者调查报告开发者年薪数据来看，一个最小研发团队，上述 4 个岗位 * 2（最小 Backup）= 8 人，仅薪资部分的投入就需要美元，而这种现状完全有机会通过云端研发模式去重新定义：一个最小研发团队的构成可能只需要个云端应用开发工程师，假设这个工程师的年薪给到之前个工种当中最高的档位，即 74,000 美元，两个也就是 148,000 美元，两个研发团队单位时间内的交付是等价的。对研发岗位而言，薪酬普遍得到了提高，对雇主而言，研发综合成本大幅降低，这就足以引起整个研发生态的升级，而这一切能发生的逻辑都在于：端开发 + 云 Serverless，使得一个擅长端开发的岗位完成所有应用逻辑的开发，该岗位并不特别擅长的应用架构、运维管理，则全部由云原生 Serverless 去弥补。
6 让故事变成事实
对云厂商而言，需要更多这样的多赢的故事，对前端岗位而言，需要这样的多赢的故事，并且，我们需要让故事变成事实！
自证预言，让梦想照进现实
回归初心，当所有的探索都得到了正向的回馈，意味着我们的方向是对的，方向对了，就不怕路远！2019 年，我开始更专注地去推动心中理想的云原生 Serverless 开发者工作平台。
Q：为什么是一个开发者工作平台？
让我们回到云计算普惠的初心，要实现最终的普惠，其路径一定会落在开发者应用，而开发者的时间都在做应用写代码，这是开发者的日常工作，我们需要出现在开发者日常工作的路径上；
Q：这是一个怎样的平台？它和传统研发平台有什么区别吗？
说到研发平台，相信大家都会立即有一些共性的思考，它应该包含组织结构、应用项目、代码托管、构建部署等功能模块，没错，这就是绝大多数传统研发平台的基本模块。
如果你有实际体验过（相信所有的开发同学都清楚），会发现，所有的传统研发平台，实际上只能辅助部署发布的过程，开发调试的过程完全由开发者自行线下解决。
在正式回答云原生 Serverless 开发者工作平台是什么之前，我们不妨再来看一下开发生态的一些现状。为了更了解开发者生态现状，我和 @神秀曾经一起去拜访过行业专家熊节，一起交流了云时代开发者的痛点和机会，我将其中与云厂商相关的内容进行了抽象，得到以下结论。
- 无论是小型研发团队还是大型研发团队，都渴求获得低成本高质量的架构服务
- 关注客户研发团队成长线，如果不能陪伴客户成长的过程，想在客户长大后再切入，未来我们不会有机会，可能只是多云的备份
- 关注开发者流动线，每个开发者背后熟悉的技术栈是相对固定的，如果我们不能守住开发者不变的技术栈，未来我们不会有机会，可能只是多云的备份
云原生 Serverless 开发者工作平台要做的是真正把开发调试和部署发布两个环节完整地串联起来，为云时代的原住民开发者提供一个一站式的开发工作环境。
Q：怎么去实现呢？
我们从技术栈及应用架构开始思考，这背后其实都与一个个应用开发场景是密切相关的。比如，开发者小明是一个云时代的原住民，他的工作主要从事做 web 应用开发，小明的技术栈可能是：NodeJS + ReactJS + Webpack + NPM + Git，他熟悉的应用架构可能是：数据库服务 + 消息服务 + 缓存服务 + 存储服务 + 函数计算服务 + CDN 服务。
可以看到，在云时代，应用架构基本上能通过云产品服务的组合去表达，这无疑正是我们要深入进去建立强连接影响开发者的。技术栈又该如何去做呢？它们由编程语言、编程框架、版本控制、构建编译等工具构成，我们怎么去强化云产品跟它们的连接呢？
这就是为什么我们要把开发调试和部署发布两个环节完整串联起来的原因。技术栈主要体现在开发调试环节，如果我们能为开发者提供一个在线的开发环境，把一些主流开发场景背后的技术栈、依赖环境、依赖服务全部都集成在一起，让开发者在工作的时候能够直接进入到业务逻辑开发的过程；同时整合能触达到开发者业务终端客户的分发渠道，让开发者完成代码开发调试之后，能够快速将代码变成在线服务。
我们通过这种平台的整合，为开发者提供低成本、高质量的架构服务，帮助开发者解决两个核心痛点：
- 从加入业务到写下业务第一行代码的时效
- 从完成编码到服务客户的时效
同时，完成了阿里云产品服务与开发者技术栈以及开发者业务应用架构之间的强连接，从而实现，客户的成长过程、开发者的流动过程，我们的云产品服务始终能获得最好的机会。
Q：开发调试和部署发布两个环节具体如何串联起来呢？
从 2019 年全球开发者人群调查报告中，我们关注到了这几个数据：
- 截止到 2018 Q4，全球活跃开发者数量达到 18,900,000
- 预计到 2030 S2，全球开发者数量将增长到 45,000,000
- 按照应用开发领域开发者规模分布数据来看，排名 Top 6 的是：Web Apps，Backend Service，Mobile Apps，Desktop Apps，ML/AI/Data Science，IoT。
从这组数据中我们既看到了开发者规模增长的趋势，也找到了串联开发者业务架构与技术栈的线索，我们知道了该布局哪些应用开发场景。
Web Apps，Backend Service，Mobile Apps，Desktop Apps，ML/AI/Data Science，IoT，这 6 个应用开发场景中，除了 Desktop Apps 外，其他几个应用开发场景，在整个阿里经济体范围内去看，每一个我们都有，背后的研发体系都很成熟，甚至是行业标杆！这是一个很好的机会，如果我们能将经济体内堪称行业标杆的应用开发场景研发体系与阿里云服务进行深度集成，重点去建设云原生 Serverless 开发的心智，一定会创造出一个云时代的原生开发环境，一个云时代开发者每天工作的平台！
在这个不断迭代的思考过程中，我跟许多同事、同行进行了交流，得到过很多启发与帮助，大家都有一个共同的想法，这是未来，但这很难！
是的，这真的不是一件容易的事情，但是我相信，只要你也相信云是未来，相信云计算终将实现真正的普惠，你一定会有跟我一样的想法，想去实现它！可以通过微信（fengchi_dh）随时与我交流，期待听到你的想法！