Serverless 是一種思想狀態

來源 | Serverless 公衆號；做者 | Ben Kehoe；譯者 | donghui

函數不是重點

若是你由於喜歡 Lambda 而選擇 Serverless，你這樣作的緣由是錯誤的。若是你選擇 Serverless，是由於你喜歡 FaaS，你這樣作的緣由也是錯誤的。函數不是重點。

固然，我喜歡 Lambda ——但這不是我提倡 Serverless 的緣由。

不要誤解我，函數很好。它們讓你透明地伸縮，你沒必要管理運行時，並且它們自然地適合事件驅動的架構。這些都是很是有用的特性。

可是函數最終應該成爲整個解決方案的一小部分。你應該使用包含業務邏輯的函數做爲託管服務之間的粘合劑，這些託管服務提供了構成應用程序的大部分繁重工做。

託管服務不是重點

咱們很幸運，雲提供商可以爲應用程序的許多不一樣部分提供如此普遍的託管服務。數據庫、身份和訪問管理（真高興我不用本身擁有它！）、分析、機器學習、內容分發、消息隊列等各類不一樣模式。

託管服務以較少的麻煩提供你所需的功能。你沒必要給他們運行的服務器打補丁。你沒必要確保自動縮放在沒有大量空閒容量的狀況下正確地提供所需的吞吐量。

託管服務顯著下降了你的運維負擔。託管服務很棒——但……它們不是重點。

運維不是重點

很高興知道你能夠應用更少的運維資源來保持應用程序的健康。尤爲重要的是，你所須要的資源主要是根據你所提供的函數數量而不是流量來伸縮的。

減小運維、效率更高——但……這不是重點。 

成本不是重點

好吧，有時候企業但願你作的只是下降成本——而這正是你所關心的。Serverless 會幫助你作到這一點。但總的來講，雲計算帳單並非問題的重點。

你的雲帳單只是雲應用程序總成本的一個組成部分。首先，是運維人員的薪水——若是你的運維人員資源更少的話，成本會更低。還有你的開發成本。

這裏有不少成本優點——但……這些都不是重點。 

代碼不是重點

代碼不只不是重點，並且是一種責任。代碼最多隻能作你想作的事情。Bug 會削弱這一點。你只會由於編寫更多的代碼而失去重點。你擁有的代碼越多，偏離你預期價值的機會就越多。理解這是一種文化轉變。

技術一直以來都很困難。聰明的人經過技術創造價值。因此開發者開始相信聰明是與生俱來的，是好的。咱們花了這麼長時間來製造瑞士手錶，以致於沒有意識到石英卡西歐的出現，並指責這種演變缺少優雅。

咱們須要理解並解決業務問題，而不是將咱們的聰明才智用於解決技術問題。當你必須編碼時，你是在解決技術問題。 

技術不是重點

咱們這樣作的緣由，是爲了達到某種商業目標。你的組織試圖創造的業務價值就是重點。

如今，有時候，你賣的是技術。但即便你的產品是技術，那也可能不是你銷售的產品的價值所在。

有句老話說，人們買的不是鑽子，而是洞。當你須要在牆上鑽個洞時，你不會在意鑽得有多漂亮，你只在意鑽得有多好就能鑽出你須要的洞。

在 iRobot，咱們不賣機器人。咱們甚至都不賣吸塵器。咱們賣清潔房屋。Roomba 讓你有時間回到你的平常生活中去關注對你來講重要的事情。因此，若是技術不是重點，咱們在這裏是爲了什麼?

重點是專一

Serverless 是一種專一於業務價值的方法。

函數如何幫助你交付價值？它們讓你將重點放在編寫業務邏輯上，而不是爲業務邏輯編寫支持的基礎設施。

託管服務讓你能夠專一於編寫函數。較少的運維資源能夠騰出人力和資金，爲客戶創造新的價值。

可觀察性爲你提供了處理 MTBF 和 MTTR 的工具，這兩種工具均可以度量你的客戶得到價值的頻率。在雲計算上花更少的錢意味着你能夠更直接地把錢花在支持創造價值上。 

專一是選擇 Serverless 的緣由

你應該選擇 Serverless，由於你想專一於創造價值——在你的公司，你努力應用技術來創造商業價值。

回到成本上，Lyft 的 AWS 帳單，每一年1億美圓，最近已經成爲新聞。許多人插話說他們能夠作得更便宜——他們不能，但這不是重點。

若是 Lyft 切換到 Lambda 並儘量地託管服務，他們的帳單會更低嗎?可能。但當他們花時間從新架構時，這會有什麼用呢?他們會失重點。

公司正處於發展比成本控制更重要的階段。最終，這種狀況可能會改變。上市公司對股東負責，所以下降成本能夠爲他們帶來價值。可是對於如今的 Lyft 來講，爲他們的客戶提供價值意味着執行他們當前的應用程序和流程。他們正在作一個 Serverless 的選擇。

我要告訴你的是，Serverless 從未涉及到咱們稱之爲 Serverless 的技術。那麼咱們所謂的 Serverless 技術和它有什麼關係呢?

Serverless 是專一業務價值的結果

技術是你如何交付價值的結果。開發團隊和運維團隊傳統上是分開的，由於他們有不一樣的專一點。但咱們看到這一趨勢正在改變。

傳統的模式把重點放在技術上——開發技術 vs 運維技術。可是咱們看到人們意識到重點應該放在價值上——交付的功能，包括如何構建和運行。

當咱們採用這種關注業務價值的概念，並運行其邏輯結論時，咱們獲得 Serverless。

當你想要專一於交付價值時，你想要編寫函數。當函數須要狀態時，須要一個數據庫。要從別人那裏得到它，你可使用 DBaaS——你能夠根據它讓你專一的程度來在你的選項之間進行選擇。

在選擇託管服務時，其中一些甚至多是面向用戶的。若是你可使用社交帳戶登陸而不是擁有本身的帳戶，那你就少了一件須要管理的事情，也少了你擁有的對用戶體驗的籌碼。

如今，對於你所外包的一切，你仍然有責任。你的用戶並不關心他們的糟糕體驗是由第三方形成的，這仍然是你的問題。你須要將中斷留給你的用戶，同時接受你不能徹底控制你在那裏的命運。這是一個不舒服的地方，但它是值得的。

在這些事情上你不能贏得分數——但你能夠失去。這意味着你須要知道「壞」是什麼樣子。這就要求你對外包的產品和技術有足夠的瞭解，以確保你爲用戶提供了足夠的質量。

請注意，在一個重點領域有深刻的專業知識，而在相鄰領域有普遍但薄弱的知識，這與 T 型技能的概念很是類似——適用於組織和團隊。 

Serverless 是一種特質

Serverless 是公司的一個特質。若是一個公司決定它不該該擁有不是實現其商業價值的核心技術，那麼它就是 Serverless 的。不多有公司是徹底 Serverless 的。可是在公司內部，仍然能夠有 Serverless 的部分。

若是你的團隊決定只關注它所傳遞的價值，並將任何超出這些價值的東西委託給另外一個團隊，或者理想狀況下委託給外部——那麼你的團隊就會變得 Serverless。你不能老是選擇使用外部技術——這很好，你仍然能夠在有限的條件下作出最好的選擇。

在一個足夠大的組織中，它就再也不重要了。當 Amazon.com 使用 Lambda 時，它是徹底 Serverless 的，儘管它在某種意義上是 on-prem 的。但若是隻有你一我的呢?

若是你對 Serverless 感到興奮，但在公司裏感到徹底孤獨怎麼辦?若是你與實際的商業價值相去甚遠——若是你爲一個服務於建立面向用戶內容的團隊的團隊打補丁，那該怎麼辦?我想說服你，你今天能夠在任何狀況下變得 Serverless。

Serverless 是方向，而不是終點

我曾經把 Serverless 技術做爲一個光譜來討論，由於我知道沒有一條清晰的線來區分 Serverless 技術和非 Serverless 技術。個人意思是，幾乎沒有一條明亮的線來分隔任何給定的分組，因此我在這個假設中我是很安全的。

我講過像 Kinesis 這樣須要管理碎片的東西，它是 Serverless 的，但比 SQS 少一些 Serverless。你沒必要使用 RDS 修補實例，但須要選擇實例類型和數量。這些技術都是不一樣程度的 Serverless。

但最近我開始意識到將 Serverless 描述爲光譜的一個問題是，它並不意味着移動。僅僅由於你使用的是某種指定爲 Serverless 的產品，並不意味着你應該感到本身已經得到了 Serverless -繼續使用它並認爲你已經選中了 Serverless 複選框是能夠接受的。 

爬上 Serverless 階梯

我開始把 Serverless 想象成一個***。你正在攀登某種必殺技，在那裏你能夠在沒有開銷的狀況下交付純業務價值。但階梯上的每一個梯級都是有效的 Serverless 步驟。

若是你從 on-prem 移動到公共雲，那是階梯。若是你從虛擬機遷移到容器，那簡直就是天梯。若是你從沒有容器編排或自定義編排遷移到 Kubernetes，這是階梯。若是你從長期運行的服務器轉移到自託管的 FaaS，那將是天梯。但總有一個梯級在你之上，你應該始終保持攀登。 

"階梯"沒有傳達的一件事是它不是線性的。從虛擬機遷移到容器再到 Kubernetes 都是在梯級上的階梯，可是將虛擬機從本地遷移到雲也是如此。在這些狀況下，一般沒有一個明確的「更好」。

我想到了通往山頂的許多路徑的比喻，但我喜歡***的一點是它能夠是無限的。沒有最終狀態。我喜歡 Lambda，但我一直在尋找更好的方式來交付代碼，使我更關注價值。

Serverless 是一種思想狀態

Serverless 是關於你如何決策的問題，而不是你的選擇。每一個決定都是有約束的。可是，若是你知道正確的方向，即便你不能以這種方式直接移動，也能夠選擇最緊密結合的選擇，而後再向上移動另外一個梯級。那麼，你如何採用這種思惟方式？你如何作出 Serverless 選擇？

配置是你的朋友

我認爲許多開發人員看不起配置，認爲它「不是真正的編程」。如今有一種對編程的盲目崇拜。咱們被告知「軟件正在吞噬世界」，而咱們卻不許確地將其翻譯成「編碼正在吞噬世界」。

咱們已經相信，開發人員是組織中惟一重要的人，而咱們的生產力意識是惟一重要的事情。咱們想在區域中感覺到，這就是編碼所提供的。這方面的任何障礙都對企業不利。咱們對進入該區域是否真的比替代路線更快，更好地創造價值沒有任何感受。 

切記：數天的編程能夠節省數小時的配置

約束是好的。刪除選項能夠幫助你保持專一。顯然，並非全部的約束都是好的——可是通常來講，作通常事情的能力是以花費更長的時間來作一件特定的事情爲代價的。護欄可能會磨損，但你會比一直盯着護欄邊緣跑得快。

這樣，Serverless是關於極簡主義的。消除干擾。Marie Kondo 如今很大，而且一樣的建議也適用。查找你的堆棧中不會產生價值的組件。 

懼怕可能發生的巨大事件

可能性蘊含着隱藏的複雜性。對於任何技術，個人主要評估指標之一是它有多少能力超出手頭的任務。當有不少額外的空間時，就會處理和學習沒必要要的複雜性。

人們把 Kubernetes 吹捧爲一個單一的工具來完成每個雲需求——它確實能夠！但若是一切皆有可能，一切皆有可能。對於一個給定的任務，Kubernetes 可能會出錯，由於你沒有考慮它在與該任務無關的狀況下的行爲方式。

另外一方面，當你考慮 Serverless 的服務時，你可能必須在主要提供商提供的80%的解決方案或第三方提供商提供的更適合你需求的服務之間作出選擇。可是該新提供商的運維需求是什麼？身份驗證是什麼樣的？這些是隱藏的複雜性，你須要引入這些特性，你須要權衡這些特性差別。 

接受不擁有本身命運的不適感

當你使用託管服務時，提供者中斷會帶來壓力。你沒法解決他們的問題。這是沒法迴避的——這老是讓人感受很糟糕。你可能會想，「若是我運行本身的 Kafka 集羣而不是使用 Kinesis，我就能夠找到問題並解決它」。這多是真的，但你應該記住兩件事：

• 那會分散人們對創造商業價值的注意力。
• 你幾乎確定會在運行它方面作得更差。你會遇到更多更糟糕的事情。服務提供商的人生目標就是擅長於此——他們有規模經濟，而你沒有。

超越「我老是能夠本身創建它」的態度可能很難。Jared Short 最近爲選擇技術提供了一套出色的指導方針。
_
這些天來我對無服務器的思考是按考慮順序進行的。–若是平臺擁有，請使用–若是市場擁有，請購買–若是你能夠從新考慮需求，請執行–若是必須構建，請擁有。——@ShortJared

所以，若是你使用的是雲平臺，請儘量留在生態系統中。這樣，你就能夠從方程式中消除不少可能性。可是，若是沒法在平臺上得到所需的東西，請從其餘地方購買。

若是你不能徹底購買所需的東西，你是否能夠從新考慮本身在作什麼以適應你能夠購買的東西？這一點真的很重要。它到達了上市時間的核心。

若是你有一些你認爲有價值的東西，你會想要儘快運送。但更快地運送一些東西，總比精確地構建好，由於你還不知道這是否是正確的東西。

等待構建出正確的東西不只會花費更長的時間，並且後續的迭代也會更慢——而且對其進行維護將佔用你未來可用於運送更多東西的資源。即便在該技術不是 Serverless 的狀況下，這也適用：始終詢問對你的要求的調整是否能夠實現更快，更好或更專一的價值交付。

可是，最後，若是必須構建它，請擁有它。尋找一種使其不同凡響的方法。如今，這並不意味着你已經構建的全部內容都應該變成差別化的。在完美的世界裏只看你買不到的東西。想象一下徹底 Serverless 的綠地實現會是什麼樣子，並找到須要在那裏構建的內容。 

找到你的業務價值部分

所以，從根本上講，你但願找到你的業務價值部分。你所服務的技術工做是什麼？也許你與面向用戶的產品相去甚遠。你可能只貢獻了一小部分。但它在那裏，你能夠找到它-並專一於這一價值。

從你爲組織中其餘人提供的直接價值開始，並專一於此。而後開始追蹤價值鏈。確保全部決策都圍繞你所創造的價值。作出 Serverless 的選擇。

僱用能夠自動完成工做的人員，而後繼續爲他們提供工做。——@jessfraz

我喜歡 Jessie Frazelle 的話。你能夠把它轉過來：自動化完成工做，繼續作有要求的工做。

請記住，你不是工具。對於你要建立的任何價值，請自動化建立。若是你管理構建服務器，請找到使它們成爲自助服務的方法，所以你交付的不是構建自己，而是構建工具，以便團隊能夠本身交付構建。 

總結：Serverless 是一種思想狀態

重點不是函數，託管服務，運維，成本，代碼或技術。重點是專一——這就是選擇 Serverless 的緣由。

Serverless 是專一業務價值的結果。這是一個特質。這是方向，而不是終點。爬上永無止境的 Serverless 階梯。

配置是你的朋友。數天的編程時間能夠節省數小時的配置時間。懼怕可能發生的巨大事件。接受不擁有本身命運的不適感。

找到你的業務價值部分，並實現 Serverless 狀態。 

英文原文連接：https://read.acloud.guru/serverless-is-a-state-of-mind-717ef2088b42