查看原文
其他

亚马逊 CTO 20 年架构经验之道:俭约架构师的七大黄金法则!

冬梅、Tina InfoQ 2023-12-08

作者 | 冬梅、Tina

声明:本文由 InfoQ 整理发布 ,未经许可禁止转载。

亚马逊 CTO Werner Vogels 向企业传达了一条信息:在管理云成本方面,是时候成为俭约的架构师了。

在过去 17 年里,Werner Vogels 带领着亚马逊从一家在线图书销售商转变为全球最大的电子商务帝国之一,可以说是有史以来最著名的首席技术官。Werner 也是一位超可扩展系统的顶级专家,拥有计算机科学博士学位,是许多会议和期刊文章的作者,其中大多数是与计算机相关的分布式系统。

在今天的 re:Invent 2023 大会主题演讲中,Werner 给大家上了一节关于成本优化的课:“我今天要讲的,汇总了我过去 20 年作为架构师的工作经验。”

“作为技术专家,我们生活在一个瞬息万变的世界,我们需要保持学习,坐下来,拿出你的记事本,现在开始做笔记。”

捡起我们曾失去的“架构艺术”

Werner 选择在主题演讲中讨论成本问题,这既反映了当前的经济环境,也反映了云计算支出不断增长的态势。本月早些时候,Gartner 公司发布预测,到 2024 年云支出将达到 6780 亿美元,比今年的 5630 亿美元大幅增长。亚马逊云科技在引领公有云市场方面取得了巨大成功,但同时也意识到,这个行业所带来的成本压力正在随着生成式 AI 等技术的广泛采用而不断增加。

“以前我们处于受限的环境中,在存在约束的条件下构建这些系统时蕴含了很多艺术。我们要做商业创新时,虽然有了绝妙的想法,但也要根据各种限制条件对蓝图进行修剪,”Werner 表示,“后来我们有了云计算,突然间所有的这些限制几乎都消失了,等于把手铐、脚镣都拿掉了。摆脱了束缚后,突然间一切都变了,我们最重要的事情变成了迅速行动、推出产品。”

随着执行速度变得更为重要,你就可以能做以前不可能做到的事情。过去这 15 年,我们见证了各种令人惊叹的创新。但这种发展速度下,我们也失去了一种架构的艺术:关注成本、以成本为重要考量的架构设计的艺术。

“作为工程师,我们在考虑成本方面的培训非常不足。我不是指大 O 阶次的成本,而是实际的金钱成本。如果给我五个容错算法,我几乎可以闭着眼睛选择最好的一个。但如果你问我在系统开始扩展时最佳和次佳方案之间的成本差异会是多少,我可能会感到犹豫。”Werner 其实早在 2012 年写的一篇博客文章中就提醒我们必须关注成本问题。

当不考虑成本这个约束条件时,大家可以做很棒的创新,但宏观经济是会改变的,成本效益才再次显露出来。Werner 表示他曾通过一种艰难的方式学会了如何将成本纳入架构中,而在今天的演讲中,“我把我的这些经验掏出来送给各位,希望大家能拿出笔记本好好记一记。”

“作为架构师,我们必须要认真地考虑这些,不仅仅是因为你要节约利用我们的资源,同时更加重要的是要让我们的企业可持续性地增长。”

Werner 将他 20 年的平台构建经验,总结出了七条成为“俭约架构师(The Frugal Architect)”的关键法则。其中包括创建将成本与业务对齐的系统,观察基础设施中的关键运营网络以避免未知的费用,并追求渐进式优化。

“我尝试向初创公司强调这一点,” Werner 说。“你将要采用什么收入模式?他们需要构建符合这一模式的架构。确保你获取收入的维度始终与你的成本保持一致。”

俭约架构师 的七大黄金法则

法则一:将成本视为一种非功能性需求

所谓非功能性需求,就是用于判断系统操作的标准,与具体特性或功能无关。可访问性、可用性、可扩展性、安全性、可移植性、可维护性和合规性等都在此列。而成本往往是其中受到忽略的一条。

“在我们设计的时候,成本是非功能方面的要求,跟安全、合规、可用性、性能这些最经典元素一样,你必须记在心里面,时刻把它体现出来。毕竟我们不仅仅是为了打造技术而打造技术,我们打造这个技术是为了支持业务运营需求的。”

在 Werner 看来,业务之所以身陷困境,往往是因为他们没有考虑到各个阶段中的相应成本——从设计到开发、再到运营——也可能是未能正确量化成本。这背后的原理非常简单:如果成本比收入还高,那还做业务干嘛呢。

架构师需要尽可能早的、以更加可持续的方式考虑成本影响,才能在系统设计过程中在功能、上市时间和效率之间寻求平衡。这样开发团队可以专注于维护更加精简高效的代码,运营部门可以优化资源用量和支出,从而最大限度提高盈利能力。

法则二:确保系统的最终成本与业务保持一致

系统能否长治久安,取决于其成本是否与业务模式高度匹配。在设计和构建系统时,架构师必须考虑收入来源和利润杠杆。更重要的是,必须找到能够产生利润的维度,确保架构规划始终围绕收益展开。

例如,在电子商务领域,这个核心维度可能是订单数量。当订单增加时,基础设施和运营成本也会随之上升。但没关系,只要系统架构设计良好,我们就能享受规模经济带来的红利。最重要的是基础设施成本对业务的影响始终精确、可以量化。

作为架构师,大家需要关注收入,并据此指导技术选型。任何不计代价的增长只会招致毁灭。正如 Werner 强调的:“你要很确定,我们业务基础设施扩展的方式,能让成本成长低于销售收入的增长。”

法则三:架构设计是一系列权衡的集合

在架构当中,每项决定都涉及相应的权衡。成本、弹性和性能这些非功能性需求之间,往往相互冲突、难以调和。

常言道“万事万物终将陨落。”要想抵御这种失败的风险,就必须关注弹性,同时牺牲掉一部分性能。

在技术与业务需求间找到适当的平衡将至关重要,也就是把握住风险承受能力与预算额度间的最佳比例。请记住,俭约是为了最大限度提升价值,而不只是尽可能控制支出。因此,在必须得花的钱上别吝啬。

Werner 还在这个环节指出,创新设计时需要平衡成本、安全性还有洞察力 / 内情这三样东西,“Amazon Lambda 就是在这样的过程中一边探索一边打造出来的。我们在做设计时,始终要保持三个方面的关系,有时候你可能需要在成本方面做一些牺牲,来达到其他的技术或者安全的要求。再往上,我们一定要建一个演化的基础结构,我们要确定我们做事情不能影响到客户,这也是 Lambda 成功的关键。”

法则四:无法观测的系统将带来无法估量的成本

如果不认真观察和测量,系统运营的真实成本将难以把控。就如同隐藏在地下室中的电表一样,这种直观性的缺失必然导致浪费。所以一定要把指标摆在明面上,这将深刻改变运营行为。

Werner 用建筑举了个例子,“上面两个房子是一模一样的,其中一个房子使用的能源量比另外一个房子少了 1/3。为什么呢?关键在于其中一个装了测量器,会自动调整冷暖气。”

尽管实现可观测性需要投入,但这笔钱绝对会物有所值。有句格言说“如果无法量化,也就无法管理。”请始终坚持对利用率、支出、错误等至关重要的成本管理指标保持关注。

当工程师和业务合作伙伴能够随时查看关键成本指标时,自然就会催生出更具可持续性的实践策略。持续检查能帮我们发现非必要支出,并调整运营以减少浪费。总之,可观测性带来的回报往往远超过前期投入。

最重要的是,这本身也是对成本的强调,能在企业中塑造出鼓励可持续性实践的文化。

法则五:依托成本感知架构实现成本控制

俭约架构的本质,在于强大监控与成本优化能力的结合。精心设计的系统能帮助大家抓住改进的机会。为此,请将应用程序拆分成一系列可以调节的构建块。

也就是说,不同的组件一定要有相应的工具来掌控,来操纵这些内容的程式,同时来调试它的矩阵和性能,要能做到随时随地想打开哪些组件就能打开它们,想关上的时候也能及时关上。这个开关必须要置于业务运营的关键环节上,保障你能够轻松控制业务的运营。

一种常见的方法就是按重要性对组件进行分层。T1 层组件必不可少,应当不计成本进行优化;T2 层组件非常重要,但暂时缩小规模也不会产生重大影响;T3 层组件则属于“锦上添花”,要保证其成本低廉且易于控制。

明确定义各层,即可在成本及其他要求之间求得平衡。对组件的精细控制则能优化成本和体验。基础设施、语言、数据库都应具备可调节性,并在系统的设计和构建阶段考虑收入和利润。总之,成本优化必须可量化,且与业务影响直接挂钩。

法则六:成本优化是个渐进的过程

追求成本效率是个持续的过程。即使在部署之后,我们也必须随时审视系统以逐步寻求优化。其中的关键在于不断提问、深入研究。编程语言往往提供分析工具以追踪代码性能,虽然这需要额外的精力和专业知识,但精细的调优足以带来几毫秒的差异。而这种看似微小的优化,累积起来足以产生超出想象的成本优势。

在运营中,大部分时间都被用于运行现有系统。所以请把握一切机会,分析资源使用情况并减少浪费。在亚马逊,我们持续监控生产中的服务,发现运营模式并消除低效因素。俭约是坚持的结果——通过逐步降低延迟和基础设施成本,服务成本才能最终得到优化。

只要不懈努力,我们总能找到改进空间。而今天省下的资源,就是明天创新的燃料。

法则七:没经历过挫折会让人盲目自信

如果软件团队在取得重大成功的过程中,从未经历过任何严重失败或者阻碍,则往往会出现自满情绪。这是一种危险的倾向,会导致团队成员对原本的方法、工具和实践变得盲目信息。

软件团队经常陷入这样的陷阱:仅凭以往的工作经验,他们就认为当前的技术、架构或语言永远是最佳选择。这可能会产生一种错误的安全感,阻碍对现状的质疑,更会打击对可能更加高效、更具成本效益或可扩展性更强的新选项的探索。

说到编程语言,人们往往会说“我们是一家 Java 公司”。这话大有问题,其底层逻辑无疑是在扼杀创新。唾手可得的成功会滋生自满情绪,而只有质疑才能不断激发新的优化与改进思路。

Grace Hopper 的名言,准确反映了这一值得高度警惕的陷阱:“我们一直都是这样做的。”

写在最后

按照惯例,Werner Vogels 以最后一个主题演讲结束今年的 re:Invent 会议。

在过去的一年里,技术演进速度迅速加快。云技术、机器学习和生成式 AI 变得更加容易获得,几乎影响着我们生活的方方面面,从写电子邮件到开发软件,甚至在早期阶段检测癌症。未来几年,旨在实现技术普及并帮助我们跟上日常生活节奏的领域将充满创新——而这一切都从生成式 AI 开始。

许多组织面临的一个困境是,随着对生成式 AI 的兴趣不断高涨,驱动应用程序所需的资源量显着增加,随着生成式 AI 等技术的广泛采用,组织面临的成本压力也在不断增加。

Werner 在他的演讲中强调:“技术的发展非常迅速,我们必须持续学习,深入了解我们的想法所在,并放下自尊心,认真思考成本问题。因为成本是复杂而重要的。”

“过去,我们受到了各种约束条件,虽然我们不想回到过去,但或许我们可以考虑将约束条件纳入我们的系统,以促进成本管理和可持续发展。使用这种约束条件可能会带来不同的成果。”

今日好文推荐

全球首款开源实时操作系统!开发了 20 多年、部署在超 120 亿台设备上的 ThreadX 正式开源

联手 OpenAI 最强竞对展开生成式 AI 反击战:亚马逊云科技将 S3 写入速度提升 10 倍、推出全新三层技术栈

Docker 的诅咒:曾以为它是终极解法,最后却是“罪大恶极”?

一个失败的 AI 女友产品,以及我的教训:来自一位中国开发者的总结

活动推荐

亚马逊云科技权威之作,开启 AI 与机器学习探索之旅!《AIGC 加速企业创新实践指南》和《机器学习助力构建企业创新引擎》是亚马逊云科技凭借多年经验为您精心打造的 AI 与机器学习指南。从入门到精通,无论你是业务决策者还是技术专家,都能在这里找到适合自己的内容,增强自身与企业在 AIGC 时代的竞争力,从此刻开始!扫描二维码即刻下载!


读者福利

继续滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存