大涛学长Serverless 服务选型

北京联盟_本文原题：Serverless 服务选型
综述
近两年来， Serverless 概念在开发者中交流的越来越多，实践、服务、产品层出不穷。
Serverless 的主题分享呈现爆发趋势，如在云原生领域颇具影响力的 KubeCon&CloudNativeCon 会议中，关于 Serverless 的主题， 2018 年有 20 个，到 2019 年增长至 35 个。
产品层面，从最早的 AWS Lambda ，到 Azure Functions、Goolge Functions、Google CloudRun ，再到国内阿里云 Serverless Kubernetes、Serverless 应用引擎、函数计算等，面向计算的 Serverless 云上基础设施越来越丰富。
新概念、新产品的产生不是凭空出现，它们诞生之初要解决的是当前问题。随着实践者对问题域的理解越来越清晰和深刻，会逐步迭代问题的处理方法，提供更接近问题本质的解决方案。
【大涛学长Serverless 服务选型】若不从问题域出发来理解解决方案，容易陷入两个极端，即「它能解决一切问题」「它太超前了，理解不了」。
本篇文章尝试以日常开发流程为起点，分析每个阶段面对的问题，然后组合解决方案，提炼面向 Serverless 的开发模型，并与业界提出的 Serverless 产品形态做对应，为开发者采用 Serverless 架构和服务提供参考。
迭代模型
从项目整体视角来看：

本文插图

这个模型的目标是满足客户需求。通过被动迭代满足客户提出的需求，同时逐步深刻理解客户需求的本质，通过主动迭代和客户一起采用更好的方案或从根源解决面对的问题。
每次的需求反馈会加深对客户需求的理解，提供更满足需求的服务。每次的 bug 反馈会加深对处理方案的理解，提供更稳定的服务。
在模型启动后，日常的核心问题就集中在了如何加速迭代。
为了解决迭代加速的问题，需要了解有哪些制约因素，有的放矢。下述是从开发视角看到的开发模型：

本文插图

虽然会有不同的开发语言和架构，但在每个阶段均有通用的问题，如：

本文插图

除了要解决上述通用问题，还需要提供标准化的方案，降低开发者的学习和使用成本，缩短从想法到上线的时间。
若将上述过程中不同阶段花费的时间做个分析，在项目整个生命周期中会发现：

部署&运维占用的时间和精力，会远大于开发&测试
通用逻辑占用的时间和精力，会接近甚至超过业务逻辑

为了加速迭代，需要依次解决占用时间和精力多的部分，如图 1：

本文插图

从左至右，通过下放不同层次的运维工作，降低「部署&运维」成本。在降低了运维工作成本后，在「通用逻辑」层面降低成本。二者结合起来，在迭代过程中更深入聚焦业务。
该过程也是从 Cloud Hosting 到 Cloud Native 的过程，充分享受云原生带来的技术红利。
由于软件设计架构和部署架构与当时环境耦合度高，面对新的理念和服务、产品，存量应用迭代过程中采用的技术需要有相应调整，即开发和部署方式需要有一定的改造。新应用的开发和部署应用新的理念时，有一定的学习和实践成本。
故上述过程不能一蹴而就，需要根据业务当前的痛点优先级来选择匹配的服务和产品，并根据未来的规划提前进行技术预研，在不同的阶段选择适合的服务和产品。