函式不是重點

如果你因為喜歡 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 狀態。