因此，在制定技術策略時，你需要評估與業務成功相關的每個組成部分。
本文的內容源自我最近在都柏林 AWS 社區日活動上的一次演講，演講內容是關於我所經歷過的一些行不通的技術策略，以及幫助我們在 Intercom 實現增長和擴張的策略。
這些只是我的個人觀點，並不是規則，當然也不可能適用於所有情況。
它們是基於我在技術領域的工作經驗、它們在不同場景中的實際應用以及與同行討論的結果。儘管它們看起來像是某種觀點，但其中的很多技巧都反映了軟件工程的主要原則：使用現有的資源、根據需要來設計解決方案、不要重複自己（DRY）、保持簡單和愚蠢（KISS）！
如果你在過去幾年裏一直有關注一些口號喊得很響亮的技術營銷，那麼你肯定聽說過多雲。多雲是指將應用程序部署到跨多個雲提供商的異構雲平臺上。
雖然這些營銷看起來還不錯，但根據雲經濟學家 Corey Quinn 的說法，多雲違背了最佳實踐，是“默認要避免的糟糕實踐”。Corey 致力於爲他的客戶減少 AWS 賬單成本，在實踐中親眼目睹了大量的雲架構，所以我認爲他的經歷是一個很好的參考來源。
多雲架構對於幾乎所有的企業（尤其是初創企業）來說都是一種過早優化，是一個你不想掉入的陷阱。你的公司可能有很多問題需要解決，這些問題遠比任何與多雲部署有關的神話般的好處都更有價值。
人們對多雲的一個常見誤解是多雲策略將幫助他們避免供應商鎖定，這源於他們對未來業務需求的模糊錯覺。而且，這可能很耗費資源，因爲抽離出任何特定雲提供商的價值是很費時的，並且會影響你從雲計算中獲得好處的能力。
當然，在某些情況下，多雲戰略對你有利。除非你是 Netflix 或蘋果，並佔據了大部分互聯網流量。對於大多數企業來說，選擇好一個雲提供商，不要再想着在它們之間來回移動工作負載。將全部精力放在一個雲提供商上，雲平臺纔會展現出它的魔力：易用性、簡單性和效率。
不要使用最好的工具來完成工作，這聽起來有悖常理，不是嗎？在 AWS 平臺上，DynamoDB 可能是最好的高可用鍵值數據訪問存儲工具，Timestream 可能是最好的時間序列數據工具。然而，如果你已經有了一個正在運行的 MySQL Aurora，你就不能直接把數據放在那裏嗎？
“你應該進行全局優化，所以你應該使用已經在使用的工具”。
即使是在雲端，增加新技術也會分散你的注意力。你應該進行全局優化，使用你已經在使用的工具。除非你確定現有的軟件無法滿足你的需求，否則不要往你的技術棧中增加更多的技術。
在 Intercom，我們稱之爲“運行更少的軟件”，這是我們技術策略的一部分。我們認爲，這對我們來說很有幫助。它幫助我們避免了創建和維護大量會拖慢我們開發速度的東西。
在剛開始創立初創公司時，可能不是你瞭解 Kubernetes 的最佳時機。但如果你已經有一個積累多年的重要的基礎設施需要構建，或者如果你的產品是要出售給 Kubernetes 用戶，那麼可以去了解。但是，除非你已經非常精通 Kubernetes，否則的話，啓動並運行一個服務的最快方法是使用最簡單、最靈活、最常見的構建塊，比如在負載均衡器後面部署一堆可自動伸縮的 EC2 主機。
在 Intercom，我們成功地將 Lambda 作爲 AWS 服務之間的粘合代碼。我認爲 Lambda 是一項驚人的技術，但它應該被用在對的地方。它擅長執行由事件觸發的簡單任務，比如調整上傳到 S3 存儲桶中的圖像的大小。我喜歡把它們看成是雲的存儲過程，但我不想用 Lambda 運行一個大型的、複雜的應用程序，因爲限制很大，而且在可觀察性方面還不夠成熟。
由前 AWS 工程師 Daniel Vassallo 和 Josh Pschorr 合著的“The Good Parts of AWS”一書對應該使用 AWS 的哪些部分提出了很好的見解，並對 Lambda 進行了評價。“我們認爲 Lambda 是非常棒的——絕對是 AWS 的一個非常好的組成部分——只要你把它當作簡單的代碼運行器。我們經常看到的一個問題是，人們有時候會誤認爲 Lambda 是一個通用的應用程序宿主”。
如果你認爲將其加入到你的技術棧是正確的，那麼就把它用在對的地方，不要把它當成一個通用的計算平臺，不過它確實可以很好與 AWS 生態系統的其他部分協同工作，況且 Lambda 團隊一直在推出非常棒的特性。
和 Kubernetes 一樣，除非你的團隊已經在微服務方面有很多經驗，否則大多數初創公司都不應該採用微服務。使用微服務增加了複雜性，增加了出錯的概率，而且與一兩個單體服務相比，構建很多微服務要做更多的工作。
“我們的團隊想要開發產品，而不是維護服務”。
大約 6 年前，在 Intercom，我們認爲重要的新功能應該作爲獨立的服務來開發，這是不可避免的。因此，我們構建了一些新功能，比如將 Webhook 和事件處理作爲微服務，與我們的 Ruby on Rails 單體系統通信。但隨着時間的推移，我們發現我們的團隊不喜歡維護這些服務。
維護這些服務需要大量的開銷和繁重的重複工作，與開發單體系統相比，在微服務中添加新功能似乎需要更長的時間。我們的團隊想要開發產品，而不是維護服務。在過去的幾年裏，我們一直在把服務合併回 Ruby on Rails 單體系統中。我想類似的經驗也適用於其他面向服務架構的系統。
我幾乎每次在 AWS 控制檯中做配置時都會後悔。“單擊”操作雖然很高效，但具有版本控制、經過同行評審的基礎架構定義也很重要。不管你使用的是 Cloudformation、Terraform，還是更高級別的工具 (如 AWS 雲開發工具包)，這些並不重要。任何方法都比在 AWS 控制檯中單擊鼠標要好。
大多數時候，通過代碼或配置定義的基礎設施更容易維護。在代碼中定義基礎設施並不一定會很複雜。在控制檯中使用模塊可能非常強大，但也可能導致意想不到的副作用，所以我更傾向於避免 DRY(不要重複自己)，喜歡簡單的聲明性指令。
雲是實現規模化構建的好地方，但這並不意味着你必須這麼做。在 1968 年出版的《計算機編程的藝術》一書中，Donald Knuth 指出：“過早優化是萬惡之源”。
“在非必要時添加極端的可伸縮性，很容易讓你掉入技術債務和低效率的陷阱”。
當然，通過使用 S3、Amazon Simple Queue Service (SQS) 和 DynamoDB 等產品，你可以輕鬆獲得難以想象的伸縮性，而且現在的計算機非常快。但是，正如極限編程聯合作者 Ron Jeffries 所說的那樣：“你很可能不需要它”。在非必要時添加極端的可伸縮性，很容易讓你掉入技術債務和低效率的陷阱。現如今，你完全可以用少量的計算機和一個數據庫做很多事情。
沒有人喜歡浪費錢，但在雲平臺上肯定有很多浪費錢的地方。AWS 的計費和優化是一個大難題，儘管原生工具的極大改進和新的購買力形式 (如 節約計劃) 讓這變得越來越容易。
我認爲最好的辦法是對成本做出反應。發佈你構建的東西，然後設置一個日曆提醒，以便日後跟蹤成本。我們很難準確地預測某些東西需要多少成本——比如，如果你正在構建一個全新的服務，你需要花多少精力來計算相關的帶寬費用、Aurora Storage IO 和 Amazon 簡單隊列服務 (SQS) 的成本？這些並不好估算。
我還發現，人們很喜歡在降低項目成本方面“小打小鬧”。移除一些沒用過的彈性 IP 或 EBS，每個月可以省下不少錢，而且清理東西會給人一種滿足感。但它真的會改變業務未來的結果嗎？有時候，我試圖爲這些行爲辯護，因爲這樣可以讓基礎設施變得更清晰，特別是對於一個有些年頭的 AWS 賬戶來說。但是，大多數時候，最好把注意力放在大問題上，而不是小打小鬧地降低成本。
話雖如此，我在 Intercom 確實花了不少時間來優化成本。對於一個在 AWS 上花費巨大、業務需求明確的成熟企業來說，這是絕對值得做的工作，因爲這確實會影響實際的業務結果。我們當然不是唯一一家通過成本優化來減少賬單的公司。
閱讀那些曾經是初創公司但現在已大獲成功的公司的工程博客，比如 Netflix、Uber 或 Airbnb，這會讓你分心，讓你爲不存在的問題提供過度工程的解決方案。此外，你真正需要從這些成功的公司獲得的信息通常不會在博客或會議演講中透露。這些東西通常是一些工程師爲完成 KPI 或 OKR 而做的事情。相反，你應該與規模相似的初創公司的工程師們建立關係。根據我的經驗，這樣做非常有效。
從成功的初創公司那裏獲得靈感是件好事，但你絕對不應該去模仿像亞馬遜、谷歌和微軟這樣的大型雲供應商。一些公司可能受益於單體代碼庫、5 個 9 的可用性、微服務或站點可靠性工程 (SRE)，但這些主要是爲了解決大型組織所面臨的問題。與其讓初創公司擔心他們的混沌工程策略，不如去構建一小羣易於理解的、內置了大量冗餘的託管服務，讓其他人去擔心如何使用混沌工程來改進他們的託管服務。
對於你的創業公司來說，一個絕對糟糕的技術策略就是按照你在會議上聽到的去做。只有你最瞭解你的業務背景和技術挑戰。核心競爭力和繁重的重複工作之間的區別並不總是涇渭分明的。在定義和實施技術戰略時，需要考慮大量的人爲因素，所以不要盲目地做這些事情。
安全是互聯網行業現今優先級最高的任務。不僅用戶的期望比以往任何時候都要高，像 GDPR 這樣的法規也要求在產品中內置合理的安全級別。
“在安全問題上讓客戶不省心肯定會讓客戶失去信心”。
在安全問題上讓客戶不省心肯定會讓客戶失去信心。從一開始就在每個產品和功能中添加安全性要比之後再添加容易得多。隨着你的公司進入高端市場，與更大客戶之間的對話將變得更加細節化，對你的產品要求也更加嚴格。值得慶幸的是，這比以往任何時候都要容易，因爲雲平臺提供了良好的安全選項，而且在不斷改進，比如 S3 桶配置，可以避免你在使用雲服務時遇到的一些典型的問題。
在 Intercom，我們說“交付就是公司的心臟”。我認爲專注於交付的公司能夠取得成功絕非偶然。
我認爲由 Nicole forgren、Jez Humble 和 Gene Kim 合著的《加速：精益軟件和 DevOps 的科學》一書是高績效技術企業的聖經。作者運用研究方法來發現在真實公司中獲得成功的最佳實踐。如果你關心你的企業是否可以取得成功，不管是什麼行業，你都將從書中獲益。
理想情況下，你應該要招聘真正想要成長的通才。成長心態本身就能鼓勵成長，在一個快速成長的環境中，你會需要它的。專家雖然可以提供誘人的生產力，但最終他們可能會變成拖慢速度的“孤島”，阻礙協作優勢的發揮。
“如果你招聘了擁有深厚專業知識的人，你應該要確保他們能夠分享專業知識，幫助你發展團隊”。
如果整個團隊無法解決最大的問題，你就不會得到最好的解決方案。你要讓團隊成員成長爲可以深入理解公司主要問題的人，而不是成爲“孤島”。如果你確實僱傭了擁有深厚專業知識的人，你應該要確保他們能夠分享專業知識，幫助你發展團隊。
正如我所提到的，使用少量易於理解的服務是明智的做法。Elasticache、SQS 和 Amazon 關係數據庫服務 (RDS) 是更好的默認選擇，而不是使用自己的 Memcached、RabbitMQ 或自己維護的 MySQL 集羣。
同樣地，我認爲一些雲安全管理和 AI/ML 服務看起來非常棒，在建立類似的東西之前，我會先研究一下它們。當你確實需要解決一些超出當前技術棧的問題時，我建議先避免自己去構建任何東西，而是簡單地使用現有云提供商提供的東西。
如果你真的把這一點付諸實踐，這意味着世界級的可觀察性、監視、最佳運維實踐、良好的正常運行時間、性能和可靠的安全性。
我認爲 Jeff Bezos 所說的“總是從客戶角度出發”這個觀點是對的。我在亞馬遜工作時第一次聽到了這個觀點，在 Intercom 工作之後就更加肯定了。如果你不知道你的客戶在做什麼，體驗什麼，思考什麼，你就不是在關注他們。像 Intercom 和 Honeycomb 這樣優秀的工具可以幫助你更好地瞭解你的客戶。
後臺回覆 學習資料 領取學習視頻
![]()
如有收穫，點個在看，誠摯感謝
本文分享自微信公衆號 - 猿天地（cxytiandi）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。