“我們也許再也不用為服務器分神了。”Amazon公司CTO Werner Vogels博士在上周于倫敦召開的AWS峰會上談到無服務器計算的價值，“我們發現一場新的革命正在孕育，即應用程序正整體從服務器當中剝離出來，意味著只需代碼即可實現運行。已經有相當一部分企業在進行應用程序拆分并替換其中的服務器部分，具體而言虛擬機與容器等運行平臺都屬于純代碼方案。”

Amazon公司CTO Werner Vogels博士在倫敦接受采訪。

由于整個行業都開始考慮利用容器取代虛擬機，包括利用Amazon的ECS（即EC2容器服務）實現管理工作，那么隨之而來的剝離潮流自然也在情理之中。當然，要讓這一切成為現實，大家可能需要以更為開放的心態接納云計算即托管平臺——而非IaaS。

S3與DynamoDB等早期AWS服務方案并不要求用戶使用虛擬機或者容器，Vogels表示。“如果大家回顧我們的DynamoDB設計思路，就會發現我們著眼于其它各類NoSQL數據庫并發現其管理難度甚高。我們的最終目標就是承擔起緩沖區管理以及連接池等任務，從而為用戶提供一致的數據庫性能表現。”

“在設計DynamoDB的同時，我們想到為什么不干脆為其提供所需性能水平的管理能力？用戶可以向服務供應商提供自身需要的讀取與寫入操作強度，而我們則確保這一切都以穩定的性能表現完成。”他解釋稱。

這些早期服務并不允許大家直接運行代碼，但Amazon公司于2014年11月啟動的Lambda則完全改變了這一切。該項目最初作為一種利用JavaScript編寫代碼的方式存在，可由S3內的文件歸檔等事件所觸發，但同時又潛在支持多種應用程序類型，并最終在發布后的這段時間內迎來顯著演變。

如今的Lambda已經能夠支持Java、Node.js以及Python，同時支持預定功能并可由事件進行觸發，且可接入AWS VPC（即虛擬專有云）以實現對專有網絡的訪問。其代碼存儲容量上限已經由原本的5 GB提升至75 GB。Lambda還能夠與負責構建API的API Gateway或者用于定義AWS資源組的CloudFormation等AWS服務順暢對接。

“大家只需要編寫代碼，我們負責運行代碼，”Vogels指出。“部署模式由代碼實現。大家仍然需要進行版本控制。每項功能的運行只耗時數秒，或者最多數分鐘。另外，每項功能都擁有單一線程與單一任務。大家仍然可以根據需求并發執行數萬乃至數十萬項Lambda功能。其計費模式不再基于每虛擬機每小時，而是按照特定時間段內的內存使用量以及所處理的請求數量進行計算，”Vogels表示。

但他在解釋中回避了一個問題，即Lambda的使用方式相當復雜，絕不止上傳代碼那么簡單。大家需要指定必要的內存容量以及特定功能的運行時長，一旦超出時間即會產生錯誤。然而，這項服務確實將虛擬機或容器以抽象形式從其運行基礎中剝離了出來——事實上，在接下來的Lambda對話環節中，他表示該服務本身也是通過容器實現的。

配置AWS Lambda內存設置

Amazon公司并不是惟一提供此類服務的供應商。微軟推出了Azure Functions，而谷歌則在自家云計算平臺上拿出了Cloud Functions。

同樣的趨勢也開始出現在其它云平臺上，微軟、谷歌以及Salesforce都已經允許大家在無需管理虛擬機或者容器的前提下實現應用程序運行。谷歌方面的App Engine則始終遵循這樣的起效方式。微軟的Azure App Service幫助我們管理虛擬機，不過其實例并非完全抽象。

也就是說，“無服務器計算”通常是指那些負責承載由眾多小型微服務類功能構成的應用——而非整體式應用程序。無服務器平臺最為典型的使用方式就是用于與其它云服務相對接。這種能力對于云服務供應商而言非常重要，也許這也正好解釋了其積極投向于其中的原因。舉例來說，我們可以利用Lambda配合其它AWS服務。

“在無服務器計算中，大家不必為容器費心，而只需要編寫應用代碼。我們可將不同片段結合起來并加以整體管理。”Vogels指出。

正如分析師James Governor指出，無服務器是一種“對按需計算模式的自然總結”，意味著大家只需要在代碼執行時付費，即“客戶價值點”。

那么無服務器模式是否代表著未來的發展方向？其負面因素在于，用戶對于代碼運行方式的控制能力有所削弱，而且現有應用程序往往很難直接被移植至這種新興模式。

即使大家熱衷于無服務器模式，但從嘗試到最終實現仍然是個漫長而艱難的過程，Vogels坦率地承認。盡管如此，在著手建立新的容器類項目之前，無服務器模式仍是一種值得考量的重要選項。