OpenStack和Serverless：大賭注還是必然

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

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

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

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

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

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

　　StackStorm將其產(chǎn)品定義為“事件驅(qū)動的自動化平臺”，并在OpenStack波士頓峰會上亮相。

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

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

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

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

　　越來越多的企業(yè)將工作負載轉(zhuǎn)移到主要的公有云提供商（AWS、Azure和Google）。

　　這不一定與無服務器無關(guān)，而是與整體的aaS功能有關(guān)。FaaS始終需要一些底層基礎架構(gòu)來運行實際的代碼，而且總是需要一個操作系統(tǒng)。如何把它無縫和無形地提供給最終用戶（Lambda、Google Cloud功能和Azure功能是如何規(guī)模化實現(xiàn)的非常好的例子），以及如何將該服務與所有云端的其他產(chǎn)品聯(lián)系起來，是問題所在。

　　專業(yè)人士建議，如果可能，你還可以等待更多的OpenStack發(fā)布，讓開源產(chǎn)品和產(chǎn)品成熟到可以簡單和諧的方式使用。

　　如果有迫切需要，則建議你與某一家主要的云提供商進行溝通，特別是如果它們已經(jīng)在運行你的工作負載。請注意，并不是所有的提供商都相互兼容——從一個解決方案遷移到另一個解決方案可能是一個非常復雜的操作。