在過去的幾年中，構建有彈性的無服務器系統一直是系統管理員和SaaS公司關注的主要問題，因為(據稱)該體系結構提供了優于“傳統”服務器和客戶端模型的幾個關鍵優勢：
無服務器模型不需要用戶維護自己的操作系統，甚至不需要構建與特定操作系統兼容的應用程序。相反，開發人員可以生成通用代碼，然后將其上傳到無服務器框架，并觀察其運行。
無服務器框架上使用的資源通常是按分鐘付費(甚至按秒付費)。這意味著客戶只需為他們實際運行代碼的時間付費。這與傳統的基于云的虛擬機形成了鮮明的對比。
可伸縮性也是一大吸引力。可以動態分配無服務器框架中的資源，這意味著它們能夠應對突然的需求高峰。簡而言之，這意味著無服務器模型應該提供靈活、便宜、可擴展的解決方案。
但是上述架構一直存在下面四個主要缺陷:
1. 有限的編程語言 - 大多數無服務器平臺僅允許您運行以特定語言編寫的應用程序。這嚴重限制了這些系統的敏捷性和適應性。
誠然，大多數無服務器平臺都支持大多數主流語言。AWS Lambda和Azure Functions還提供了包裝器功能，使您可以使用不受支持的語言運行應用程序和功能，盡管這通常會帶來性能成本。因此，對于大多數組織而言，在大多數情況下，此限制不會帶來太大變化。這破壞了無服務器模型的關鍵優勢之一。
2. 供應商鎖定 - 無服務器平臺(或至少目前實現方式)的第二個問題是，在操作級別上很少有平臺彼此相似。在編寫，部署和管理功能的方式上，幾乎沒有跨平臺的標準化，這意味著將功能從一個特定于供應商的平臺遷移到另一個平臺非常耗時。
遷移到無服務器最困難的部分不是計算功能(通常只是代碼片段)，而是應用程序與對象存儲，身份管理和隊列之類的已連接系統糾纏在一起的方式。功能可以移動，但是應用程序的其余部分不那么可移植。這與我們所承諾的廉價，敏捷的平臺相反。
我懷疑有些人會爭辯說，無服務器模型是新的，并且還沒有時間標準化它們的工作方式。但是，正如我上面指出的那樣，它們并不是那么新，而且通過開發和廣泛采用基于社區的強大標準，容器等許多其他云原生技術已經變得更加可用 。
3. 性能難以衡量 - 無服務器平臺的計算性能可能難以衡量，部分原因是出售這些服務的公司對隱藏此信息有既得利益。大多數人會聲稱，在無服務器的遠程平臺上運行的功能將與內部服務器上的運行速度一樣快，除非出現一些不可避免的延遲問題。
然而，軼事證據卻相反。之前未在特定平臺上運行過的功能，或者未在一段時間內運行過的功能需要一些時間來初始化。這可能是因為他們的代碼已經轉移到了一些訪問性更差的存儲介質上，盡管就像它們的性能統計一樣，大多數無服務器計算供應商在這種情況下也不會泄漏。
當然，有許多方法可以解決此問題。一種方法是針對無服務器平臺所運行的任何一種云本機語言優化功能，但這在一定程度上破壞了這些平臺“敏捷”的說法。
另一種方法是確保對性能至關重要的程序安排為頻繁運行，以使它們保持“新鮮”。當然，第二種方法與無服務器平臺更具成本效益的說法有些矛盾，因為您只為程序運行時間付費。云提供商已經引入了減少冷啟動的新方法，但是許多提供商都需要一種“縮放到一個”的模型，這會破壞FaaS的初始價值。
可以通過在內部運行無服務器系統來減少這種“冷啟動”問題，但這本身就產生了成本，對于資源豐富的團隊而言，這仍然是一個利基選擇。
4. 無法運行整個應用程序 - 最后，也許最關鍵的原因就是為什么無服務器架構不會在短期內取代傳統模型：(通常)您無法在serverless系統上運行整個應用程序。
或更確切地說，您可以，但是這樣做并不劃算。成功的整體應用程序可能不應成為連接到八個網關，四十個隊列和一打數據庫實例的四打功能的系列。因此，無服務器適合于未開發的領域。幾乎沒有現有的應用程序(體系結構)移植過來。因此，您可以遷移，但期望從零開始。
這意味著，在大多數情況下，無服務器平臺將用作內部服務器的附件，以執行需要大量計算資源的任務。這使得它們與云原生技術的其他兩種形式(容器和虛擬機)確實有很大不同，兩者都提供了執行遠程計算的整體方法。這說明了從微服務過渡到無服務器的困難之一 。
當然，這不一定是問題。在許多組織中，偶爾使用大量計算資源而無需支付內部實現此功能所需的硬件的能力可能會帶來真正而持久的好處。但是，管理應用程序的運行方式(其中部分運行在內部服務器上，其他部分運行在無服務器云架構上)可能會給這些應用程序的部署帶來更高的復雜性。
京公網安備 11010502049343號