架構師們，亞馬遜CTO喊你看看這本書

12月5日消息，2023亞馬遜云科技 re:lnvent 的壓軸仍然是亞馬遜公司副總裁兼首席技術官 Werner Vogels 的演講。

作為亞馬遜CTO，Werner Vogels可謂是亞馬遜云科技的靈魂人物，也是云計算領域知名的頂級專家。

Werner Vogels 擁有計算機博士學位，在加入亞馬遜之前，Werner Vogels 是一名學者，曾在康奈爾大學進行了十年的研究科學工作，并建立了大規(guī)模的分布式系統(tǒng)。

2004年Werner Vogels 加入亞馬遜擔任系統(tǒng)研究總監(jiān)，2005年1月被任命為CTO和副總裁至今。

今年是Werner Vogels 第十二次在re:lnvent 亮相。

在今年的演講中，Werner Vogels 鄭重向現(xiàn)場和線上的架構師們推薦了自己寫的《The Frugal Architect》（《云架構節(jié)儉之道》）這本“新書”。

亞馬遜公司副總裁兼首席技術官 Werner Vogels

其實《The Frugal Architect》只有短短7頁，每頁對應了Werner Vogels 想要強調的一項法則，為架構師和開發(fā)者們提供了有關架構設計、衡量、優(yōu)化的規(guī)范準則教程。

在全球企業(yè)都在強調“降本”的大環(huán)境中，理解《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

使成本成為非功能性需求。

非功能性需求指定了可用于判斷系統(tǒng)運行的標準，而不是特定的特征或功能。示例包括可訪問性、可用性、可擴展性、安全性、可移植性、可維護性和法規(guī)遵從性。經(jīng)常被忽視的是成本。

公司可能會失敗，因為他們沒有考慮到業(yè)務的每個階段——從設計到開發(fā)再到運營——或者因為他們沒有正確地衡量成本。數(shù)學很簡單：如果成本高于收入，你的企業(yè)就面臨風險。

通過盡早和持續(xù)地考慮成本影響，可以設計系統(tǒng)來平衡功能、上市時間和效率。開發(fā)可以專注于維護精簡高效的代碼。運營可以微調資源使用和支出，以最大限度地提高盈利能力。

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

最后使成本與業(yè)務保持一致的系統(tǒng)。

系統(tǒng)的持久性取決于其成本與商業(yè)模式的一致性。在設計和構建系統(tǒng)時，我們必須考慮收入來源和利潤杠桿。重要的是要找到你將要賺錢的維度，然后確保架構遵循資金。

例如，在電子商務中，該維度可能是訂單數(shù)量。當訂單增加時，基礎設施和運營成本就會上升。這沒關系，因為如果你的系統(tǒng)架構良好，你就可以開始利用規(guī)模經(jīng)濟。重要的是，基礎設施成本對業(yè)務有著可衡量的影響。

作為構建者，我們需要考慮收入，并利用這些知識為我們的選擇提供信息。因為不惜一切代價的增長會帶來毀滅的痕跡。

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

在持續(xù)的取舍與權衡中搭建架構。

在體系結構中，每一個決策都伴隨著一種權衡。成本、彈性和性能是非功能性需求，它們往往相互矛盾。

俗話說：“一切都會失敗。”能夠抵御失敗意味著投資于韌性，但業(yè)績可能會付出代價。

在您的技術和業(yè)務需求之間找到正確的平衡至關重要——找到與您的風險承受能力和預算相一致的最佳點。記住，節(jié)儉是價值最大化，而不僅僅是支出最小化。要做到這一點，你需要確定你愿意為什么付費。

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

未觀測到的系統(tǒng)帶來未知的成本

如果沒有仔細的觀察和衡量，運行一個系統(tǒng)的真正成本仍然是看不見的。就像藏在地下室的公用事業(yè)計量表一樣，缺乏可見性會導致浪費的習慣。使儀表更顯眼可以深刻地改變行為。

盡管觀察需要投資，但不進行充分的監(jiān)測是短視的。這句格言警告說，“如果你不能衡量它，你就無法管理它?！备櫪寐?、支出、錯誤等對成本管理至關重要。

當關鍵成本指標被放在工程師及其業(yè)務合作伙伴之前的首要位置和中心位置時，更可持續(xù)的實踐就會有機地出現(xiàn)。持續(xù)的檢查可以讓您發(fā)現(xiàn)多余的支出，并調整運營以削減開支?？捎^測性的投資回報通常遠遠超過支出。

最重要的是，將成本保持在首位會鼓勵可持續(xù)的做法。

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

通過成本感知的架構實施成本控制。

節(jié)儉架構的本質是穩(wěn)健的監(jiān)控與優(yōu)化成本的能力相結合。精心設計的系統(tǒng)使您能夠抓住改進的機會采取行動。要實現(xiàn)這一點，請將應用程序分解為可調的構建塊。

一種常見的方法是按關鍵程度對組件進行分層。一級組件是必不可少的；優(yōu)化而不考慮成本。二級組件很重要，但可以暫時縮減，不會產生重大影響。第3層組件是“很好擁有的”；使其成本低且易于控制。

定義層可以在成本和其他需求之間進行權衡。對組件的精細控制可優(yōu)化成本和體驗。基礎設施、語言和數(shù)據(jù)庫都應該是可調的。在設計和構建系統(tǒng)時考慮到收入和利潤。成本優(yōu)化必須是可衡量的，并與業(yè)務影響掛鉤。

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

成本優(yōu)化是漸進的

追求成本效益是一個持續(xù)的過程。即使在部署之后，我們也必須重新訪問系統(tǒng)以逐步改進優(yōu)化。關鍵是不斷質疑和深入研究。編程語言提供了分析代碼性能的分析工具，雖然這些工具需要設置和專業(yè)知識，但它們可以實現(xiàn)細粒度分析，從而導致縮短幾毫秒的更改。看似微小的優(yōu)化會大規(guī)模地積累成巨大的節(jié)約。

在操作中，大部分時間都花在運行現(xiàn)有系統(tǒng)上。有機會了解資源使用情況并確定廢物減少情況。在亞馬遜，我們持續(xù)監(jiān)控生產中的服務，以了解模式并降低效率。節(jié)儉需要持久性——通過逐步減少延遲和基礎設施成本，我們可以優(yōu)化服務成本。

如果我們繼續(xù)尋找，總有改進的空間。我們今天節(jié)省下來的資金用于明天的創(chuàng)新

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

走出慣性，遠離盲目

當軟件團隊在沒有面臨重大失敗或障礙的情況下取得重大成功時，就會產生自滿情緒。對導致這些勝利的方法、工具和實踐有過度自信的危險傾向。

軟件團隊經(jīng)常陷入這樣的陷阱，即認為他們當前的技術、體系結構或語言永遠是最好的選擇，僅僅因為他們過去是這樣工作的。這可能會產生一種虛假的安全感，阻礙人們質疑現(xiàn)狀或探索更高效、更具成本效益或可擴展的新選擇。

當涉及到編程語言時，您經(jīng)常會看到這種情況?！拔覀兪且患襃ava商店”是我經(jīng)常聽到的一句話——它會扼殺創(chuàng)新。不受挑戰(zhàn)的成功通過假設滋生自滿情緒。我們必須始終尋找質疑、優(yōu)化和改進的方法。

正如Grace Hopper的名言，英語中最危險的短語之一是：“我們一直都是這樣做的。”

生成海報

免責聲明：本網(wǎng)站內容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內容可能涉嫌侵犯其知識產權或存在不實內容時，應及時向本網(wǎng)站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內容或斷開相關鏈接。