關鍵點
- 幾年來，我們一直被承諾無伺服器運算將迎來一個無需特定作業系統來運行應用程式的新時代。 我們被告知這種結構將解決許多可擴展性問題。 事實上，一切都不一樣了。
- 雖然許多人將無伺服器視為一個新想法，但其根源可以追溯到 2006 年 Zimki PaaS 和 Google App Engine 的出現，這兩者都使用無伺服器架構。
- 無伺服器革命停滯不前有四個原因，從有限的程式語言支援到效能問題。
- 無伺服器運算並非毫無用處。 一點也不。 但是，不應將它們視為伺服器的直接替代品。 對於某些應用程序，它們可以是一個方便的工具。
伺服器死了，伺服器萬歲！
這是無伺服器革命的戰鬥口號。 只要快速瀏覽一下過去幾年的產業新聞，就很容易得出這樣的結論：傳統的伺服器模型已經消亡，幾年內我們都將使用無伺服器架構。
正如業內人士所知，正如我們在有關的文章中也指出的那樣 ，這是錯誤的。 儘管有許多關於其優點的文章 ，它從未發生過。 實際上， 這場革命可能已經走進了死胡同。
無伺服器模型的一些承諾確實已經實現，但並非全部。 不是每個人。
在這篇文章中，我想看看造成這種情況的原因。 為什麼無伺服器模型缺乏靈活性仍然是其廣泛採用的障礙，儘管它們在特定的、明確定義的環境中仍然有用。
無伺服器運算專家的承諾
在我們討論無伺服器運算的挑戰之前，讓我們先看看它應該提供什麼。 人數眾多，而且有時非常雄心勃勃。
對於那些不熟悉該術語的人，這裡有一個快速定義。 無伺服器運算定義了一種架構，其中應用程式（或應用程式的一部分）在通常遠端託管的執行時間環境中按需運行。 此外，無伺服器系統可以在家中託管。 在過去的幾年裡，建立彈性無伺服器系統一直是系統管理員和 SaaS 公司的主要關注點，因為（據稱）這種架構比「傳統」客戶端-伺服器模型提供了幾個關鍵優勢：
- 無伺服器模型不需要使用者維護自己的作業系統，甚至不需要建立與特定作業系統相容的應用程式。 相反，開發人員創建共享程式碼，將其上傳到無伺服器平台，然後觀察其運行。
- 無伺服器框架中的資源通常按分鐘（甚至秒）計費。 這意味著客戶只需為實際運行程式碼的時間付費。 這與傳統的雲端虛擬機相比毫不遜色，傳統的雲端虛擬機大部分時間都是閒置的，但你必須為此付費。
- 可擴展性問題也解決了。 Serverless框架中的資源是動態分配的，因此系統可以輕鬆應對突然激增的需求。
簡而言之，無伺服器模型提供了靈活、低成本、可擴展的解決方案。 令人驚訝的是我們沒有更早想到這個想法。
這真的是新想法嗎？
事實上，這個想法並不新鮮。 允許使用者只為程式碼實際運行的時間付費的概念自從由 2006 年，大約在同一時間，Google App Engine 提供了一個非常相似的解決方案。
事實上，我們現在所說的「無伺服器」模型比許多現在稱為「雲端原生」的技術更古老，這些技術提供了大致相同的功能。 如前所述，無伺服器模型本質上只是已經存在了數十年的 SaaS 業務模型的延伸。
還值得認識到的是，無伺服器不是 FaaS 架構，儘管兩者之間存在聯繫。 FaaS 本質上是無伺服器架構中以運算為中心的部分，但它並不代表整個系統。
那麼有什麼好大驚小怪的呢？ 那麼，隨著發展中國家的網路普及率不斷飆升，對運算資源的需求也同時增加。 例如，許多電子商務行業快速成長的國家根本不具備用於這些平台上的應用程式的運算基礎設施。 這就是付費無伺服器平台的用武之地。
無伺服器模型的問題
問題是無伺服器模型存在......問題。 不要誤會我的意思：我並不是說它們本身不好或在某些情況下不能為某些公司提供重大價值。 但「革命」的主要主張——無伺服器架構將迅速取代傳統架構——從未實現。
這就是為什麼。
對程式語言的支援有限
大多數無伺服器平台僅允許您執行以某些語言編寫的應用程式。 這嚴重限制了這些系統的靈活性和適應性。
無伺服器平台被認為支援大多數主要語言。 AWS Lambda 和 Azure Functions 還提供了一個包裝器，以不受支援的語言執行應用程式和函數，儘管這通常會帶來效能成本。 因此對於大多數組織來說，這種限制通常不是什麼大問題。 但事情是這樣的。 無伺服器模型的好處之一應該是鮮為人知、很少使用的程式可以更便宜地使用，因為您只需為它們運行的時間付費。 鮮為人知、很少使用的程式通常是用...鮮為人知、很少使用的程式語言編寫的。
這破壞了無伺服器模型的主要優勢之一。
供應商綁定
無伺服器平台的第二個問題，或至少是它們目前的實現方式，是它們在操作層面通常彼此不相似。 在編寫功能、部署和管理方面實際上沒有標準化。 這意味著將功能從一個平台遷移到另一個平台非常耗時。
遷移到無伺服器模型最困難的部分不是計算功能（通常只是程式碼片段），而是應用程式如何與物件儲存、身分管理和佇列等連接系統進行通訊。 功能可以移動，但應用程式的其餘部分不能移動。 這與承諾的廉價且靈活的平台恰恰相反。
有些人認為無伺服器模型是新的，還沒有時間標準化它們的工作方式。 但正如我上面提到的，它們並不是那麼新鮮，而且由於良好標準的開發和廣泛採用，許多其他雲端技術（例如容器）已經變得更加可用。
Производительность
無伺服器平台的運算效能難以衡量，部分原因是供應商傾向於將資訊保密。 大多數人認為，遠端無伺服器平台上的功能與內部伺服器上的功能運行速度一樣快，除了一些不可避免的延遲問題。
然而，個別事實顯示事實恰恰相反。 以前未在特定平台上運行或一段時間未運行的功能將需要一些時間來初始化。 這可能是由於他們的程式碼已移植到一些難以存取的儲存介質，儘管與基準測試一樣，大多數供應商不會告訴您有關資料遷移的資訊。
當然，有幾種方法可以解決這個問題。 一是針對無伺服器平台運行的任何雲端語言最佳化功能，但這在某種程度上削弱了這些平台「敏捷」的主張。
另一種方法是確保定期運行對生產力至關重要的程式以保持新鮮感。 當然，第二種方法與無伺服器平台更具成本效益的說法有點矛盾，因為您只需為程式運行的時間付費。 雲端供應商推出了減少冷啟動的新方法，但其中許多方法需要“規模化到一”，這破壞了 FaaS 的原始價值。
冷啟動問題可以透過在內部運行無伺服器系統來部分解決，但這會帶來一定的成本，並且對於資源充足的團隊來說仍然是一個利基選擇。
您無法運行整個應用程式
最後，也許無伺服器架構不會很快取代傳統模型的最重要原因：它們（通常）無法運行整個應用程式。
更準確地說，從成本角度來看這是不切實際的。 您成功的整體應用程式可能不應該變成由八個網關、四十個佇列和十幾個資料庫實例連接的四打功能的集合。 因此，無伺服器更適合新的發展。 幾乎沒有現有的應用程式（架構）可以遷移。 您可以遷移，但必須從頭開始。
這意味著在絕大多數情況下，無伺服器平台被用作後端伺服器的補充來執行運算密集型任務。 這使得它們與其他兩種形式的雲端技術（容器和虛擬機器）非常不同，後者提供了執行遠端運算的整體方法。 這說明了從微服務轉向無伺服器的挑戰之一。
當然，這並不總是一個問題。 無需購買自己的硬體即可定期利用大量運算資源的能力可以為許多組織帶來真正、持久的好處。 但是，當某些應用程式駐留在內部伺服器上，而其他應用程式駐留在無伺服器雲端架構上時，管理就會變得更加複雜。
革命萬歲？
儘管有這些抱怨，我並不反對無伺服器解決方案本身。 誠實地。 開發人員只需要了解（尤其是如果他們是第一次探索無伺服器）該技術並不能直接取代伺服器。 相反，請查看我們的提示和資源 並決定如何最好地應用該模型。
來源： www.habr.com