無伺服器革命的好、壞和醜!
摘要：
有人預言10年後，也就是2020年無伺服器將承載全球83％的企業工作量。
無論你喜歡與否，一場革命正在進行中。AWS處於領先地位，MS Azure和GCP緊隨其後，所有人都懷有共同的目標：
無伺服器=FAAS=DevOps之死
無論名稱如何（為方便起見，我們稱之為“無伺服器”），這...
有人預言10年後，也就是2020年無伺服器將承載全球83％的企業工作量。
無論你喜歡與否，一場革命正在進行中。AWS處於領先地位，MS Azure和GCP緊隨其後，所有人都懷有共同的目標：
無伺服器=FAAS=DevOps之死
無論名稱如何（為方便起見，我們稱之為“無伺服器”），這種新正規化已經在重塑軟體環境方面發揮了作用。我們已經看到像可口可樂這樣的巨頭在其生產堆疊中採用無伺服器元件，而像無伺服器這樣的框架獲得了數百萬美元的資金。然而，我們應該記住，無伺服器不是每個人適用，每個地方適用，每次都是適用 - 至少到目前為止不是。
伺服器（少）=狀態（少）
作為一個傳統的程式員，我在無伺服器方面看到的最大“障礙”是“無狀態”。
儘管像lambda這樣的實現傾向於保留狀態一段時間，但是一般契約是你的應用程式應該能夠放棄所有的希望並優雅地從零開始。不再存在記憶體狀態：如果你想儲存，那麼你輸了。
從另一個角度思考，這也可能被認為是無伺服器的強大優勢之一; 因為瞬態是大多數情況，狀態 -不是全部 -是邪惡的根源。
這可能是一個公平的權衡，特別是像我這樣的臭名昭著的程式設計師，是通過記憶體狀態管理和尋求（通常是過早的）優化。
我們不應該忘記由於記憶體狀態管理和快取容量的減少而導致的效能損害; 你的狀態管理器（資料儲存），以前只是一些“電路跳躍”，現在會有幾個網路跳躍，導致幾毫秒 - 甚至幾秒 - 的延遲。
鑑於其簡單性，多功能性和可擴充套件性，無伺服器應用程式可以成為公司IT基礎設施的寶貴資產; 但是，如果沒有正確設計，部署，管理和監控，在架構複雜性和財務問題方面，事情可能會非常容易失控。所以，知道如何馴服野獸比簡單地學習野獸也許更重要。
祝您無伺服器冒險成功！