“這是愚蠢的。 比愚蠢還糟：這是一場營銷炒作。”
‐ 理查德·斯托曼 （ Richard Stallman）對云計算的評論，2008年9月

而且，十年后，當有人提到這個詞時，您開始三思而后行：是到天上掉的東西，還是到2020年預計將占全球83％的企業工作負載的那件事？

無論您是否喜歡，另一場革命正在進行中。 AWS處于領先地位，緊隨其后的是MS Azure和GCP，它們都懷有一個共同的目標：

解除對基礎軟件的束縛。

無服務器。

FaaS。

DevOps的死亡。

隨便你

無論名稱如何（為方便起見，我們將野獸稱為“無服務器”），這種新范例已經在重塑軟件領域中發揮了作用。 我們已經看到像可口可樂這樣的巨頭在其生產堆棧中采用了無服務器組件， 而無服務器這樣的框架則獲得了數百萬美元的資金。 但是，我們應該記住，無服務器并不適合每個人，任何地方，每次都適用-至少到目前為止還不是。

服務器（較少）=狀態（較少）

作為常規程序員，我看到的無服務器最大的“障礙”是“無狀態”。 早先我可以肯定的是，我將復雜的計算結果存儲在內存中。 或我提取到/tmp的相當大的元數據文件； 或我剛剛產生的輔助子進程； 一旦我的程序恢復控制，仍然會在那里，無服務器幾乎打破了所有這些假設。 盡管像lambda這樣的實現往往會保留狀態一段時間 ，但總的約定是，應用程序應該能夠拋棄所有希望，并可以從零開始優雅地啟動，以防被干凈的表盤調用。 不再有內存中狀態：如果要保存，則保存。 你不，你輸。

從另一個角度考慮，這也可能被認為是無服務器的（意外）巨大優勢之一。 因為瞬態（通過“服務器化”架構僅使存在成為可能）是大多數（即使不是全部）邪惡的根源。 現在，通過設計，您可以減少犯錯誤的空間-這可能是一個公平的權衡，尤其是對于像我這樣臭名昭著的程序員而言，它們通過內存狀態管理尋求（通常為時過早）優化。

但是，我們不應忘記由于內存中狀態管理和緩存容量的減少而導致的性能損失； 您的狀態管理器（數據存儲）原先只有數個“電路躍點” ，現在卻要相隔數個網絡躍點，從而導致數毫秒（甚至數秒）的延遲，以及更多的故障空間。

次秒計費

如果您在過去的十年中還活著，那么您會看到它的來臨：一切都逐漸變成按需付費的模式。 現在，它的長度已到了以0.1秒的執行間隔對lambda進行收費的程度，并且量化將繼續進行。 對于持久負載而言，這可能并不意味著很多優勢，有時甚至可能意味著劣勢 ，但由于負載差異較大的應用程序不必始終準備并為其預期的峰值負載付費，因此可以獲得巨大的優勢。 更不用說具有稀疏負載配置文件的事件驅動和批處理系統，這些系統可能節省一個數量級，特別是當它們是小型的且在地理位置上受限時。

此外，新的按資源付費使用模型（考慮到時間（或者說執行時間），也是一種非常有價值的資源）鼓勵了面向性能的編程，這確實是一個好兆頭。 FaaS提供商通常使用復合計費指標，將執行時間與內存分配等相結合，進一步加強了均衡優化的動力，最終產生了更好的資源利用率，更少的浪費以及由此帶來的財務和環境效益。

看不見的紅外線

代替物理硬件，虛擬化（以后）或容器化（以后）操作系統環境，現在您只能看到一個過程：實際上是一個功能或工作單元。 乍一看聽起來不錯（不再進行基礎設施/硬件/操作系統/支持實用程序的監視或維護-希望無服務器提供商會為我們提供幫助！），但這在靈活性方面也意味著巨大的挫折：即使在在容器的日子里，我們至少可以靈活地選擇自己喜歡的基本操作系統（盡管仍綁定到底層內核），而現在我們所擁有的只是編程語言的選擇（有時是其版本）。 但是，那些經歷了devop頭痛的人肯定會同意后者是一個非常合理的權衡。

加強隔離

由于您不再具有訪問現實世界的權限（通常來說，這是一個短暫的容器化過程），因此出錯的空間更少（不可避免的，因為實際上您可以做的事情更少！）。 即使您受到損害，您的短命和有限的特權也可以防止進一步的污染，除非該漏洞利用足夠強大以至于影響基本的業務流程框架 。 隨之而來的是，不幸的是，如果發現了這樣的漏洞，則由于基于lambda的惡意軟件主機將比以往具有更大的可伸縮性，因此可以被大量利用。

大多數提供商故意限制lambda嘗試進行惡意活動，例如發送垃圾郵件 ，合法用戶對此會不以為然，但遭到了垃圾郵件的困擾（想象每月有數百萬lambda運行時數量激增，AWS已經提供了100萬次免費調用， 320萬秒的執行時間 -向一組用戶發送垃圾郵件；十二個免費的AWS訂閱將使攻擊者獲得巨大的優勢！）

供應商鎖定：有副作用嗎？

這是每個云平臺（或者如果您仔細考慮的話） 任何平臺，實用程序或服務的固有問題。 一旦您決定利用平臺的“酷”或“高級”功能，便可以有效地與之耦合。 對于無服務器平臺而言，這比以往任何時候都更加真實：除了語言構造之外，幾乎所有其他一切都是特定于提供程序的，并且嘗試編寫“通用”功能最終會以難以理解的復雜方式被大量黑客和重新發明的輪子所包圍。 ，或者很可能什么都沒有。

從某種意義上說，這是必不可少且不可避免的回報。 如果必須要特別，就必須要具體！ 諸如Serverless之類的框架正在積極嘗試解決這一問題，但是，按照一般的觀點 ，通用解決方案仍然遙不可及。

擁有權利的同時也被賦予了重大的責任

鑒于無服務器應用程序的簡單性，多功能性和可伸縮性，它們對于公司的IT基礎設施而言可以成為寶貴的資產； 但是，如果設計，部署，管理和監控不當，則無論從架構復雜性還是在財務方面，事情都可能非常容易失控。 因此，知道如何馴服野獸比簡單地學習野獸可以做什么更為重要。

祝您在無服務器的冒險中好運！

翻譯自: https://www.javacodegeeks.com/2018/02/serverless-revolution-good-bad-ugly.html

總結

以上是生活随笔為你收集整理的无服务器革命：好，坏和丑的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。