“無服務器”一詞是一個極具誘惑力的流行語，因為再也沒有什么比服務器更讓人痛苦的了。難道說所有的安全漏洞補丁都在你的收件箱里用上百萬個電子郵件中數不清的詞語描述的?設想一下你如果能夠擺脫服務器，你可以不去想這些補丁。難道說防火墻上的所有端口你都得時刻記著他們是否處于關閉狀態?這些問題再也不會使你苦惱了。無服務器的世界將使你重獲自由。無論如何，這個詞是如此承諾的。
無服務器的世界看起來很無拘無束，并且充分利用時間為你的每一個正當使命效忠：你告訴它的它應該是什么樣的。但同時也不要被欺騙了。你也將為從苦惱中獲取自由而付出一定代價，那就是犧牲這份自由去進行遷移。亞馬遜，微軟和谷歌云中的無服務器平臺通過專有接口施展他們的魔力，每當你將一些苦惱轉移到他們的一直等待著的手中時，你就會慢慢上癮。特別是被像谷歌的大規模集群管理工具Borg這樣的工具所吸收。“擁有”這個詞太強大了，強大到你可能會發現很難從它手中逃脫。
程序員很反感這種束縛，這也就是為什么許多程序員嘗試著開發開源軟件包，而這些軟件包提供基于云的無服務器平臺的一些甚至大部分功能，但是卻可以在任何地方使用一大堆代碼。這不僅可以使調試和測試變得更加容易進行，而且可以讓您的整個配套元件和媒體播放器價格上漲，并且有更好反應時間或其余好處。你甚至可以把它帶回家，放在你曾經打電話給服務器機房的帶空調的儲藏室里。
為了了解這個迅速發展的開放源代碼無服務架構的世界，我啟動了幾臺機器并編寫了一些簡單的邏輯。現在就得出任何確定的結論還為時過早，因為這些項目喜歡說稱自己是“預覽版”，但是將我們從束縛中解放還是很有希望的。
下面讓我們來看看為此所做出的努力的四大軟件 - Fission, Fn, Kubeless, 和OpenWhisk.。當然，之后會很快出現更多的軟件加入他們的行列。
Fission
一個來自九號平臺的開源無服務器對策，Fission將使用一些配有動態裝載器的標準容器把Kubernetes與內部容器聯系在一起。所使用的功能將被放置于適當的標準容器中，并被加載以回答來自已在容器內的Web服務器的查詢。
標準環境包括主要模型(Node.js，Python和Go)以及一些老派的解決方案，如PHP，.Net，Ruby甚至Perl。當然，你也可以用你喜歡的任何語言翻閱你自己的語言，只要你制作一個可以回應HTTP請求的二進制文件即可。
對于任何想通過容器編排提供的自動縮放選項直接跳到Kubernetes級別的人來說，Fission可能是最有用的。他們可以使用Kubectl，Helm和Tiller等標準工具在Kubernetes集群內運行Fission。
一個使用Fission的指令行界面將簡單功能轉換為運行容器的快速五項示例。
如果你不能依靠HTTP來調用這些函數，Fission可以通過Crontab或來自兩個得到支持的排隊工具之一的信息(Azure隊列存儲或NATS流)觸發它們。還可以選擇在YAML文件中定義“工作流”，以便按順序運行多個任務。
Fission提供的最大服務是維護動態加載代碼的一組標準容器。這些容器基本上是預先配置好的，為您節省添加必不可少的代碼以便在群集中正確運行的麻煩。
Fn項目
Fn意味著甲骨文公司涉足無服務器空間，將一些模板，主要語言的標準構建例程和一些標準的開源的應用容器引擎Docker粘合在一起。 Fn比其他應用軟件更加以Java為中心，當您考慮甲骨文公司擁有Java時，這并不令人意外。 Fn需要使用多種語言的結合體，并且以Docker為基礎就可以構建例程。有些甲骨文公司的資料寫道“一個依賴：Docker”。
其中一個更有趣的功能是一套包裝器，它可以讓您在甲骨文公司的本地堆棧中運行您的亞馬遜云服務匿名代碼而不是您的代碼。使用這些包裝器的核心功能是相對而言更容易了解其信息，但這往往只是圖片的一部分。大多數人使用匿名代碼作為其他亞馬遜云服務的粘合代碼。這些包裝器只能幫助您自己獲取匿名代碼本身，因此您必須找出其他解決方案來解決亞馬遜云服務應用程序編程接口API所帶來的繁重工作。這些包裝器很棒，但它們的實用性取決于您設計架構的方式以及您的代碼運用在多少亞馬遜服務上。
與所有這一類工具一樣，Fn的接口都是命令行。您輸入fn，然后添加命令以創建新模板，生成結果代碼或最終部署它。你編寫一個簡單的函數即一個單獨的文件，然后fn會將它與合適的模板進行綁定，以便它可以在某個Docker容器中運行。
Go，Java，Python，Ruby和Node.js的預建模板都捆綁為Fn開發工具包(FDK)，但您無需集中時間在它們身上。他們都會要求你建立一個函數，并將一個字符串作為參數，最后返回一個字符串作為結果。沒什么比這更容易操作了。
Fn中的這個實驗性用戶界面展示了如何將多個不同的功能鏈接到一起進入工作流程。
當您部署代碼時，Fn會將其連接到一個HTTP觸發器，該觸發器捆綁了所有的參數并將它們提供給在Docker容器中運行的函數。差不多剩下所有的事情都是對你的夢想和設計敞開大門的。是的，Fn可以讓你免于為所有的部署而頭痛，但是你仍然需要在該函數中編寫所有的代碼。
你可以用Fn內部的機制來略微變動一下。管家信息存儲在一個基本數據庫(SQL3)中，用于跟蹤路線和其他部署信息，但您可以打破傳統，直接使用MySQL或Postgres。消息隊列還有一個可配置的選項，可以幫助不同版本的Fn進行協調工作。你可能對他們無動于衷，但如果你想要得到更多的話，那么選項就在那里。
Fn經過一番設計后非常輕巧，簡單。它需要一些標準的構建工具和一些標準的Docker模板并將它們連接在一起，這樣編寫一段代碼并觀測它在其中一個Docker容器中運行起來會更容易。
Kubeless
Kubeless源于Bitnami，是幫助我們用多種不同類型的手持產品提取云的所有功能的公司之一。同Fission一樣，Kubeless的設計宗旨也是將無服務器的所有樂趣帶給Kubernetes群集。這個名字有點令人發笑，因為這項技術是沒有Kubernetes的。如果要說有的話，那就是利用Kubernetes的內置功能來打造快速無服務器的基礎架構。
Kubeless將您的功能轉變為自定義資源，這是Kubernetes根據需要創建和擴展的功能被設計出來的一點。開發人員似乎偏愛Python，因為這些例子大部分都是寫在里面的，但也有Node.js，Ruby，PHP，Go和.Net的運行時間。盡管文檔的某些部分缺少Java 1.8，但根據所安裝的版本，它已包含在可用運行時間表中。
這個框架的基本功能比其他框架更為復雜。您編寫的每個函數都將使用兩個參數，一個是參與事件的對象，另一個是參與某個元數據或上下文的對象，與只傳遞字符串到函數的方法相比，這個框架允許有更復雜一點的自我感知編程模型。最后，你必須返回一個字符串，該字符串將返回任何HTTP請求啟動一切的滾動。(在一些堆棧中有一些更好的幫助函數，其中在Node.js運行時間內接受一個對象并對其進行序列化。)
Kubeless有一個用戶界面，可以讓你編輯你的功能，然后點擊進行部署。
如果您不想從HTTP請求中觸發功能，則可以將Kubeless配置為在特定時間響應Kafka或NAT消息或預定的調用。您還可以通過為事件創建自定義資源來擴展此功能。
對于已經完全接受Kubernetes的人來說，Kubeless所采用的方式是非常有吸引力的，并且可以讓人在集群和自動縮放的世界中感到自在。Kubeless主要是一個快速將一些基本代碼轉換為回應請求的Kubernetes集群的工具。
OpenWhisk
OpenWhisk是IBM在IBM Cloud中構建云功能的官方工具。它也是由Apache軟件基金會帶領的一個開源項目(仍處于孵化狀態)。 OpenWhisk實際上是幾個流行的Apache項目的綜合體，這些項目被拼接在一起以占用幾行代碼，然后將它們包裝在Docker容器中，并通過REST API喚醒它們的執行。這些請求由Nginx發起，轉化為Kafka信息，然后傳遞到容器中。身份驗證和管理信息存儲在CouchDB中。就像一個Apache基金會再度聯合。
代碼本身可以用JavaScript，Java，Python，PHP，Go等編寫，要明白，即使是Swift對那些花時間寫iPhone應用程序的人也是如此。當然你可以使用幾乎任何你可以綁定到Docker容器中的東西，只要函數參數可以被stdin接受并且結果通過stdout輸出。
OpenWhisk開發人員基本上為每種主要語言都構建了一系列標準框架，這些框架將采用一些預先配置的語庫來進行一些文本輸入并吐出一些文本輸出。當你編寫你的簡要功能時，OpenWhisk會將它粘貼到這個標準容器中，并且一切開始工作 - 前提是你已經按照說明書正確書寫了你的功能。
總會有竅門的。 Java代碼希望Google GSON庫是可用的。 Swift代碼的容器將運行Swift的開源版本，因此可能會也可能不會有代碼與iOS世界中的經歷完全相同的時刻。 JavaScript可能是所有人傾心的選項，并且您的JavaScript代碼將在節點6或節點8內運行，這是很好理解和被預測的。
OpenWhisk請求的路徑。請求到達HTTP網關后，它將通過Kafka傳播到正確的Docker包裹里。
但是，在IBM精心設計的云平臺中使用OpenWhisk和在我自己的機器中運行OpenWhisk兩者之間存在巨大差異。 IBM的Web界面使得編寫幾行代碼變得簡單易懂并且可觀測它們成功運行。我卻花了半個小時才從無到有在IBM Cloudant數據庫中存儲文本中看到正在運行的界面。
當我嘗試做類似于開源發行版的事情時，在經歷過配置API主機之類的障礙之后，我還是一直遇到障礙。這些文檔遠不如應有的那么完整。有幾個不同的快速啟動路徑的指針，你會嘗試著去猜測和填補漏洞。
然而很快就可以清楚的知道，在你自己的機器上運行它們所有的配置有相當多的布局。打包Swift函數的說明是幾行代碼采用大量配置和腳本來運行的好示例。
無服務器vs. 簡易性
這四個項目都在一個很狹窄的細分市場中。“無服務器”這個詞沒有像預期的一樣被廣泛使用，還有很多其他的選擇可以在沒有“無服務器”的時髦詞匯的情況下提供很大的靈活性和自由度。數據庫通常被認為是最初的無服務器選項，許多像WordPress，Drupal和Magento這樣的開源系統都是無服務器的。您可以通過添加適合于大框架的PHP模塊來擴展它們。調用插件或模塊的內容也某種程度上說是“無服務器”。
在這種情況下，這些工具都不像任何一代技術那樣無憂無慮地運行。這四個無服務器平臺更是接近Kubernetes或Docker集群的增強型管理器。它們更像是一種管理工具，可以簡化所有需要設置和運行這些集群的配置。或者像自動生成工具一樣，可以包裝你的功能并讓它在群集上運行。
他們所扮演的角色是受限于他們的架構。工具創建者的目標是提供最大的靈活性。而他們都有一長串支持的語言，但是他們說支持所有符合輸入輸出標準的二進制數據。所以他們所能做的就是將零件粘合在一起并吐出一個容器。
事實證明，將容器內的零件正確組合是一個很大的挑戰。所有的資料都會說，你可以通過編寫一個函數來執行這些任務或動作。但是這個函數能具有有什么樣的功能呢?此時你被困在處理容器內的所有工作上。在交出控制權之前，您必須先正確處理容器里的二進制和代碼。然后處理所有其他部分，如數據庫和API。
這最終要比為亞馬遜云服務Lambda，IBM Cloud Functions或微軟Azure和谷歌云上的相同功能編寫代碼要難做的多。當所有的東西就緒，云的數據存儲或API服務將提供您所需的持久性和分析。這時你真的只需編寫一些簡單的函數來編碼一些業務邏輯，就完成了。剩下的就是云在那里繼續這項工作。
持久性、API集成和云的其他組件都為開源項目帶來了一些挑戰。所有這些項目都很好地發揮功能并使其運行。但是他們沒有解決所有其他事情，這意味著你也必須重復所有這些其他事情。如果您邁著步子逃離主要的云提供商，您會感覺到像個孩子背著一個裝滿了果醬餡餅的背包走出家門，然后發現家不僅僅是食物。而是一張床，一臺洗衣機，一臺電視機，一間浴室，一只狗等。
一點想法
在這一點上，開源項目對云本身來說是非常好的營銷策略。在初步了解了這些開源項目之后，我很快就開始各種問題，這讓在舒適的、被鎖定的云環境之外生存變得更加困難。不過隨著平臺的成熟和程序員推動“無服務器”這個詞的含義，這可能會有所改變。
一開始，我認為無服務器主要是云的一種外殼腳本，這種方法只需添加一些邏輯來更平滑進出IBM Cloudant或Amazon S3等大型服務的數據流。現在人們正在接受這個簡單的想法，然后在無服務器框架內轉向去編寫令人難以置信的復雜功能。一些更為大膽的程序員也正在將相當復雜的代碼轉換，機器學習或計算工作，放在無服務器調用中，這些調用在時間和內存限制基本能完成工作。
開放源代碼工具包對這種更大更宏觀的無服務器前景做了很好的鋪墊。如果您將要完成一項功能中的幾乎所有工作，那么這些工具立馬會幫助您開始運行。
但這也有個困難，無服務器對于許多人來說可能更便宜的原因是因為只有在運行代碼時才需要支付服務器費用。在你有足夠大的工作量來保證一臺服務器全速運行之前，在云中運行你的函數應該會更便宜，因為這將幫你與其他一些函數共享硬件。如果你的函數只能產生10%的負載，支付10%的負載蜂擁當然是便宜的，而這時云服務器的價格你需要支付100%，花在服務器的90%資金是浪費的。
這種成本組成是很容易讓人迷惑的，涉及電力成本，房地產成本和硬件成本。如果你夠聰明，便可以大大節省開支。這些開源項目使您可以在自己的服務器場上復制無服務器的魔法，但這也意味著您必須自己找到正確的方法來處理所有的經濟問題和部署復雜性。好消息是，他們在處理將函數轉換為運行的容器這個工作方面還是做得非常好的。如果，這是唯一的任務的話。
