Amazon
在云端运算服务尚未问市之前，评估资讯系统的成本效益是资讯人员必备能力，身为全球最大电商亚马逊（Amazon）技术长的Werner Vogels说：「在当时采购资料库这类大型系统，都得先评估足以使用五年的规格，才能达到最佳成本效益。」然而，在云端运算资源垂手可得的今日，虽然传统硬体的限制越来越少了，软体开发人员可以更聚焦在功能创新与更快推出上市，但也因此忽略成本效益的重要性，Vogels指出，重视成本效益几乎已成失传的技艺，为此他在re:Invent 2023的主题演讲提出「节约架构（Frugal Architect）」设计法则，呼吁将成本意识纳入软体架构设计，进而达成永续目标。
节约架构可谓亚马逊过去二十多年软体开发经验的总和，特别是打造具有成本意识与永续发展的系统架构，Vogels回忆道，「在还很难买得到PlayStation的年代，只要有人贴文说亚马逊明天会开卖，许多消费者就会在开卖前五分钟开始狂按电脑的F5按键更新网页，以在第一时间读取到贩售网页，不过这也导致网站流量瞬间爆增。」然而，当时可没有调度自如的云端运算资源可用，因此考验着资讯人员如何有创意地解决刺手问题。
还有一次，在黑色星期五购物节来临前，亚马逊的业务团队兴高采烈地提出许多可冲高业绩的新点子，接着就轮到技术团队苦恼如何在既有系统架构与有限资源下达成业务目标。不过Vogels指出，过往资讯人员就是因为突破种种硬体上的限制而练就一身技艺，然而随着云端运算普及，在限制越来越少的情况下，这些技艺也逐渐失传。
Vogels提出的节约架构由三大类、七项软体架构设计法则所组成，他表示，之所以称之为法则，代表是过往诸多经验的心得，并非硬性规定；而区分成「设计（Design）」「量测（Measure）」与「最佳化（Optimize）」三个部分，则有助於形成框架式的思考架构。
第一项法则是将成本纳入非功能性（Non-functional）需求。传统上非功能性需求包含资安（Security）、法规遵循（Compliance）、无障碍设计（Accessibility）、效能（Performance）、可用性（Availability）、扩充性（Scalability）与可维护性（Maintainability）等项目，Vogels指出，在过去资安、法遵与无障碍设计是无法妥协的三个项目，然而现在光这三项并不足够，还需要纳入成本（Cost）与永续性（Sustainability），成为必要的非功能性需求。
以Amaozn设计S3物件储存服务的经验为例，Vogels指出，由於云端运算服务必须提供明确的价格，因此必须先分析运算成本，以订定合理计价模式。一开始他们认为S3储存服务的成本不外乎传输档案与储存档案，然而，在先期客户试用S3的过程中，他们才发现之前忽略了使用者读取（Request）物件资料其实也会有相对应的成本。
上述经验随後也运用在DynamoDB无伺服器资料库服务，由於此服务提供两种读取一致性（Consistency）选项，包括最终一致读取（Eventually Consistency）与强烈一致读取（Strong Consistency），而由於强烈一致读取的读取次数是最终一致读取的2倍，因此计价也就必须多一倍才合理。
成本考量必需落实在系统设计的每一个环节，Vogels说：「我们开发软体，终究是为了帮公司获利，而不是展现自己的技能。」因此，除了考量软体架构必要的功能性、扩充性与稳定性，还要评估软体成本对公司获利的影响。在设计软体系统架构前，必须先确定营收模式，并确保系统的设计能够支持获利，他说：「系统架构设计一定要跟着公司获利的方向发展，如果不幸走反了，最终你一定会完蛋。」这也就是节约架构的第二项法则：「系统成本必须与公司获利保持一致。」
AWS知名的无伺服器运算服务Lambda，其实背後也有一段鲜为人知的成本与架构重构的故事。在S3、DynamoDB等物件储存与资料库无伺服器化服务陆续推出之後，AWS的客户开始期待运算服务也可以无伺服器化，好摆脱繁重的伺服器管理工作。Vogels表示，因为之前有设计S3物件储存服务的经验，在订价方面他们很快确定无伺服器运算服务需从两个面向计价：每微秒的处理器运算量，以及记忆体使用量，在功能方面也确定必须兼顾安全性、强化隔离与成本效益等三项非功能性需求，但是接下来他们却察觉缺乏足够的技术，以达成上述三项必备的非功能性需求。
眼看推出无伺服器运算服务势在必行，但在缺乏相对应技术，以致於无法兼具成本效益的情况下，Vogels说：「所以我们一开始就先确定了，在成本效益上得有所牺牲……而未来一定得为此付出相对应的技术债与经济债。」於是，他们成立了两个团队，第一个团队先在既有技术下动手开发，第二个团队则负责开发无伺服器运算服务所需要的关键技术。
为了确保无伺服器运算服务的每一个用户程式码都有安全隔离，第一个团队选择将每一个Lambda服务以EC2最小规格的T2执行个体来运行，然而，由於Lambda函数程式码通常都很小，即便已经采用最小执行个体T2，但大多数的运算利用率都不到一半，也就是说AWS得多付出多一倍的运算成本来提供Lambda服务，而这也就是Vogels所说的，在决定开发的第一天就已经知道未来必须承担的经济债。
AWS在2014年推出Lambda後，事隔四年，第二个团队以Linux KVM为基础开发出微型虚拟机器Firecracker，让单一主机可以承载更多的Lambda服务，终於解决运算利用率的问题。Vogels指出，其实当初如果没有开发Firecracker，接下来的无伺服器容器运算服务Fargate也难以实现。
回首从Amazon S3至AWS Lambda的开发历程，Vogels打趣地说，这个过程就像一边开飞机还要一边换引擎，而且还不能让乘客察觉异状。这段经历也让他观察到节约架构的第三项法则：「架构设计是一连串的权衡与取舍」。他建议开发人员要打造可持续进化又不影响业务营运的架构，因为改变一定会发生。
继续阅读 → Part 2 节约架构量测篇
节约架构 Frugal Architect
设计
I. 成本是必要的非功能性需求
II. 系统成本必须与公司获利保持一致
III. 架构设计是一连串的权衡与取舍
量测
IV. 无法量测的系统必有隐藏的成本
V. 有成本意识的架构必有成本控制措施
最佳化
VI. 成本最佳化是渐进的
VII. 无庸置疑的成功必将导致错误的臆断