2018年關於無伺服器含義的幾個觀點 - Subbu的部落格

banq發表於2018-12-31
伺服器

我們需要幾乎瞬時的資源彈性，而不必預先分配資源或支付超出需要的資源。我們還希望將所有執行最佳實踐融入執行時，以免我們擔心程式碼執行得幾乎是低階自動化，低操作性和低健壯性，這是近十年來雲端計算最基本的兩項追求，無伺服器是實現這些機遇的最接近的。

然而，當我回顧2018年時，我發現在訊息，價值和方向等方面：有許多框架可供使用，出版了大量書籍，並在全球範圍內就此主題召開了多次會議，這些其實無關緊要，更重要的是，企業是否會持續採用，我們慢慢會意識到好處。

阻礙我們的可能是我們的心智模型和無伺服器的觀點。正如最近的一篇論文“ 無伺服器計算：前進一步，後退兩步 ”所指出的那樣，“無伺服器計算的概念足夠模糊，允許樂觀主義者對它可能意味著什麼進行任何可能的廣泛解釋。”我不得不表示同意。

在這篇文章中，我想總結三個當代關於無伺服器的觀點，以及這些觀點的含義。我的目標是表明我們的觀點決定了結果，除非我們改進觀點，否則我們可能找不到更好的未來。

1.像其他人一樣管理伺服器
在此視角中，無伺服器功能將運營職責轉移到提供者，因此，作為無伺服器功能的使用者，您不必考慮管理伺服器。因此，伺服器配置，作業系統升級，維護，容量管理等所有相關職責從消費者轉移到能力提供者。據認為，這種觀點可以讓您免於思考“運營”並讓您專注於您的程式碼。
在極端情況下，您可以擴充套件此檢視以將其他人執行的任何服務歸類為無伺服器。在這裡，我使用維基百科對服務的定義為“可以遠端訪問並獨立操作和更新的獨立功能單元”。Kelsey Hightower的推文下面的幻燈片舉例說明了無伺服器作為運營結構的這一觀點。在撰寫本文時，我不知道這張幻燈片的原作者。
如果無伺服器是一個可操作的構造，這是否意味著我的本地堆疊也可以是無伺服器的，只要其他人而不是我做所有的操作即可？ -  @kelseyhightower
根據這種觀點，任何雲服務都有資格成為“無伺服器”。您可以根據獲得靈活性，彈性和成本效率的難易程度，透過其“無伺服器程度”對每項服務進行評級。服務越容易獲得這些品質，能力就越“無服務”。這就是你在上面的幻燈片中從左到右看到的內容。
在描述“後端即服務”（BaaS）時，CNCF的無伺服器工作組也屬於這種觀點。
後端即服務（BaaS），它是第三方基於API的服務，可替代應用程式中的核心功能子集。因為這些API是作為一種自動擴充套件和透明操作的服務提供的，所以開發人員認為這是無伺服器的。

BaaS是描述多租戶中介軟體服務的行話。
這種觀點的一個關鍵限制是它讓你專注於將後端重活外包給提供者，卻忽略了無伺服器的關鍵屬性，這就是無伺服器還包括一個程式設計和執行時環境，讓你編寫和執行你的碼。

例如，比較亞馬遜的S3和Lambda。兩者都是多租戶，彈性，自動配置，按使用付費的服務，雖然前一個為您提供儲存物件的API，而另一個為您提供一個自以為是的程式設計框架和執行時編寫和執行您的程式碼。

此檢視還支援像AWS這樣的雲提供商執行許多託管服務，就像您在上面的幻燈片中看到的那樣，但不支援當今存在的可移植開源無伺服器框架。大多數開源和第三方無伺服器解決方案都要求您自行配置一些資源並對其進行管理。例如，在Kubernetes上執行OpenFaaS或Kubeless等框架並不是[url=https://kubeless.io/]無視[/url]伺服器，因為您仍需要配置，管理，升級和保護Kubernetes叢集。

2.無伺服器作為函式和事件的視角
從這個角度來看，無伺服器是一種程式設計模型，為宣告性配置觸發事件的小程式碼函式單元組成。微服務的概念匹配其邏輯極限。在此檢視中，函式和事件是面向開發人員的編寫應用程式的抽象。
此視角完全側重於面向開發人員的抽象，根據這種觀點，任何使用函式和事件作為抽象的框架都是無伺服器的。時候操作執行時所需的資源無關緊要。
我聽說其他基於Kubernetes的函式框架的支持者表達了類似的觀點。由於這種視角不關注誰執行伺服器，它為幾個開源專案提供了最廣泛的保護，以提供創新和有趣的功能和基於事件的程式設計框架。
雖然開發人員的經驗非常重要，但這種觀點忽視了諸如彈性，成本效率和降低運營開銷等屬性。您可能還想知道這個視角是否只是AWS Lambda的逆向工程，無需成本和運營效率即可重新建立開發人員體驗。

3.無伺服器作為服務功能（FaaS）的視角
這種視角是最常用的無伺服器檢視，描述了2014年AWS Lambda最初提供的內容，現在又有一些其他雲提供商。它結合了函式和基於事件的無狀態程式設計模型，以及作為服務提供的執行時。此外，您還可以訪問用於中介軟體功能的豐富雲服務。

雖然這種觀點很好地服務於某些無狀態的應用程式模式，但它也使我們無法超越函式和事件。我們無法以鬆散耦合的無狀態短暫事件觸發函式的形式表達世界上今天和明天的程式設計問題。

沒有其他工作能夠比最近釋出的加州大學伯克利分校論文“ 無伺服器計算：前進一步，後退兩步 ”更好地描述這種鴿子的後果。以下是該文的一些示例亮點。

  • 對於模型訓練問題：“Lambda的有限資源和資料傳輸架構意味著在Lambda上執行此演算法比在EC2上執行慢21倍，並且價格高出7.3倍。”
  • 對於透過批處理問題提供的低延遲預測：“這個”伺服器“版本（分別用EC2和ZeroMQ替換Lambda和SQS）的每批延遲為2.8ms - 比最佳化的Lambda實現快127倍。”括號是我加上的。
  • 對於分散式計算問題：“在（無法實現的）最佳情況下 - 當每個領導者在加入系統後立即當選時 - 系統將僅在領導者選舉協議中花費1.9％的總時間。即使您認為這是可以忍受的，請注意使用DynamoDB作為細粒度的通訊介質是非常昂貴的：支援1,000個節點的叢集成本至少每小時450美元。“

還有其他幾個未記錄的例子。例如，我不會將許多Apache Spark驅動的大規模資料處理解決方案歸入事件觸發函式。
雲原生的託管服務可以填補解決此類問題的空白，同時仍然提供無伺服器的彈性，成本和運營效率。我過去曾提出這樣的論點，但我認識到等待這些發展只會扼殺實驗和創新。

接下來是什麼？
這些觀點在哪裡引導我們？離我們今天不遠的地方。
雖然我無法寫出具體數字，很可能不到當今全球計算容量的1％的幾分之一用於執行無伺服器工作負載。因此無伺服器的機會幾乎是無限的，很明顯，今天對無伺服器的看法不會讓我們為大多數程式設計問題提供近乎瞬時的彈性，成本和運營效率。假設我們擁有解決所有當前和未來程式設計問題所需的所有無伺服器原語是愚蠢的。
然而，我對未來充滿希望。我也期待著我們承認事件觸發函式作為面向抽象的主要開發人員只是幾種可能性之一，我們需要新型別的框架作為服務來解決其他型別的問題。
明天的無伺服器產品很可能是“作為服務的框架”，“函式即服務”只是解決某類無狀態程式設計問題的一種可能性。

相關文章