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