风君子博客12月5日消息，2023亚马逊云科技 re:lnvent 的压轴仍然是亚马逊公司副总裁兼首席技术官 Werner Vogels 的演讲。
作为亚马逊CTO，Werner Vogels可谓是亚马逊云科技的灵魂人物，也是云计算领域知名的顶级专家。
Werner Vogels 拥有计算机博士学位，在加入亚马逊之前，Werner Vogels 是一名学者，曾在康奈尔大学进行了十年的研究科学工作，并建立了大规模的分布式系统。
2004年Werner Vogels 加入亚马逊担任系统研究总监，2005年1月被任命为CTO和副总裁至今。
今年是Werner Vogels 第十二次在re:lnvent 亮相。
在今年的演讲中，Werner Vogels 郑重向现场和线上的架构师们推荐了自己写的《The Frugal Architect》（《云架构节俭之道》）这本“新书”。
亚马逊公司副总裁兼首席技术官 Werner Vogels
其实《The Frugal Architect》只有短短7页，每页对应了Werner Vogels 想要强调的一项法则，为架构师和开发者们提供了有关架构设计、衡量、优化的规范准则教程。
在全球企业都在强调“降本”的大环境中，理解《The Frugal Architect》可谓正合时宜。
以下为《The Frugal Architect》的内容：
LAW I.
Make Cost a Non-functional Requirement.
A non-functional requirement specifies criteria that can be used to judge the operation of a system, rather than specific features or functions. Examples are accessibility, availability, scalability, security, portability, maintainability, and compliance. What often goes overlooked is cost.
Companies can fail because they don’t consider cost at every stage of the business – from design to development to operation – or because they’re not measuring it properly. The math is simple: if costs are higher than your revenue, your business is at risk.
By considering cost implications early and continuously, systems can be designed to balance features, time-to-market, and efficiency. Development can focus on maintaining lean and efficient code. And operations can fine-tune resource usage and spending to maximize profitability.
法则I
使成本成为非功能性需求。
非功能性需求指定了可用于判断系统运行的标准，而不是特定的特征或功能。示例包括可访问性、可用性、可扩展性、安全性、可移植性、可维护性和法规遵从性。经常被忽视的是成本。
公司可能会失败，因为他们没有考虑到业务的每个阶段——从设计到开发再到运营——或者因为他们没有正确地衡量成本。数学很简单：如果成本高于收入，你的企业就面临风险。
通过尽早和持续地考虑成本影响，可以设计系统来平衡功能、上市时间和效率。开发可以专注于维护精简高效的代码。运营可以微调资源使用和支出，以最大限度地提高盈利能力。
LAW II.
Systems that Last Align Cost to Business.
The durability of a system depends on how well its costs are aligned to the business model. When designing and building systems, we must consider the revenue sources and profit levers. It’s important to find the dimension you’re going to make money over, then make sure the architecture follows the money.
For example, in e-commerce, that dimension might be the number of orders. When orders go up, infrastructure and operation costs rise. And that’s okay, because if your system is architected well, you can start to exploit economies of scale. What’s important is that infrastructure costs have a measurable impact on the business.
As builders, we need to think about revenue – and use that knowledge to inform our choices. Because growth at all costs leads to a trail of destruction.
法则II
最后使成本与业务保持一致的系统。
系统的持久性取决于其成本与商业模式的一致性。在设计和构建系统时，我们必须考虑收入来源和利润杠杆。重要的是要找到你将要赚钱的维度，然后确保架构遵循资金。
例如，在电子商务中，该维度可能是订单数量。当订单增加时，基础设施和运营成本就会上升。这没关系，因为如果你的系统架构良好，你就可以开始利用规模经济。重要的是，基础设施成本对业务有着可衡量的影响。
作为构建者，我们需要考虑收入，并利用这些知识为我们的选择提供信息。因为不惜一切代价的增长会带来毁灭的痕迹。
LAW III.
Architecting is a Series of Trade-offs.
In architecture, every decision comes with a trade-off. Cost, resilience, and performance are non-functional requirements that are often at tension with each other.
As the saying goes, “Everything fails, all the time.” Being able to defend against failure means investing in resilience, but performance may pay the price.
It’s crucial to find the right balance between your technical and business needs – to find the sweet spot that aligns with your risk tolerance and budget. Remember, frugality is about maximizing value, not just minimizing spend. And to do that, you need to determine what you’re willing to pay for.
法则 III
在持续的取舍与权衡中搭建架构。
在体系结构中，每一个决策都伴随着一种权衡。成本、弹性和性能是非功能性需求，它们往往相互矛盾。
俗话说：“一切都会失败。”能够抵御失败意味着投资于韧性，但业绩可能会付出代价。
在您的技术和业务需求之间找到正确的平衡至关重要——找到与您的风险承受能力和预算相一致的最佳点。记住，节俭是价值最大化，而不仅仅是支出最小化。要做到这一点，你需要确定你愿意为什么付费。
LAW IV.
Unobserved Systems Lead to Unknown Costs.
Without careful observation and measurement, the true costs of operating a system remain invisible. Like a utility meter tucked away in a basement, lack of visibility enables wasteful habits. Making meters more visible can profoundly shift behaviors.
Though observation requires investment, not implementing adequate monitoring is shortsighted. The adage warns, “If you can’t measure it, you can’t manage it.” Tracking utilization, spending, errors, and more, is crucial for cost management.
When critical cost metrics are placed front-and-center before engineers and their business partners, more sustainable practices emerge organically. Ongoing inspection lets you spot excess spend and tune operations to trim expenses. The return on investment in observability typically far outweighs the expense.
Most importantly, keeping costs in the forefront encourages sustainable practices.
法则IV
未观测到的系统带来未知的成本
如果没有仔细的观察和衡量，运行一个系统的真正成本仍然是看不见的。就像藏在地下室的公用事业计量表一样，缺乏可见性会导致浪费的习惯。使仪表更显眼可以深刻地改变行为。
尽管观察需要投资，但不进行充分的监测是短视的。这句格言警告说，“如果你不能衡量它，你就无法管理它。”跟踪利用率、支出、错误等对成本管理至关重要。
当关键成本指标被放在工程师及其业务合作伙伴之前的首要位置和中心位置时，更可持续的实践就会有机地出现。持续的检查可以让您发现多余的支出，并调整运营以削减开支。可观测性的投资回报通常远远超过支出。
最重要的是，将成本保持在首位会鼓励可持续的做法。
LAW V.
Cost Aware Architectures Implement Cost Controls.
The essence of frugal architecture is robust monitoring combined with the ability to optimize costs. Well-designed systems allow you to take action on opportunities for improvement. For this to work, decompose applications into tunable building blocks.
A common approach is tiering components by criticality. Tier 1 components are essential; optimize regardless of cost. Tier 2 components are important but can be temporarily scaled down without major impact. Tier 3 components are “nice-to-have”; make them low-cost and easily controlled.
Defining tiers enables trade-offs between cost and other requirements. Granular control over components optimizes both cost and experience. Infrastructure, languages, databases should all be tunable. Architect and build systems with revenue and profit in mind. Cost optimization must be measurable and tied to business impact.
法则V
通过成本感知的架构实施成本控制。
节俭架构的本质是稳健的监控与优化成本的能力相结合。精心设计的系统使您能够抓住改进的机会采取行动。要实现这一点，请将应用程序分解为可调的构建块。
一种常见的方法是按关键程度对组件进行分层。一级组件是必不可少的；优化而不考虑成本。二级组件很重要，但可以暂时缩减，不会产生重大影响。第3层组件是“很好拥有的”；使其成本低且易于控制。
定义层可以在成本和其他需求之间进行权衡。对组件的精细控制可优化成本和体验。基础设施、语言和数据库都应该是可调的。在设计和构建系统时考虑到收入和利润。成本优化必须是可衡量的，并与业务影响挂钩。
LAW VI.
Cost Optimization is Incremental.
The pursuit of cost efficiency is an ongoing journey. Even after deployment, we must revisit systems to incrementally improve optimization. The key is continually questioning and diving deeper. Programming languages provide profiling tools to analyze code performance, and while these require setup and expertise, they enable granular analyses that can lead to changes that shave milliseconds. What may seem like small optimizations accumulate into large savings at scale.
In operations, most time is spent running existing systems. There are opportunities to profile resource usage and identify waste reduction. At Amazon, we continuously monitor services in production to understand patterns and trim inefficiencies. Frugality takes persistence – by incrementally reducing latencies and infrastructure costs, we can optimize the cost to serve.
There is always room for improvement… if we keep looking. The savings we reap today fund innovation for tomorrow.
法则VI
成本优化是渐进的
追求成本效益是一个持续的过程。即使在部署之后，我们也必须重新访问系统以逐步改进优化。关键是不断质疑和深入研究。编程语言提供了分析代码性能的分析工具，虽然这些工具需要设置和专业知识，但它们可以实现细粒度分析，从而导致缩短几毫秒的更改。看似微小的优化会大规模地积累成巨大的节约。
在操作中，大部分时间都花在运行现有系统上。有机会了解资源使用情况并确定废物减少情况。在亚马逊，我们持续监控生产中的服务，以了解模式并降低效率。节俭需要持久性——通过逐步减少延迟和基础设施成本，我们可以优化服务成本。
如果我们继续寻找，总有改进的空间。我们今天节省下来的资金用于明天的创新
LAW VII.
Unchallenged Success Leads to Assumptions.
When software teams achieve significant success without facing major failures or roadblocks, complacency can set in. There is a dangerous tendency to become overconfident in the methods, tools, and practices that led to those wins.
Software teams often fall into the trap of assuming their current technologies, architectures, or languages will always be the best choice, simply because they have worked in the past. This can create a false sense of security that discourages questioning the status quo or exploring new options which could be more efficient, cost-effective, or scalable.
You see this frequently when it comes to programming languages. “We’re a Java shop” is a phrase I’ve heard too often – and it can stifle innovation. Unchallenged success breeds complacency through assumptions. We must always look for ways to question, optimize and improve.
As Grace Hopper famously stated, one of the most dangerous phrases in the English language is: “We’ve always done it this way.”
法则VII
走出惯性，远离盲目
当软件团队在没有面临重大失败或障碍的情况下取得重大成功时，就会产生自满情绪。对导致这些胜利的方法、工具和实践有过度自信的危险倾向。
软件团队经常陷入这样的陷阱，即认为他们当前的技术、体系结构或语言永远是最好的选择，仅仅因为他们过去是这样工作的。这可能会产生一种虚假的安全感，阻碍人们质疑现状或探索更高效、更具成本效益或可扩展的新选择。
当涉及到编程语言时，您经常会看到这种情况。“我们是一家Java商店”是我经常听到的一句话——它会扼杀创新。不受挑战的成功通过假设滋生自满情绪。我们必须始终寻找质疑、优化和改进的方法。
正如Grace Hopper的名言，英语中最危险的短语之一是：“我们一直都是这样做的。”