Serverless 是炙手可热的技术，被认为是云计算发展的未来方向。尤其是在前端研发领域，使用 Node 开发云函数，可以让前端工程师更加专注于业务逻辑，实现全栈工程师的角色转变。
Serverless 的优势技术 Leader 和架构师在进行技术选型时会关注很多指标， Serverless 贡献最大的就是 研发交付速度（Time to Market） 和 成本（Cost）。
研发交付速度方面，衡量的指标是 Time to Market，是从需求产出到上线所用的总时长，Serverless 在这方面的优势在技术和团队协作两个视角上均有体现。
一是技术视角。 有一种观点称 Serverless 是一种很简单的技术，我对这种观点并不完全同意。Serverless 架构让用户和底层架构的关系发生了变化，之前开发者需要关注核心业务逻辑、运维和底层架构的治理，在 Serverless 架构中底层的部分由 Serverless 架构提供方来解决。从整个应用系统的角度来看，系统架构的难度和复杂度并没有实质简化。
这里我们不展开讲 Serverless 架构的底层实现细节。只需要了解一点：Serverless 底层架构做的事情越多，业务层面需要关注的架构和运维工作就越少，因为做的工作少了，所以交付的时间就更快了。
二是团队协作视角。在 Serverless 的模式下，全栈开发的工作模式会执行得更加顺畅。我们知道，前后端分离确实是一种很好的架构模式：细化了分工，降低了耦合，提升了复用。但随之而来的问题，是团队间的沟通成本、KPI 目标的差异所带来的各种催排期、接口确认以及联调测试。不少技术团队用全栈开发的模式来解决这些问题， Serverless 下不需要在架构和技术栈花费过多精力，Runtime 和语言也没有强制依赖，而是完全面向业务，每个前端工程师都可以是全栈的。
另一个优势就是 Serverless 会大大降低成本，体现在计算资源和人力两个层面。
在计算资源的成本方面，主要体现在弹性扩缩容量，按需付费。在传统的计算资源预算时，往往为了能抗住峰值流量，系统容量都有 Buffer，说白了就是日常的浪费。
在 Serverless 模式下，当业务代码上线后，一分钱都不需要支付。只有当真实请求和流量过来了，平台才会根据请求量，瞬时拉起对应数量的函数实例，去接收请求和执行业务代码，此时才需要为真正的代码执行所消耗的资源付费。No Pay for Idle ，从会计学的角度，Serverless 让计算资源从固定成本变成了可变成本。这种付费模式对于那种流量波动很大的业务优势明显。
还要说明的是人力成本。很多技术 Leader 总抱怨人手不够，也许真实情况并非如此，只是没有足够比例的人投入到业务功能的开发和迭代上，而是去做了架构、底层等必要的支撑性工作。我承认这些工作确实非常有挑战、非常必要，也非常重要。在 Serverless 模式下，由于不再需要关注底层架构，所以缩小这部分的工作量和人力占比，就有了更多的工程师可以放在核心业务上，多做迭代，从而加速产品功能的研发。这不是更高的 ROI 吗？
Serverless 的适用场景Serverless 适用于事件触发的场景。当某个事件发生时，拉起并调用 Serverless 云函数，比如文件上传、消息队列中的消息事件、定时器事件，也可以是 IoT 设备的某个事件。还可以用于一些文件处理，比如图像处理、音视频处理和日志分析等场景。
当然，这些事件也包括 HTTP 请求事件，这是 Serverless 的一个很大的适用场景—— HTTP Service，主要实现基于 HTTP 应用的后端服务，比如 REST API、BFF 和 SSR 服务，以及业务逻辑的实现。
我主要关注 Serverless 在 HTTP 场景下的应用。这也是和前端工程师结合最紧密的部分。小到为小游戏、运营活动提供后端的支持，大到整个 App 或站点的 REST API、BFF，或是 H5 页面的 SSR，都是 Serverless 适用的场景。
Serverless 对前端开发者的意义