在過去的12到18個月中，云領域出現(xiàn)了一個日益增長的趨勢。僅僅在幾年前，我們還習慣于為每個應用程序使用裸機服務器，然后演變?yōu)闉榱藴p少物理資源的虛擬機管理程序和虛擬化。下一步是通過將這些虛擬機和實例分成更小的單元--容器來進一步壓縮?，F(xiàn)在看到的是進化中的下一個階段--功能即服務（FaaS），或者更普遍的說法，無服務器（Serverless）。

我們不斷尋求優(yōu)化資源的使用和成本。要做到這些，什么是比消除底層操作系統(tǒng)更好的方式？本質上，我們大多數人是編寫代碼來創(chuàng)建應用程序。我們不想管理操作系統(tǒng)及其依賴關系，也不想編排它們。我們編寫代碼，并期望代碼運行，而不必處理下面的所有"管道"。這就是無服務器發(fā)揮作用的地方。

正如我們今天在公有云中使用的許多事情一樣，亞馬遜是使用Lambda提供此功能的先鋒。Lambda的基本概念是允許你上傳代碼(當然必須使用支持的語言之一)，而無需擔心其部署或擴展--所有這一切都由平臺負責。你的代碼將根據你定義的觸發(fā)器運行--可以是從隊列中消息到計劃任務的任何內容，這帶來了很大的靈活性。

最棒的是，你支付要為功能實際使用的時間和分配到的資源數量付費。不會僅僅因為你的代碼需要每天運行12次，就要為數小時的計算機資源和存儲空間花冤枉錢。你可以使用的粒度非常精細，老實說，除非你是非常重度的用戶，否則成本基本為0(亞馬遜每月免費提供100萬個請求)。

OpenStack中有許多不能用作完整服務的組成部分，并不像AWS中的對應部分那樣強大。LBaaS和DBaaS是OpenStack社區(qū)多年來試圖實現(xiàn)的兩個例子。不幸的是，這些服務與競爭對手相比不占優(yōu)。由于缺乏基本功能，許多企業(yè)即使在多個發(fā)布周期之后仍不愿意采用這些服務。

OpenStack社區(qū)已經認識到了無服務器基礎設施的趨勢，并且OpenStack中也將(已經)出現(xiàn)對這種服務的需求。目前，有兩個競爭項目在OpenStack上提供FaaS——StackStorm、OpenWhisk，這兩個項目都是由商業(yè)公司支持的。

StackStorm將其產品定義為"事件驅動的自動化平臺"，并在OpenStack波士頓峰會上亮相。

從上圖可以看出，該解決方案本身可以利用一些其他OpenStack服務，如Zaquar、Trove和Mistral。但問題在于，今天的大部分OpenStack部署在生產中幾乎不使用這些服務，如下所示：

因此，StackStorm路線需要大量修補。它在許多方面都向走向未知的水域，并不被接受為合適的OpenStack項目。

OpenWhisk是在OpenStack波士頓峰會上展示的IBM項目。該項目是開源的，可以認為它正在尋求成為現(xiàn)代數據中心的OpenStack(也可能是內部部署)云上無服務器的實際標準解決方案。在波士頓會議中呈現(xiàn)的示例是文件上傳到Swift的具體場景，然后會在OpenWhisk上觸發(fā)一個功能：

從上述兩幅圖和示例可以看出，無服務器仍然是一項正在進行的工作。 OpenStack社區(qū)本身尚未決定希望匯聚哪一種解決方案來為OpenStack提供完全集成的無服務器解決方案。上述示例還無法視為目前任何人都可以在其OpenStack(或本地)云上實際使用的完全成熟的解決方案。

越來越多的企業(yè)將工作負載轉移到主要的公有云提供商(AWS、Azure和Google)。
這不一定與無服務器無關，而是與整體的aaS功能有關。FaaS始終需要一些底層基礎架構來運行實際的代碼，而且總是需要一個操作系統(tǒng)。如何把它無縫和無形地提供給最終用戶(Lambda、Google Cloud功能和Azure功能是如何規(guī)?；瘜崿F(xiàn)的非常好的例子)，以及如何將該服務與所有云端的其他產品聯(lián)系起來，是問題所在。

如果可能，可以等待更多的OpenStack發(fā)布，讓開源產品和產品成熟到可以簡單和諧的方式使用。
如果有迫切需要，則建議與某一家主要的云提供商進行溝通，特別是如果它們已經在運行你的工作負載。請注意，并不是所有的提供商都相互兼容--從一個解決方案遷移到另一個解決方案可能是一個非常復雜的操作。

來源：http://sdtimes.com/openstack-serverless-sdtimes/