传统应用架构与Serverless架构总体拥有成本(TCO)分析与比较

Posted 2021-04-02 云计算部落

这篇报告是2019年9月德勤基于AWS Serverless发布的一篇白皮书，原文叫《Determining the Total
Cost of Ownership of Serverless Technologies when compared to Traditional Cloud》。本文就基于这篇文章提供的方法论，来分析一下Serverless模式的开发总成本。顺便比较一下国内各个云在Serverless架构下的成本。我们重点比较国内排名前三的云平台：阿里云、腾讯云和华为云。

在原文中包含两个案例，我们重点结合第一个案例云主机与Serverless的比较进行详细分析。

如何对Serverless模式成本进行估算

Serverless模式是一种真正的将云平台的计算、存储和网络按需付费的云计算理想模式。之前的文章中我也提到过，Serverless最大的优势就是降低了基础架构层的可见性，即“零运维”。开发人员可以更关注业务逻辑的开发，而将繁重的运维工作交由云商负责。Serverless为应用带来了良好的可扩展性、敏捷性和弹性，缩短应用上线时间，提高发布频率，加速公司收入增长。

但是由于使用情况的不确定性，往往很难精准的估算Serverless的成本。在本文中对于Serverless TCO评估框架包含三个关键成本：基础设施、开发和维护。

案例简述

这是一家交通运输公司的需求，用户平均在途中的时间要花费两个多小时。交通公司提供了一个应用（可能是手机APP）包含以下功能：在线订票、连接WIFI、还可以实时监控自己行程。每年有数百万乘客、数百个目的地以及数千条线路，这些相乘之后需要一个并发量巨大的系统进行支撑。运输公司应对这种情况需要花费非常昂贵的成本，而且很难预测。这样也影响了与决策相关的数据得不到及时更新，造成机会成本的丧失。所以为了解决这个问题，这家公司在评估将订票系统运行在函数计算服务上还是EC2实例上。根据测算，这套系统需要满足每天150万笔交易。

基础设施成本

资源部分应该是最透明也是最容易比较的部分，只要根据应用运行的情况评估价格即可。

传统方式

这是原文中给出的系统资源消耗情况，因为没有更细节化的信息，所以只能根据价格进行反推。

云资源	规格	数量
云主机	m5.large(2vCPU/8G/200G)	3台
数据库	r5.large(2vCPU/16G/500G)	3台
云硬盘	500 IOPS SSD	1G

原文案例中并没有改变给出具体的应用架构和构建细节，所以我们无法从技术层面深究架构合理性，所以只能更关注成本因素。

Serverless模式

Serverless是按照资源使用时间计费的，所以这里要根据使用时间计算价格。

功能模块	规格	执行时间	执行次数
售票响应函数	512 MB内存	3000 ms	32,400,000
数据处理	512 MB内存	3000 ms	10,800,000

对比

这是原文给出的资源消耗情况比对，但是有一些非常明显的错误，总计部分很明显的对不上。从原文中的描述可以得知这些信息：Webservers三台节点对应了下面处理票务的函数；而数据库加上存储对应了数据处理函数。这里我非常疑惑的一点：就算你把逻辑写在了函数计算里，你最终处理完的数据还是需要用持久化存储呀？所以我认为这个案例在描述上存在很大的纰漏，对于Serverless至少还应该包含一个数据库服务用于存储最终处理的数据。不过这里我们不纠结与这个问题，只从案例的成本分析进行对比。

出乎意料的是，在这个请求量级上，使用函数计算服务在这个场景下反而要高于应用系统建立在云主机上。函数计算两个非常重要的计量指标：运行时间和请求次数，这两个指标决定了你的账单。

相同的情况也发生在Kubernetes服务中，我们之前在构建SaaS时，重点评估了阿里云Kubernetes托管版本(用两台云主机作为Worker, Master托管)和Serverless版本(Master和Worker节点均不见，底层直接使用阿里云ECI容器服务)，原本以为Serverless版本要比托管版本便宜，但是由于我们的程序多以Daemon方式运行，轮询任务很多，导致资源使用时间较长，最终的结果是Serverless版本的价格远远高于托管版本的价格。所以在应用Serverless架构时，要从这种架构的特点进行设计，降低上线后的成本。

开发成本

开发成本是评估Serverless架构总体成本第二个重要因素，如果使用传统方式开发，当客户量激增后，基础架构瓶颈的问题。当出现问题再去调整架构进行开发，会无形中错失很多机会成本，引起客户不满。如果在前期过度进行开发设计或者投入大量基础架构设施，又会导致前期成本的浪费。所以对于这种场景，Serverless灵活的扩展性就更加适合业务发展的需要，更好的满足客户的需求，同时又避免了资源的浪费。

虽然云主机在一定程度上降低了传统运维成本，但是相较于Serverless架构，仍然需要去维护网络、安全、负载均衡、自动伸缩策略等。而使用Serverless架构时，由于采用的事件驱动，所以研发人员无须在前期设计阶段将过多精力研究系统健壮性，可以马上进入研发阶段。

另外一部分成本来自于持久化集成，在传统方式下，DevOps流程往往需要经历多个阶段，从编译到制品库，从打包到上线中间过程相对较长。由于函数计算的特点，可以更快速的发布上线。测试人员也可以根据函数计算针对性的设计测试方法，合理的控制产品出现Bug的“爆炸半径”。

运维成本

运维上主要关注以下几个方面：扩展性、安全、补丁、监控验证测试等内容。每一个应用受到应用的范围和组织的影响，在运维成本上不同。但是，根据平均情况，使用传统云主机，运维人员每个月需要花费8-10小时在于加强安全性，额外每月需要40个小时用于监控、日志分析、验证和测试工作。而使用Serverless架构，运维的工作量进一步下降，真正可以做到开发运维一体化的效果，让Developer做Operation成为可能。

结论

在达到一定请求数量级时，Serverless架构在基础架构上要高于传统自建方式，但是在开发和维护成本上，Serverless要大幅度优于传统架构。在本案例中，整体成本预估节约40%的TCO。要从架构设计上对函数计算的特点有充分的认知，根据函数计算特点进行设计，才能最大化利用函数计算实现降本增效的结果。