从营销到IT，全图文解析亚马逊规模经济下的降本增效如何做？AWS CTO Werner Vogels 到底说了什么- 大数跨境

首页

从营销到IT，全图文解析亚马逊规模经济下的降本增效如何做？AWS CTO Werner Vogels 到底说了什么

雨神汇

2023-12-04

导读：从营销到IT，FinOps的盛宴，亚马逊规模经济下的降本增效如何做？AWS CTO Werner Vogels 说了什么

关注我们 点击蓝字

一段开场黑客帝国风开始了 2023 Reinvent ，该3分钟续写了2022年的开篇故事

然后开始了AWS CTO Werner Vogels 博士长达2小时的分享。

雨生将为您解读视频，主要分为2大部分，后面一小时讲生成式AI相关的雨生讲另开文章讲解

第一大部分 AWS赋格节俭架构七法则

【雨生点评：开场视频3分钟，此处呼应22年reinvent 的场景，博士cosplay 黑客帝国，剧本续集在2023 Neo在第一部里进入到架构师的房间：

而在2022年的revient 剧情如下

Murphys明确告诉Neo，你有两个选择：吃了红药丸，从沉睡中醒来，回到真实的机器世界；吃了蓝药丸，忘了这一切，继续沉睡在虚假的Matrix里。”

红药丸代表世界是同步

蓝药丸代表世界异步

而博士调皮说可不可以选黄色的，可惜2022年时不能让吃，【2022年此处埋有伏笔】

没办法博士终选了红药丸一个世界是同步的

然后他被世界同步的惊讶掉了，比如一根一个炸薯条，并且最后薯条还撒了，

22年的开场以博士接打黑客帝国的电话开场

开场博士暂停时空吃了薯条，如同黑客帝国的主角neo 一样接个电话穿越到了架构师现场，就如同黑客帝国一样

然后延续202年Reinvent 的剧情，开始了3分钟的热身视频。最终在2022年博士没吃到黄色药丸💊，但在2023年吃到了黄色薯条，做了 Rollback 回滚到了2022年前的那一个。

【雨生点评有没有可能视频在2022年就录好了？】

2023年博士穿越到了另外一个平行时空，

此处的架构师和博士装X，

架构师说：每次我增加服务的时候我都新开一个机柜，他非常昂贵，

所以搞得他非常热，而且拿出一个电风扇来散热。

博士问：你考虑上云迁移吗？

然后这老掉牙的架构师被博士打脸了，博士说这是Perl 脚本吗？

【雨生点评，仔细看了下还真是Perl 脚本，此处让我想起了马斯克下云三部曲

马斯克主导的云退化在推特节省60%的云上开支

马斯克是如何亲自下云搬运服务器的

云退化的马斯克是个狠人】

博士又说：“上云需要重新架构re-artechiture，上云从CICD 开始，要从无服务器开始，要从Lambda 开始”

04:00 -，进而引申到 AWS赋格节俭架构七法则 THE FRUGAL ARCHITECT

05:00 - 成本意识架构

BTW：博士还是SSSC 扫街联社的成员

Street Sweeper Social Club是一个美国说唱摇滚超级团体，于2006 年在加利福尼亚州洛杉矶成立。^[2]乐队主要由Rage Against the Machine乐队的吉他手Tom Morello和The Coup乐队主唱兼主持人Boots Riley组成

08:45 - 以成本为考量进行架构设计

10:00 - PBS 【类似于CCTV 儿童频道】降低了80%的 Streaming Cost

12:30 - 成本是可持续性的近似指标

成本与可持续性息息相关

Cost is a close proxy for sustainability

13:40 - WeTransfer

降低WeTransfer【国外版本的茄子快传？】 78%的cost

14:30 -AWS赋格节俭架构七法则

16:00 - 法则1 - 成本是非功能性需求

可访问性、可用性、可伸缩性、安全性、可移植性、可维护性和合规性

非功能性需求（NFRs）的定量价值通常体现在它们对系统整体性能、稳定性、安全性等方面的具体指标。通过量化这些需求，组织可以更好地评估系统的质量、风险和成本效益。以下是一些NFRs的定量价值示例：

17:00 - 亚马逊S3概览

从固定成本到变动成本的 Pay-as-you-go

【雨生点评：

在财务和会计领域，固定成本（Fixed Costs）和变动成本（Variable Costs）是两种基本的成本概念，它们根据成本与生产量或销售量的关系进行分类。在云计算领域很多企业混淆了IT费用，有的企业会把IT费用归咎为固定成本（Fixed Costs），只有较少数的企业才会把IT费用归类为变动成本（Variable Costs）。

而影响如何区分的分水岭就是 AWS赋格节俭架构七法则的如何设计，如何度量，如何优化。

在财务和会计领域

**固定成本（Fixed Costs）**：

固定成本是指在一定生产活动或经营范围内，不随生产量或销售量的变化而变化的成本。这些成本在短期内是恒定的，无论企业的业务量是多是少。

固定成本的例子包括：- 租金或折旧：无论生产多少产品，企业支付的租金或固定资产的折旧通常是相同的。

- 保险费：企业支付的保险费用通常是固定的，不会因为生产量的变化而变化。

- 管理薪酬：管理层的薪酬通常是固定的，与企业的生产或销售活动无关。

*变动成本（Variable Costs）**：

变动成本是指随着生产量或销售量的增减而相应变化的成本。这些成本与企业的生产活动直接相关，生产或销售越多，变动成本就越高，反之亦然。

变动成本的例子包括：- 原材料费用：生产更多产品需要更多的原材料，因此原材料费用会随生产量的增加而增加。

- 直接劳动成本：如果工人按件支付工资，那么生产更多产品就意味着需要支付更多的劳动成本。

- 销售佣金：销售人员的佣金通常与销售额成比例，销售额越高，支付的佣金也越多。

而在云计算领域则大有不同的

云计算服务通常涉及两类成本：固定成本和变动成本。

1. **固定成本**: - **基础服务费用**：云服务提供商可能会收取一定的基础服务费，无论实际使用量如何，这部分费用保持不变。

2. **变动成本**: - **按需服务费用**：云计算的一个关键特点是其弹性和可扩展性，用户根据实际使用的计算资源（如CPU时间、存储空间、数据传输量）来支付费用。随着资源使用量的增加或减少，相关成本也相应变化。

云计算的成本模型通常被认为是变动成本较多，因为它允许企业根据需求扩展或缩减资源，实现成本的优化。

例如，如果一个企业的数据存储或计算需求增加，它可以实时增加云服务的使用量，而不需要投资于额外的物理硬件。相反，如果需求减少，企业也可以减少云资源的使用，从而减少成本支出。

这种按使用量付费的模型可以帮助企业避免大量的前期固定投资（如购买服务器和其他硬件设备），

并将这些固定成本转变为与业务规模相适应的变动成本。因此，云计算可以提供更大的财务灵活性，使企业能够更有效地管理其IT成本。】

19:00 - 亚马逊DynamoDB 从节俭赋格架构来思考

雨生知道每次因为这个主题都要争论很久，这次也算官方正式回应What Why &How。

就是为什么DynamoDB设计默认的是最终一致性读取优先【Eventually consistent read】DynamoDB，GetItem 操作默认执行最终一致性读取，】

而不是默认用【Strongly consistent read】。雨生也听朋友们吐槽说DynamoDB 不支持强一致性读【其实不是的，DynamoDB支持强一致性，如果要执行强一致性 GetItem、BatchGetItem、Query 或 Scan 请求，将 ConsistentRead 参数设置为 true。

强一致性读取需要两次

Amazon DynamoDB 是一种托管的NoSQL数据库服务，它提供了两种读取选项：最终一致性读（Eventually Consistent Reads）和强一致性读（Strongly Consistent Reads）。默认情况下，DynamoDB 使用最终一致性读，但用户可以选择使用强一致性读。设计成最终一致性读的原因主要包括以下几点：

1. **性能优势**：最终一致性读通常比强一致性读更快。这是因为它允许系统从任何副本中读取数据，而不需要等待所有副本之间的同步。这种读取方式尤其在高吞吐量和低延迟的场景中有优势。

2. **可用性和容错性**：采用最终一致性模型可以提高数据库的可用性和容错性。即使部分系统组件出现故障或网络分区，用户仍然可以读取数据，尽管这些数据可能不是最新的。这符合CAP定理中的AP（可用性和分区容忍性）原则。

3. **分布式系统的复杂性**：在分布式系统中，实现强一致性需要复杂的协调机制来确保所有数据副本在任何时候都是一致的。这不仅会增加系统的复杂性，还可能降低性能。

4. **成本效率**：最终一致性读操作的成本通常低于强一致性读。对于那些不需要立即获得最新数据的应用程序，最终一致性读提供了一种成本效率更高的解决方案。

5. **应用场景的适用性**：许多应用场景并不需要强一致性。例如，社交媒体的时间线更新、博客文章的评论或产品目录的浏览通常可以容忍短暂的数据不一致性。

在这些场景中，最终一致性读是一个合理的选择。虽然最终一致性是DynamoDB的默认读取模型，但Amazon认识到某些应用场景确实需要强一致性。因此，DynamoDB也提供了强一致性读选项，用户可以根据自己的需求选择最合适的一致性模型。在需要确保读取操作返回最新数据的情况下，强一致性读是必要的，例如，在处理金融交易或其他关键任务时。

最后博士总结：法则1 以成本为考量进行架构设计的关键，博士直接给到官方答复最终一致性读取的Cost 是【Strongl consistent read】的1/2 。

在设计每一环节都要仔细考虑成本，这样才能真正做到节约。

20:00 - 法则2 - 持续性系统确保成本与业务目标相符

博士明确提到

然后如果你考虑一下你的商业案例，因为毕竟，我们不仅仅是为了技术而构建技术，我们构建技术来支持我们的业务

雨生点评

【不要技术自嗨模式】【不要技术自嗨模式】【不要技术自嗨模式】

博士问到 How much will this cost IT

确定你能够获利的方向，接着保证架构设计能够顺应资金走向

支与收，各相宜

规模经济下的降本增效

熵增：云上unlimited 之恶

这一部分博士以【飞轮效应】进行了结尾

确保商业行为和技术选择和谐统一

25:00 - Lambda概览 2014年发布了AWS Lambda

Lambda 是成本，安全、顾客需求的三者和谐

【Getting insights into your customer】

28:00 - 讨论技术债务和创新的关系引出了Firecraker 服务

28:40 - Firecracker微型虚拟机概览微虚机

30:00 - 构建可进化🧬架构，博士说去年就提起过可进化🧬架构，因为架构将随时随地在变，我们要设计可🧬进化架构，进而避免架构迭代影响客户，这是Lambda 优势，也是其他架构无可比拟的。

【雨生点评，想想最近滴滴等稳定性事故对客户的影响，详情参考如下三篇文章

云退化【一】当资产负债表衰退引发的技术退化浪潮

关于阿里云故障的吐槽

我们能从阿里云史诗级故障中学到什么】

进而提到还技术债要从商业&技术端思考

31:45 - 法则3 - 架构设计是一系列权衡，进而权衡我们的客户，以匹配信息技术成本和商业定价模型

提到了要多维度度量和思考，进而成就商业市场增长的成功

成本、合规性、可用性、可扩展性、可持续性、可访问性、性能、弹性、安全性

注意下图在视频中是随时变化的，

32:15 - 特邀演讲者 - Cat Swetel，Nubank高级工程总监【巴西】

【雨生点评，这是一个巴西版本的普惠金融的云上故事】

Nubank是一家巴西金融科技公司【雨生点评：注意不要等同于巴西版的蚂蚁金服】，成立于2013年，它是拉丁美洲最大的数字银行和技术公司之一，总部位于巴西圣保罗。拥有9000万客户。属于生长在云上的新一代金融科技公司，

Nubank一开始通过提供无年费信用卡和无与伦比的客户体验而打破了金融行业的常规，但这种颠覆仅仅是开始。不久之后，我们推出了银行账户、保险、投资和贷款服务。

Nubank主要使用了 40多种AWS服务和千余个微服务

她提到在巴西每笔交易5刀起，时间得一天。

Nubank 的Pix 交易做到了10秒内的延迟

并且在应对成本和稳定性冲突时的思考

Cat Swetel，Nubank高级工程总监说她两个都要，并能够达到和谐共处

他们之前面对典型的云熵增问题

Nubank 的第一个微服务叫【ZGC】

并且使用了Nvme+Redis+Dynamodb 的架构，Nubank 每在Nvme 投入1刀，避免了其他工作流投入了3500刀

【雨生点评：该架构及具备了赋格节俭架构的特点，雨生在MarTech SaaS 行业深入实践过百亿数据量级别/日】

增效35%，并且为9000万客户节省了8亿美金的交易费。

【雨生点评：降客户费率，增商业&客户效，形成了完整闭环飞轮效应

TO CHARGE LESS AND INVEST MORE IN OUR CUSTOMERS】

最终让天下没有难做的生意在巴西🇧🇷落地每两个成年人，就有一个是Nubank 的客户

【雨生点评：真香啊，没年费，福利多】

普惠金融在巴西，

继续缩小差距，让银行服务惠及每一个人

持之以恒，银行之利，普及于民

最后博士上台总结【Nubank 的每个业务部门拥有 AWS 成本冠军】

回顾了赋格节俭架构 AWS赋格节俭架构七法则

第一部分

设计阶段

法则一将成本作为非功能性需求

法则二可持续性的系统将成本与业务对齐。

法则三架构设计是一系列权衡。

接下来进入 AWS赋格节俭架构七法则的

第二部分如何度量

41:00 - 法则4 - 未观测的系统导致未知的成本

【雨生点评：此处呼应最近很火的可观测性】

系统不察，费用莫测。企业需要理解成本，每一个工程决策都像是一块仪表。我知道，当你开始让你的指标可见时，它可以改变行为。你必须真正弄清楚并思考各种度量和可观测性。博士提到他儿时经历了70年代的石油危机，他居住的地方是17世纪风格的老房子，很美，但能耗很高。

节能建筑的兴起，有的建筑比其他的节省1/3的能源？为什么呢？

43:30 - 亚马逊系统成本指标

44:00 - 每次请求的成本/微服务级别 CPR 【Cost Per Request】

45:45 - 每次请求的传递成本/系统级别 TCPR 【 Transitive Cost Per Request 】

46:16 - 每次请求的转化率。CRPR【Conversion Rate Per Request 】

【雨生点评：其实上述指标在广告营销ADTech/MarTech行业满普及的营销指标，而在云上想要做好赋格节俭架构，博士在第四法则指出做度量可观测指标，定义metrics for system cost 是必经之路。

以下是一些营销指标关联博士所说的 Amazon Metrics for system cost。以雨生的从业经历，一次营销活动可以有10X-100X的request【http为主】

1. **ROI (Return on Investment)**: 投资回报率是衡量投资盈利性的一个指标。在营销中，它用来计算营销活动带来的收益与其成本之间的比例。计算公式通常是：(营销活动带来的收益 - 营销活动成本) / 营销活动成本。换在 IT指标上可以 =就是营销活动带来的 IT指标的Reqeust 要确保ROI收益合理度量，不能长期低于1。

2. **CPM (Cost Per Mille)**: 在营销届，千次展示成本是衡量广告成本的一个指标，它表示每一千次广告展示所需的费用。这是一个常用于展示广告和品牌知名度活动的指标。换在 IT指标上可以 =每次请求的成本/微服务级别 CPR 【Cost Per Request】或者 每千次请求的成本/微服务级别CPMR【Cost Per Mille Request】

此图中为微服务级别的每次营销产出比成本，场景为电商商品快递物流的IT 成本/每微服务

3. **eCPM (Effective Cost Per Mille)**: 在营销届，有效千次展示成本是实际上每一千次广告展示的平均成本。它考虑了所有收入来源（如点击、展示、转化等）来计算广告的效果。计算公式是：总收入 / 总展示次数 * 1000。换在 IT指标上可以 =每次请求的成本/微服务级别 eCPR 【Effective Cost Per Request】或者 每千次请求的成本/微服务级别ECPMR【Effective Cost Per Mille Request】

写到此处，不知道大家还记得前面的那个DynamoDB 的最终一致性读的成本是强一致性读的1/2 吗？

最终一致性读 1次/单位

强一致性读 2次/单位，如果你用了最终一致性，你的eCPMR 直接翻倍

如果你用了强制性，你的eCPMR直接是别人的1/2

从而实现你的eCPMR 跟着业务随时合理优化，从而实现Cost Down。

4. **CAC (Customer Acquisition Cost)**: 在营销届这是获取新客户的综合成本，包括广告费用、销售团队的工资、软件和工具的成本等。

换在 IT指标上可以 =每次请求的传递成本/系统级别 TCPR 【Transitive Cost Per Request 】

相当于是从TCO 【Total Cost Ownership】到 TCPR的迭代。

类比SRE工程就是从SLA到SLO再到SLI

而完成一个营销活动大概需要7-10步完成下单，而涉及到的IT微服务整体系统级别的请求在70X-100X的级别。

可能大家不觉得营销活动对IT系统的影响，博士贴了一张图，只是打开Amazon首页一次就带来的后端微服务活动完整图。

博士强烈建议大家，在AWS 的console 操作资源的时候，打上一个叫做美刀Tag 在你操作的所有IT上

【雨生点评：说到此处太多的其他f厂商连打Tag 都不好好支持，真拉胯】

5. **CR (Conversion Rate)**: 转化率是衡量访问者完成目标动作（如购买、注册等）的比率，计算公式是：转化次数 / 访问次数 * 100%。换在 IT指标上可以 =每次请求的转化率。CRPR【Conversion Rate Per Request 】

这些指标度量是可以延伸到IT&商业系统上做 insights，想了解更多的请参考FinOps（一）-对企业的IT效能在做指标metrics，BMIFI和BMICO 是什么？】

这样你的每一个产品售卖，每一个PV，的Cost 你都清楚明白，进而优化

进而通过IT的度量从而可观察到你的业务的健康度，从而避免收益递减

更快是否上需要的：这样，你的页面在99%的情况下打开时间是1.7s，如果你能工程上做到1.6s，你知道这样会增加多大的cost，而快了这0.1s 是否会带来对应的商业订单转化？这样做值不值做？就需要思考了。

知晓你的成本，虽然很难：度量Metrics，去想下你的IT和商业的关系。是否过度优化带来了边际效用递减

48:45 - 发布 - AWS管理控制台我的应用程序

亚马逊肯定不只是提出问题的，经过博士长达49分钟的铺垫，终于一个全新的服务上架了，他说可以落地前面所说痛点的服务，你想度量你IT的eCPM吗？

AWS Management Console myApplications

成本也是可持续性的代表

可观测性照亮成本之道，成本变得透明

通过myApplications 你可以可观测前面提起的的需求模块，非功能需求模块NFRs 的成本

50:00 - 发布 - 亚马逊Cloudwatch应用程序信号

支持自动化纳管EKS集群可观测，相当于kubecost+opencost+datadog+Grafana

进而定义客户自己的仪表盘

您喜欢哪种风格的仪表盘呢？

50:40 - 法则5 - 成本意识架构实施成本控制

现场响起一堆鼓掌👏声音，但博士说我不care 你们拍掌与否，但重要的是你们开心。

【雨生点评：一个不支持可调的架构不是好架构‘

博士说，亚马逊官网就是一个例子，他们可以根据SKU选品而下架了，进而IT架构可调

雨生问：我们做到了没有？

你需要有一个开关，用于商业和IT的决策

【雨生点评：想象下你的业务&系统中有多少无效的SKU，摊高了你的企业经营成本，而有些亏损的云厂商SKU 滥用职权，在这方面更为要命】

54:10 - 层级信息指导权衡

解耦和分层，不同层次指导着取舍决策。

在Tier 1，我们要花钱在容错，可能的话多花一些钱，因为他决定商业的最重要环节【搜索框】，如果没有这个，生意是无法进行的

【雨生点评：就如同百度谷歌没了搜索框一样】

在Tier 2，我们可以降低一些容错成本，比如两个Az可用区就够了，没必要多Region 地域容错。

在Tire3，比如最佳售卖棒单，根本没人在意下线5分钟这种应用，也不会影响用户体验。

所以分层业务到架构的设计思想会让你的业务和IT系统更加紧密的结合在一起

所以你需要各类switch

关闭feature 的开关【feature flag ？】

Throttle 【限流器熔断？】

关闭预先调用

降低日志和metrics 的数量

显示较少的细节就够了

要建立自己的分层业务到 IT的架构

接下来进入 AWS赋格节俭架构七法则的第三部分如何优化

55:52 - 法则6 - 成本优化是渐进的

要消除数字浪费

【雨生点评上一个时代是丰田的muda 消除浪费，这次算是迭代了】

56:18 - 节省机会的四大法宝

STOP：比如晚上的时候把开发环境关了，就如同下班关灯一样

Rightsize：选择更合适的主机，小生大也要大降小

Shift ：但更推荐升级到Gravition ARM系列。

Reduce：是否真的需要发送5M图片给客户，能否把图片做到600*100 像素

提到语言的时候，博士提起三个工具和网站，博士说他在上学时候就是他在工具箱里了。

此处博士带货能力刚刚的，推荐Amazon codeguru profiler

可以实现端到端的效能分析 (Profiling) 如火焰图，并跟踪各类cost

博士举例子，根据数据分析42% cost 花费在了网络通信上，这显然不正常。

进而定位到代码的关联环节

【雨生点评APM 如Dynatrace/Datadog/NewRelic 要危险了】

自动分析到原来是处理字长的代码有问题

最终把网络通信的IT成本由42%降低到了27%

Day One 持续优化

博士还吐槽要profling ，而不要认为ios 的app 比android 能耗高，成本贵

1:00:00 - 法则7 - 不受挑战的成功导致假设

【雨生点评，莫经他人苦、莫劝他人善，不要拿着互联网的大棒跨行业对客户指点迷津，

关注的是成功背后的假设和自满可能带来的问题

Unchallenged success leads to assumptions

这句话强调的是，如果一个人或组织在没有遇到显著挑战的情况下取得了成功，他们可能会错误地假设这种成功是理所当然的，或者认为成功的模式可以轻易复制。这可能导致过度自信，忽略了成功的复杂性和不可预测性，从而在未来的决策中产生错误的假设。】

博士提到

"The most dangerous phrase in the English language is. We've always done it this way.- REAR ADMIRAL GRACE HOPPER

这句话出自美国海军少将格蕾丝·霍珀（Rear Admiral Grace Hopper），她是一位计算机科学家和美国海军的先驱者。这句话的意思是，坚持传统做法，不愿意接受变革或创新，是非常危险的。霍珀认为，“我们一直这样做”这个理由往往是阻碍进步和创新的障碍。这种思维方式使得个人和组织满足于现状，不愿意质疑或改变现有的做法，即使存在更有效、更高效或更合理的方法。

少将的这句话表达了对于固守旧习、拒绝变革的批评。从逻辑和效率的角度来看，这句话提倡对现有流程和做法持续的审视和质疑，鼓励寻找可能的改进空间。这种思维方式对于促进技术创新、工作流程优化以及组织和社会的发展至关重要。