無伺服器計算 - 軟體開發的創新方法
無伺服器是一種軟體開發方法，用於快速構建和部署應用程式，實現鬆散耦合的模組和ofollow,noindex" target="_blank">微服務 。 根據Forrester的說法，“它提供了更好的軟體開發經驗，快速擴充套件構成應用程式的服務，降低成本，並在工作負載變化時提高基礎架構利用率。“
無伺服器 顯然是一個隱喻，就像雲一樣。 計算仍然需要伺服器和其他物理裝置。 自我管理或自主計算 可能是更準確的術語。 無伺服器平臺通常意味著資源供應、容量規劃和其他系統管理決策對開發人員和運營商完全隱藏，計算資源根據需要進行配置，定價基於其實際使用而不是預購容量 。
十年前，雲被視為一種有前途的技術，人們說 “有一個明確的共識：關於雲端計算是什麼卻沒有真正的共識。” 這在當時很明顯，雖然我們正在發生重大而深刻的事情。不完全確定它到底是什麼。 十年之後，那些早期的定義辯論結束了 。 雲現在是公司IT戰略的一個組成部分，其基礎是實施變革的日常工具。
無伺服器與雲端計算密切相關。 所有主要的雲供應商都提供無伺服器技術來動態管理硬體和軟體資源的分配，包括亞馬遜的AWS Lambda ，谷歌的雲功能 ，微軟的Azure功能 和IBM的雲功能 。還有一個開源的無伺服器平臺，Apache OpenWhisk ，IBM的產品以及其他供應商提供的平臺。 Serverless執行環境支援以各種語言開發輕量級應用程式或微服務。
我特別喜歡Mike Roberts 最近關於無伺服器架構 的文章。Roberts認為無伺服器是雲系統的下一個發展方向。就像雲早期的情況一樣，沒有人清楚地看到無伺服器是什麼。它包含兩種不同但重疊的軟體設計方法：後端即服務 （BaaS），它顯著地包含第三方，雲託管的應用程式和服務，例如身份驗證，搜尋，業務服務和資料庫; 和函式即服務 （FaaS）， - 其中包括由應用程式開發人員編寫的自定義程式碼，然後上傳到雲，僅在由特定事件觸發時呼叫，並由雲提供程式完全管理。
所有設計都涉及權衡。我發現將無伺服器方法與傳統的基於伺服器的應用程式進行比較是有用的。 基於伺服器的應用程式往往是長期存在的 。 一旦載入並啟動，應用程式就可以準備好並監聽請求，以便他們可以快速處理它們。 開發人員負責配置 支援其應用程式所需的資源，包括估計其型別和容量，如何在各個元件之間分配資源，以及如何根據應用程式的實際負載進行擴充套件。
雲使這些活動更容易，但仍然必須完成。 必須為雲提供商提供所需的估計資源，以便他們可以自行規劃並有效地支援其各種客戶。 而且，由於資源規劃不是一項精確的活動，開發人員通常會估算出比預期更大的負載，並且無論是在內部還是通過雲提供商，都會過度配置所需的資源。 最近的WSJ CIO期刊文章 指出：
“通過購買更多的雲端計算容量，他們確實需要 - 即使是一種有意識的策略來防止關鍵系統崩潰 - 或購買他們永遠不會使用的高階儲備，所有行業的公司成本可能會平均超支42％，這是根據Densify編制的資料，Densify是一家與全球大公司合作的雲優化公司。 該公司表示，根據雲部署的規模，這可能會導致每年IT預算損失數十萬甚至數百萬美元。其估算基於去年200位雲行業專業人士和70家全球公司的投入。“
無伺服器基於非常不同的資源管理模型。 最大的開銷是應用程式的設計。 無伺服器應用程式由一組鬆散耦合的輕量級模組或微服務 編織或組成。 每個這樣的模組僅在被另一個應用程式模組觸發或由外部函式呼叫時被賦予資源。
無伺服器模組預計執行的時間相對較短，並且通常限制每次呼叫允許執行的時間。 模組完成執行後，其資源將返回到無伺服器平臺，並可供其他需要它們的模組使用。 這些模組是無狀態的 ，意味著在呼叫之間不會傳遞或記住任何資訊。 任何需要在呼叫中保持永續性的資訊都必須明確儲存在單獨的檔案或資料庫中。
鑑於無伺服器應用程式的特殊性，開發人員不再需要計劃、分配或配置模組例項。 一旦模組被呼叫，無伺服器平臺將找出它所需的資源並自動配置它們。 在呼叫其他模組時，平臺將自動為它們分配所需的資源，並在它們執行完畢後將其取出。開發人員只需為其模組實際執行期間使用的資源付費。 如果不經常呼叫，或者只是尖峰呼叫，則無需為簡單資源計劃和支付費用。
“無伺服器架構可能會受益於顯著降低的運營成本，複雜性和工程前置時間，但代價是增加了對供應商依賴性和相對不成熟的支援服務的依賴，”Roberts指出。 雖然在無伺服器方面有很多需要，但他的文章 也指出了一些權衡和缺點。
其中之一是響應請求可能會出現延遲。 與傳統的伺服器應用程式不同， 無伺服器程式碼僅在實際呼叫函式時才例項化。對於某些應用程式， 這種冷啟動 延遲可能是不可接受的。 但是，如果頻繁呼叫該函式，則很可能先前的呼叫仍在進行，並且延遲將顯著縮短。無伺服器供應商鎖定是另一個潛在的缺點。 羅伯茨寫道：“很可能你從一家供應商那裡使用的無伺服器功能將被另一家供應商以不同的方式實現。” “如果您想切換供應商，您幾乎肯定需要更新您的操作工具（部署，監控等），您可能需要更改您的程式碼（例如，以滿足不同的FaaS介面），並且您可能如果競爭廠商的實施行為存在差異，甚至需要改變您的設計或架構。“
測試是另一個潛在的問題。 雖然單元測試無伺服器模組相對簡單，但測試和除錯由許多此類模組組成的無伺服器應用程式非常困難。
“無伺服器不是解決每個問題的正確方法，所以要警惕那些說它將取代所有現有架構的人，”Roberts寫道。 “如果你現在投入無伺服器系統，請小心，特別是在FaaS領域。 雖然有豐富的 - 擴充套件和節省的部署工作 - 需要被掠奪，但也有龍 - 除錯和監控 - 潛伏在下一個角落...“作者：Irving Wladawsky-Berger