你好，我是猿java。
每到年底，各种技术盛会，让人应接不暇，今天带来的是亚马逊CTO Werner Vogels博士在 re:Invent 大会上分享的俭约架构七大黄金法则，20年架构的精粹，在全球企业都在"降本增效"的大环境下，能否雪中送炭？
Werner Vogels简介
Werner Vogels，出生于1958 年10月3日，计算机博士，2004 年 9 月加入亚马逊Amazon，2005 年 1月至今，一直担任亚马逊的 CTO（首席技术官），他是 Amazon Web Services（AWS）的主要发起人之一。
Werner Vogels 博士在云计算领域有着广泛的影响力，他对技术的见解以及对分布式系统、大规模计算和可扩展性的深入理解使得他成为业界的权威，并被认为是云计算领域的重要思想领袖之一。Werner Vogels 博士在 2023年 re:Invent 大会的照片：
65岁，一位爷爷级的技术大牛，本该退休安享晚年，却依然朝气蓬勃活跃在技术前沿，是不是狠狠地打脸国内程序员的 35岁危机？
re:Invent 是什么？
re:Invent 是亚马逊举办的一年一度的技术会议，重点关注云计算和 AWS 服务。该会议是 AWS 最大规模的全球性活动之一，汇集了来自全球各地的技术专家、开发者、企业家和 IT 专业人士。
re:Invent 包括各种技术会议、演讲、研讨会、实验室、培训课程、展示和交流活动。AWS 会在该会议上发布新的服务、功能和工具，同时也提供了一个平台让用户分享最佳实践、案例研究和技术见解。
此外，re:Invent 也是一个让参与者互相交流和建立联系的平台，他们可以与同行、AWS 的工程师和合作伙伴进行交流，分享经验和洞察，了解云计算领域的最新发展。
The Frugal Architect
The Frugal Architect：翻译为：节俭的建筑师，要求在设计和构建软件系统或解决方案时，遵循节俭、精简和有效利用资源的原则。
在软件架构领域，The Frugal Architect 意味着设计者或架构师在创建系统时尽量避免过度设计、复杂性和浪费资源的情况。
那么，在 Werner Vogels博士的眼中，The Frugal Architect 是什么？接下来，就让我们一起来品味下他总结的俭约架构七大黄金法则。
法则一：使成本成为非功能性需求****
非功能性需求指定可用于判断系统操作的标准，而不是特定的特性或功能。例如可访问性、可用性、可扩展性、安全性、可移植性、可维护性和合规性。经常被忽视的是成本。公司可能会失败，因为他们没有考虑业务的每个阶段（从设计到开发再到运营）的成本，或者因为他们没有正确衡量成本。数学很简单：如果成本高于你的收入，业务就会面临风险。通过尽早持续考虑成本影响，系统可以设计为平衡功能、上市时间和效率。开发可以专注于维护精简高效的代码。运营部门可以微调资源使用和支出，以最大限度地提高盈利能力。
法则二：最终使成本与业务保持一致的系统
系统的耐用性取决于其成本与业务模式的匹配程度。在设计和构建系统时，我们必须考虑收入来源和利润杠杆。重要的是找到你要赚钱的维度，然后确保架构跟随金钱。
例如，在电子商务中，该维度可能是订单数量。当订单增加时，基础设施和运营成本就会上升。没关系，因为如果你的系统架构良好，你就可以开始利用规模经济。重要的是基础设施成本对业务具有可衡量的影响。
作为建设者，我们需要考虑收入------并利用这些知识来指导我们的选择。因为不惜一切代价的增长会导致毁灭。
法则三：架构设计是一系列的权衡
在建筑中，每个决定都需要权衡。成本、弹性和性能是非功能性需求，它们常常相互矛盾。
俗话说："一切都会失败。"能够抵御失败意味着投资于韧性，但绩效可能会付出代价。
在你的技术和业务需求之间找到适当的平衡至关重要 - 找到与你的风险承受能力和预算相符的最佳点。请记住，节俭是为了最大化价值，而不仅仅是最小化支出。为此，你需要确定你愿意支付的费用。
法则四：未观察到的系统会导致未知的成本
如果不仔细观察和测量，操作系统的真实成本仍然是看不见的。就像藏在地下室的电表一样，缺乏能见度会导致浪费的习惯。让仪表变得更加明显可以深刻地改变行为。
尽管观察需要投资，但不实施充分的监测是短视的行为。这句格言警告说："如果你无法衡量它，你就无法管理它。"跟踪利用率、支出、错误等对于成本管理至关重要。
当关键成本指标被置于工程师及其业务合作伙伴的首要位置时，更可持续的实践就会自然而然地出现。持续的检查可以让你发现多余的支出并调整运营以削减支出。可观测性的投资回报通常远远超过成本。
最重要的是，将成本放在首位可以鼓励可持续实践。
法则五：成本感知架构实施成本控制
节俭架构的本质是强大的监控与优化成本的能力相结合。精心设计的系统使你能够抓住改进的机会采取行动。为此，请将应用程序分解为可调整的构建块。
一种常见的方法是按重要性对组件进行分层。第 1 层组件必不可少；不考虑成本进行优化。第 2 层组件很重要，但可以暂时缩小规模，不会产生重大影响。第 3 层组件是"必备的"；使它们成本低廉且易于控制。
定义层可以在成本和其他要求之间进行权衡。对组件的精细控制可以优化成本和体验。基础设施、语言、数据库都应该是可调的。设计和构建系统时要考虑到收入和利润。成本优化必须是可衡量的，并与业务影响挂钩。
法则六：成本优化是渐进的
追求成本效率是一个持续的过程。即使在部署之后，我们也必须重新审视系统以逐步改进优化。关键是不断提问并深入研究。编程语言提供分析工具来分析代码性能，虽然这些需要设置和专业知识，但它们支持精细分析，从而导致缩短毫秒的更改。看似微小的优化，累积起来会产生大规模的节省。
在运营中，大部分时间都花在运行现有系统上。有机会分析资源使用情况并确定减少浪费。在亚马逊，我们持续监控生产中的服务，以了解模式并消除低效率。节俭需要坚持------通过逐步减少延迟和基础设施成本，我们可以优化服务成本。
如果我们继续寻找，总会有改进的空间。我们今天获得的节省为明天的创新提供了资金。
法则七：毫无挑战的成功会导致盲目
当软件团队在没有面临重大失败或障碍的情况下取得重大成功时，就会出现自满情绪。存在一种危险的倾向，即对导致这些胜利的方法、工具和实践变得过度自信。
软件团队经常陷入这样的陷阱：仅仅因为他们过去的工作经验，就认为他们当前的技术、架构或语言永远是最佳选择。这可能会产生一种错误的安全感，阻碍质疑现状或探索可能更高效、更具成本效益或可扩展的新选择。
当谈到编程语言时，你经常会看到这种情况。"我们是一家 Java 商店"是我经常听到的一句话，它会扼杀创新。无可争议的成功会通过假设滋生自满情绪。我们必须始终寻找质疑、优化和改进的方法。
正如格蕾丝·霍珀（Grace Hopper）的名言，英语中最危险的短语之一是："我们一直都是这样做的。"
个人思考
- 角色转换
Werner Vogels 博士在 re:Invent 大会上把Architect 称为 Builder，或许对于"架构师" 这个称呼，很多人会困惑他的职责范围，但如果换成 Builder-建设者，就算你不从事计算机行业应该也能很清晰的他工作，比如：建房子，房子美不美，结不结实，完全取决你。角色的转换让我们对架构师有了更进一层的理解。
- 关注成本
亚马逊，世界 Top前几的科技型公司，CTO 却在 re:Invent 这种全球性的技术大会上一直强调关注成本，很意外？这是否意味着 2024年，将会有更多的公司追捧这一法则，在不断减少预算的情况下继续推动产品创新？对于技术人来说会不会是更大的挑战？
- 云原生
就算没有用过云，也应该听过 docker, K8s等和云相关的名词，国内，但凡有点规模的企业似乎都在上云，云原生通过容器化、微服务架构、持续交付和自动化等技术实践来优化应用程序的开发、部署和管理，突破了物理硬件的束缚，大大提高了应用程序的可靠性、可用性和安全性，同时也提升了开发团队的效率和创新能力。
- 架构是一种权衡
在日常的开发中，很多时候都是时间和空间的权衡，架构何尝不是，功能性和非功能性的权衡。
强烈推荐大家看看原视频：亚马逊 CTO 20 年架构精华：俭约架构七大黄金法则
最后，把猿哥的座右铭送给你： 投资自己才是最大的财富。 由于水平有限，如果文章存在缺点和错误，欢迎批评指正。