原文：it』s all going to be serverless — the question is 「when?」
很多觀點將無伺服器化（serverless）和現在的功能即服務( functions-as-a-service )產品聯絡起來，這很令人失望，他們完全曲解了無伺服器化。這個觀點很狹隘。
硬體依然是那些，所以無伺服器化是一種服務層抽象，乙個給你帶來益處的感覺。如此，它有兩個明確的特點：配置虛擬機器映象中不可見基礎設施，以及基於呼叫的計費方式而不是傳統的按時收費。
並非如你開始所認為那樣的模糊不清——雲在一定程度上已經是無伺服器化。當使用諸如aws s3或者azure儲存等基礎服務時，你要按每gb付賬（使用磁碟的成本），按每次i/o操作付賬（資料訪問所需計算機資源的成本）和按次所傳輸的位元組數付賬（網路管道的成本）。伺服器就在那裡，其資源為成百上千的客戶所共享，只是你沒有察覺而已。
讓很多開發者不安的是無伺服器執行自己**的理念-換言之，通用無伺服器化計算。
我怎麼知道自己的**如何執行？我如何除錯並且監視環境？我如何加固伺服器？
這些都是本能的反應和疑問——這些重要的非功能觀點在我們開始**乙個良好的無伺服器架構前都必須得到解決。現在開始討論我們的選擇。
第一種具備廣泛用途的無伺服器化計算機是功能即服務業務：aws lambda和azure functions。這兩種服務都為按需執行的**提供執行環境。你不必開發很多應用，你只要寫應用片段和事件規則，這些規則在需要的時候觸發你的**。「當我在/foo 收到乙個http request時，執行x 」，「當佇列中有訊息時開始y」諸如此類。
功能可能很簡單：只是輸入乙個或者幾個方法來完成乙個簡單工作。
你不知道或者不關心伺服器，你的**只是執行而已。現在你處於功能園中，根據記憶體和cpu的使用，按照零點幾秒的時間進行計費。無論一天中進行了一次』或者一百萬次呼叫，這沒關係-這種差別你是看不見的。
所以，現在無伺服器化是明確的方向。但是功能集並不能單獨佔據主導地位。為什麼？
此外，還要大量的工具問題使得faas產品對於一些場景難以使用。我對這些卻並不擔心——所有這些產品都在以飛快的速度進行改進，如果現在工具問題阻礙了你，這些問題應該很快就會得到解決。問題是「什麼時候」？
工作流編排產品使得很多複雜的事情變得容易。在乙個購物反饋過程中插入24小時的延遲？只要增加乙個延遲任務，然後你的應用會在一天後神奇的恢復。有人在twitter上提及你的產品時要有所回應？簡單的雙擊，你也不必考慮使用twitter api。這種開箱即用活動不但能減輕編排的痛苦，而且對於大多普通服務可以消除編寫客戶**的需要。
儘管工作流很適合業務過程建模，但是卻不是適用於所有無伺服器工作負載的靈丹妙藥。例如，複雜的決策樹用於表示工作流仍顯得相當笨拙。原始的**依然保留其獨特的表達潛能。此外，工作流的單步計數計費模型造成頻繁的輪詢和昂貴的過細粒度的人力劃分。
功能集和工作流都不能解決帶有大量移動部件的連續執行任務的問題。這聽起來 似乎是相當有限的問題，但是有乙個額外原因讓其成為大問題：過去幾十年中幾乎所有的應用，至少部分上是設計作為連續執行的任務。
因此，在我們的無伺服器化百寶囊中還需要更多的工具。
容器技術是幾年前隨著docker的出現而降臨的，並且它的出現引起了不小的震動。容器定義了下一代的虛擬機器。儘管最初提供的都是linux空間，現在也有了對於windows的支援，容器排程技術（mesosphere, kubernetes等）現在逐漸成為主流。
「ok，jouni,你明顯是把容器作為乙個軟體包裝媒介，但是無伺服器呢？容器在本質上只是執行在一台容器主機上的打包的迷你伺服器，本質上仍然是另外一台伺服器！實際上，它們幾乎是無伺服器的死對頭！」
我很高興你這麼問。我相信容器在轉化為無伺服器平台前需要解決兩個問題：無伺服器主機和容器維護。
對於許多使用者來說，容器群集是一種有效主機平台，相比於虛擬機器，容器可以真正提公升負載密度。
但是，為了轉向無伺服器化，我們需要忘記等待工作的虛擬機器。我們需要在詳細耗費度量上基於呼叫的計費。
第乙個這樣做的主流產品是 2023年7月發布預覽的azure container instances。acl為我們提供了按需定製容器，而不必考慮執行在何種基礎設施之上。需要來個配備乙個虛擬cpu和2g記憶體的容器例項麼？
az
container
create--
name
jounidemo--
image
myregistry/nginx
-based
-demo:v2--
cpu1--
memory2-
-registry
上述就是執行中的微賬單，事實上它會十分有效。你不必使用一台虛擬機器來處理你的批處理任務，如果你需要處理高突發能力，秒級或者更短延遲的無伺服器容器就可以滿足需要，而不是啟動時間更長的虛擬機器群集。
但是雖然現在有無伺服器容器可供選擇，我們仍然要面臨包含伺服器容器的困境——也就是所謂的「如何獲得你修補過的base images」問題。
無伺服器化的信條之一是開發者只需關注業務邏輯，而非其他細節。容器是一種奇妙的工具，但是按照定義，其與生俱來的還有維護其環境的技術負擔。
你通過建立乙個os base image來構造自己的應用，在其頂端對所需的服務進行分層，最後注入你的應用。當你發布乙個新版本，你重建你的容器映象然後就可以工作了。情況是，一旦base image和依賴都組合到你的映象中，它們如何更新？近來的windows補丁和新的linux 核心安全補丁如何更新到你的應用中？
考慮這樣的問題和無伺服器化的本質有點對立。日常的依賴維護不是無伺服器化開發者要關注的，所以這些應該自動化。
但是日常維護和關鍵決策之間的界線是模糊的。例如，乙個典型的web**很樂意更新其作業系統，並不會在意其***。但是你如何劃分這界線？你的web伺服器應該在你未察覺的情況下進行更新麼？乙個新node.js版本呢？
這是乙個微妙的問題，但是需要認真研究。對於這點，我推薦花費幾分鐘聽一聽在 .net rocks #1459上對微軟的 steve lasker的採訪，大約在37分鐘處。
並且，包含伺服器的容器看起來似乎更為serverless。容器能夠比簡單的**片段功能框架完成更為複雜的工作任務，並且通過減小執行階段所包含依賴的***，它們也更關注業務本身。
題目的「即將完全轉向無伺服器化」咒語，後面跟著乙個何時實現的問題。現在答案已經顯而易見，就是「現在！」這個平台現在仍然還要很多問題要解決。
例如，在azure container instances 上執行乙個24x7容器任務，花費太昂貴；你就想使用一台虛擬機器了。實現虛擬機器完全自動更新補丁則是另外乙個挑戰。現在容器的維護自動化還沒有實現。faas的日誌和監控部分以及工作流產品對於aws和azure開發者來說，依然是持續的痛苦根源。對於windows容器的支援呢？還處於開發階段。
但是工具一直以飛快的速度進行改進。基於功能的無伺服器化和工作流產品在去年跨越了一大步。容器仍然處於準備過程中，容器中的所有部分都揹負很高的期待。
一旦這些都實現了，就可以將現有事件應用的很大一部分，遷移到具備更少伺服器層級依賴的平台上。對於新的原生雲應用架構師來說，無伺服器微服務平台將會要求完全嶄新的設計思想。我期待接下來的12個月裡能發生翻天覆地的變化。
無伺服器計算101
serverless computing 無伺服器計算 是目前最被看好的雲計算執行模型。其最大的好處是提供分布式彈性可伸縮的計算執行環境，僅為實際使用資源付費，並且將應用維護者從常規的運維事務中解放出來，更利於專注到具體的業務上。在主流的應用部署方式下，無論是使用雲主機還是kubernetes作為執...
無伺服器計算101
serverless computing 無伺服器計算 是目前最被看好的雲計算執行模型。其最大的好處是提供分布式彈性可伸縮的計算執行環境，僅為實際使用資源付費，並且將應用維護者從常規的運維事務中解放出來，更利於專注到具體的業務上。在主流的應用部署方式下，無論是使用雲主機還是kubernetes作為執...
無伺服器Serverless總結
雲計算是通過 internet 按需提供計算能力 資料庫儲存 應用程式和其他 it 資源，採用按使用量付費的定價模式。雲計算的發展歷程 iaas paas saas baas faas 無伺服器計算是一種計算方法，可將對常見基礎結構管理任務 例如，擴充套件，排程，修補，配置等 的責任轉移給雲提供商和...