管理服務器帶來的無休止的麻煩是大型雲服務公司採用“無服務器”架構的原因之一。他們知道老闆已經聽夠了服務器出這樣或那樣問題的藉口。如果我們能夠擺脫那些服務器，那麼老闆一定會考慮。
藉助AWS Lambda、谷歌雲函數和微軟Azure Functions，可幫你將很小的業務邏輯做得更好。
如果你因為服務器出問題而在凌晨3點被喚醒，你就會明白像“無服務器”這樣的流行詞如此具有吸引力的原因。這些設備可能需要數小時、數天甚至數週才能配置完畢，然後需要不斷地更新以修復錯誤和安全漏洞。這些更新程序通常會給其自身帶來麻煩，因為新更新程序會導致與其他更新程序不兼容，或者這一工作看起來永無休止。
管理服務器帶來的無休止的麻煩是大型雲服務公司採用“無服務器”架構的原因之一。他們知道老闆已經聽夠了服務器出這樣或那樣問題的藉口。如果我們能夠擺脫那些服務器，那麼老闆一定會考慮。
這是一個很棒的銷售語言，但唯一的問題是它並不完全正確。這些應用程序處於無服務器架構，就像餐廳裡沒有廚房一樣。如果你想要的菜在菜單上，並且你喜歡廚師的烹飪方法，那麼坐在餐廳裡是很棒的選擇。但如果你想要一種不同的菜餚，如果你想要不同的調料，那麼你最好有自己的廚房。
亞馬遜、谷歌和微軟是三家大公司，正在為未來管理應用程序而戰，他們希望將這些應用程序寫入其無服務器API中，並通過其自動化層進行管理。如果這些平臺可提供你想要的東西，而且這些新模型非常通用化，那麼這些平臺可能是創建自己的價值數十億美元的獨角獸網絡應用的最簡單和最快捷的方式。你只需編寫關鍵的邏輯部分，而平臺會處理所有的細節。
無服務器功能正在成為連接所有云功能的粘合劑或腳本語言。曾經相當獨立的映射或人工智能工具現在通過事件驅動的無服務器功能進行鏈接。現在，更多的工作可以通過請求來解決，這些請求會通過每個雲的各個部分產生波動和回彈，產生觸發並由一系列事件觸發。如果你想了解機器學習技術並使用它來分析你的數據，那麼最快速的方法之一就是創建一個無服務器應用程序，並開始將事件發送到雲計算的機器學習部分。
隱含的承諾是，將所有內容切割得更薄，這樣可以更輕鬆地共享雲端的資源。過去，每個人都會瘋狂地創建新的實例，例如在自己的虛擬機上運行Ubuntu服務器。每個人都使用相同的操作系統，並且這個系統在同一個真實機箱上覆制無數次，假裝成十幾個或更多的虛擬Ubuntu機箱。無服務器操作可以避免所有重複操作，使雲計算成本大幅降低，特別是對於偶爾運行的作業，而且從未使在空調服務器機房中的舊機箱發生堵塞。
當然，所有這些便利都有隱性成本。如果你想離開或想將你的代碼移動到另一個站點，你可能會陷入重寫大部分堆棧的困境。這些API是不同的，儘管JavaScript等流行語言有一些標準化，但它們更接近於專有技術。使用者有很多被鎖定的機會。
為了理解無服務器的吸引力，我花了一些時間來構建一些函數，並圍繞堆棧進行研究。我沒有寫太多的代碼，但這就是關鍵。我花了更多時間點擊按鈕並輸入網頁表單來配置一切。你還記得我們用XML和JSON配置過所有的東西嗎?現在我們填寫一個網絡表單，雲端就會為我們做這一切。儘管如此，你仍然必須像程序員一樣思考，瞭解幕後發生的事情，以及你無法控制的事情。
AWS Lambda計算服務
AWS Lambda正在成長為亞馬遜整個雲端的shell腳本層。這是一個基本系統，可讓你嵌入響應事件的函數，這些事件可能是由亞馬遜雲基礎架構任何部分所產生的。如果一個新文件上傳到S3，你可以讓它觸發一個函數，做一些有趣的事情。如果某些視頻正在被Amazon Elastic Transcoder媒體轉碼工具進行轉碼，你可以在轉碼完成後等待其去觸發Lambda函數。這些函數反過來可以觸發其他Lambda操作，也可能只是向某人發送更新。
你可以使用JavaScript(Node.js)、Python、Java、C#和Go語言編寫Lambda函數。鑑於這些語言可以嵌入許多其他語言中，所以很可能運行其他代碼，如Haskell、Lisp甚至C ++。(關於將舊版C ++編譯為庫以與AWS Lambda一起使用的內容，請參閱本文案例。)
編寫Lambda函數往往比你預想的要複雜得多，因為亞馬遜提供了很多配置和優化選項。雖然技術上你可以只寫幾行代碼，就能完成很不錯的功能，但是我覺得，我必須花更多時間來配置代碼的運行方式。這一工作的大部分內容是通過在瀏覽器中填寫表單而不是在文本文件中輸入來完成的。有時候感覺就像我們只是將文本編輯器換成了瀏覽器表單，但這就是使用亞馬遜為Lambda用戶提升靈活性的代價。
其中一些額外的步驟是由於亞馬遜向用戶提供更多的選項所帶來的，並期待有更多首次函數編寫者。一旦我在谷歌或微軟上編寫完一個函數後，我就可以將瀏覽器指向正確的URL並立即進行測試。亞馬遜讓我點擊來配置API網關，並在防火牆中打開恰當的漏洞。
最後，所有這些點擊會增加一層輔助工具，使得工作比一開始使用文本文件更輕鬆一些。當我創建一個函數時，瀏覽器會彈出一個警告，“這個函數包含外部庫”。在純節點的時代，這是我希望知道的事情，或者我可以通過谷歌來搜索錯誤信息，然後希望找到答案進行學習。而現在雲端正急著來提供幫助。
如果無服務器意味著將你從管理服務器的雜事中解放出來，那麼亞馬遜還有許多其他如同AWS Lambda一樣的“無服務器”選項。它具有像Amazon EC2 Auto Scaling和AWS Fargate這樣的彈性工具，可以啟動和關閉服務器，以及具有AWS Elastic Beanstalk工具可將你上傳的代碼部署到Web服務器並處理負載平衡和縮放。當然，擁有許多這些自動化工具，你仍然需要負責創建服務器映像。
AWS Step Functions是一種更有用的產品，它是一種無代碼流程圖工具，用於創建狀態機以創建軟件架構師調用工作流的模型。一部分問題是所有的無服務器函數都是完全沒有狀態的，當你執行非常基本的業務邏輯時，這些函數是正常的，但當你通過一個清單或流程圖來處理客戶端問題時，這些函數可能會是一場噩夢。你要不斷地到數據庫重新加載有關客戶端的信息。Step Function可將Lambda函數與狀態結合在一起。
谷歌雲函數和Firebase平臺
如果你的目標是擺脫配置服務器的麻煩，那麼谷歌雲提供了許多服務可以讓你更輕鬆，例如輸入根密碼，甚至使用命令行等工作。
從2008年的Google App Engine平臺開始，谷歌一直在慢慢地添加不同的“無服務器”選項，並將各種消息發送和數據透明度結合在一起。一個名為Google Cloud Pub / Sub的工具可對用戶隱藏消息隊列，因此你只需為數據生產者和消費者編寫代碼即可。谷歌雲函數為許多主要產品(包括某些選取框工具和API)提供事件驅動的計算。然後是谷歌Firebase平臺，這是一個很強大的數據庫，可讓你將JavaScript代碼混合到數據存儲層，該數據存儲層將數據傳送到客戶端。
其中，Firebase平臺是我最感興趣的。一些人認為數據庫是原始的無服務器應用程序，它將數據結構和磁盤存儲工作抽象出來，通過TCP/IP端口傳遞所有信息。Firebase平臺通過添加JavaScript代碼和消息發送功能來完成你想在服務器端基礎架構執行的幾乎所有工作(包括身份驗證)，使這種抽象性工作做到極致。從技術上講，它只是一個數據庫，但它可以處理堆棧的大部分業務邏輯和消息傳遞。你真的可以擺脫一些客戶端的HTML、CSS、JavaScript和Firebase平臺。
你可能會像對待Oracle一樣，試圖將Firebase平臺的JavaScript層稱為“存儲過程”，但這樣做會忽略更多內容。Firebase代碼是用JavaScript編寫的，因此它將以本地版本的Node.js運行。你可以在該層中嵌入大部分業務邏輯，因為節點環境中已經充滿了處理此工作流的庫。另外，你還會享受在客戶端、服務器上運行的同構代碼的樂趣，現在可以運行在數據庫中。
引起我注意的部分是Firebase中內置的同步層。它可將整個網絡中來自數據庫的對象副本進行同步。其訣竅是，你可將你的客戶端應用程序設置為另一個數據庫節點，該節點可訂閱所有相關數據(僅包含相關數據)的更改。如果數據在一個地方發生改變，它會在所有位置進行改變。你可以避免所有消息傳遞的麻煩，並專注於將信息寫入Firebase中，因為Firebase會將其複製到需要的位置。
你無需只關注於Firebase。更基本的谷歌雲函數是一種更簡單的方法，可將定製代碼嵌入整個谷歌雲中。目前，雲函數很大程度上只是編寫Node.js代碼的一個選項，該代碼將在預配置的節點環境中運行。雖然谷歌雲平臺的其他部分可支持各種語言，包括Java、C#、Go、Python和PHP，但云函數卻僅限於使用JavaScript和Node語言。有跡象表明，其他語言選擇即將實現，如果這些選擇很快出現，我不會感到驚訝。
至少在這一點上，谷歌雲函數不會像AWS Lambda進入AWS一樣深入到谷歌雲中。當我嘗試構建一個與Google Docs交互的函數時，我發現我可能不得不使用REST API並將代碼寫入名為Apps Script的應用程序中。換句話說，Google Docs環境擁有自己的REST API，其在無服務器這個流行詞出現很久之前就處於無服務器狀態。
值得注意的是，Google App Engine的功能持續變得強大。一開始，它提供了啟動Python應用程序以滿足訪問者進入網站的需求，但多年來一直在擴展功能，目前可處理許多不同的語言運行環境。將代碼打包成可執行文件後，App Engine將啟動流程，開啟足夠的節點來處理流量，並在用戶發送請求時按比例放大或縮減數量。
要牢記的是，仍存在一些障礙。與雲函數一樣，你的代碼必須以相對無狀態的方式編寫，並且必須在有限的時間內完成每個請求。但是App Engine不會拋棄所有的scaffolding，也不會忘記各請求之間的所有東西。App Engine是無服務器革命中的重要組成部分，對於那些仍採用舊方法並使用Python，PHP，Java，C#或Go語言構建自己的堆棧的人來說，它仍然是最容易獲得的平臺。
微軟Azure Function
當然，微軟與其他公司一樣在努力工作，以確保人們可以使用微軟Azure完成所有的無服務器架構工作。微軟公司已經為處理事件創建了自己的基本函數，即Azure Function，並且還構建了一些更復雜的工具，這些工具對於不太成熟的程序員來說更加易於使用。
微軟擁有的最大優勢可能是它的Office應用程序集合，這些前期的桌面可執行文件正在緩慢而穩定地遷移到雲端。事實上，在雲計算收入的一種財務核算方法上，微軟已領先於亞馬遜公司，這部分原因在於微軟將其部分Office收入納入到短期的“雲”計算收入中。
Azure Functions文檔中最好的一個示例說明了，當某人在將電子表格保存到OneDrive時，雲函數是如何被觸發的。突然間，雲端的小精靈活躍起來，可以處理電子表格中一些事情。對於喜歡Excel電子表格(或其他Office文檔)的IT支持團隊來說，這絕對是天賜之物。他們可以編寫Azure Function來做幾乎任何事情。我們通常認為HTML和網絡是雲端的唯一接口，但沒有理由不能通過Microsoft Word或Excel等文檔格式連接至雲端。
Azure的Logic Apps引起了我的注意，它的一個工具可以幫你填寫表單，而不用擔心語義和語法。你仍然需要像程序員一樣思考，並對抽象概念和數據做出明智的決定，但是你可能會說服自己，你並沒有像填寫表格那樣來編寫“代碼”。
像亞馬遜的Step Functions一樣，Logic Apps的目的是對“工作流”進行編碼，這是一種流行詞，比起普通的“函數”要複雜得多，這要歸功於可使用某種狀態。你仍然可以用類似流程圖的方式編寫鏈接各種函數和連接器的邏輯，但是你不會用像正式計算機語言那樣進行詳細說明。
Logic Apps的一大優勢是預先構建的“連接器”，可深入到微軟和第三方的一些更大應用程序中。你可以有效地從Logic Apps 以及Salesforce、Twitter和Office 365等程序中推送或提取數據。這些連接對於公司IT人員來說非常有價值，他們現在可以通過編寫Logic Apps來連接外部工具，就像他們過去創建shell腳本一樣。
Azure另一個有趣的地方是Azure Cosmos DB，它同時是NoSQL數據庫和SQL數據庫。微軟已經複製了Cassandra和MongoDB的API，這樣你就可以在不改寫Cassandra或MongoDB代碼的情況下輸入和輸出信息。或者，如果你想寫SQL語句的話，你也可以這樣做。Cosmos DB可以讓內容很直觀，併為所有內容建立索引，以使其快速運行。如果你有很多SQL和NoSQL代碼需要同時使用，這將使它成為一個非常不錯的中心連接。或者，也許你只是想在未來為採用不同的方法敞開大門。
無服務器雲的比較
哪個無服務器平臺適合你?在所有三個獨立平臺中編寫基本函數幾乎都是一樣的，但是存在一些差異。最明顯的區別可能是可使用的語言，因為這些平臺在完成支持Node.js和JavaScript語言後都會使用自己偏好的語言。你可以為微軟的Azure使用C#語言編寫，這並不令人驚訝，但它對F#和TypeScript語言的支持是獨一無二的。亞馬遜可支持Java、C#和Python語言。谷歌目前的基本函數嚴格限於使用JavaScript語言，但它在App Engine中支持更多的語言。
對無服務器雲進行對比最難的是掌握其價格和速度，因為更多的東西隱藏在底層。當我啟動虛擬機，並按每小時價格收費時，我常常覺得自己像個瘋狂的消費者。現在，提供商正在將其服務切分的如此精細，以至於你可以以不到一美元的價格獲得數十萬次函數調用。你會像在“王牌大賤諜”電影中的“邪惡博士”一樣，反覆去說“百萬”這個詞。
當然，這種明顯的低價很快就會削弱我們大腦中理性的和預算意識的部分，就像我們在一個陌生的國家度假一樣，這個國家使用完全不同的貨幣面額。不久之後，你將訂購另外數百萬次的數據庫調用，就像你在墨西哥坎昆的酒吧喝酒一樣，因為你無法快速換算價格以確定其實際成本。
當雲計算為你提供一臺原始的虛擬機時，你可以猜測其內存容量和CPU性能，但是在無服務器的環境中，你並不真正知道其中的內在配置。
值得注意的是，無服務器模式幾乎會迫使你將數據存儲在本地雲數據庫中，因為它不允許你在代碼中保留任何狀態。你必須相信這些後端架構。你的函數必須運行在沒有任何本地緩存或配置的環境中，因為其他版本總是被創建和銷燬。因此，數據庫膠水代碼會填滿你的代碼，就像在《怪奇物語》(Stranger Things)電影中表裡世界(Upside Down)的那些藤蔓一樣。
比較成本的唯一現實方法是在所有平臺上構建應用程序，這是一項艱鉅的挑戰。可以在三者之間移動一些代碼，因為它們都運行Node.js，但即便如此，你仍然會遇到並忍受一些差異。 (例如，你直接在Microsoft和Google中處理HTTP請求，但要通過AWS中的API Gateway進行處理。)
好消息是你不必如此偏執。在我的實驗中，許多基本應用程序幾乎不使用任何資源，你可以使用這三個平臺所提供的免費資源很長時間，這些資源是為吸引那些不願付費的開發人員。無服務器模式確實為我們節省了開銷。除非你的服務器是始終接近滿負荷運行，並且放置在擁有免費空調的機房，否則你將業務轉向無服務器方式，這很可能最終會為你節省一些大筆資金。你會節省如此多的資金，你也就不會計較它每百萬次函數調用的價格是1美元或1.50美元。
還有一個更深層的問題。如果你受夠了這些雲，你就會陷入困境。這並不是很輕鬆地就能將代碼取出並在其他地方的商品服務器上運行，而是你可能要使用裝滿自己代碼的Docker容器進行操作。如果幸運的話，你可以複製相同的原始架構和基本的JavaScript函數，但在此之後，你要在所有部位都重寫數據庫膠水代碼。所有這三家公司都有自己的專有數據存儲層。
目前還不清楚出現故障時會發生什麼。運行你自己的服務器意味著，當你的老闆不能正常工作時，你需要立即解決問題。目前還不清楚在這個領域會發生什麼。在谷歌公司的一個頁面中包含一個溫和的警告，“這是谷歌雲函數的測試版。此API可能會以不兼容的方式進行更改，並且不受任何服務水平協議(SLA)或棄用政策所約束。”
亞馬遜的服務條款比它首次進入這一領域時要好一些，但它仍然包含一些你需要記住的警告內容，例如：“如果你上傳到AWS Lambda的任何內容超過三個月未使用，那麼我們會在30天內通知你，並可能將其刪除，且不承擔任何形式的責任。”如果你想在亞馬遜雲端保留你的代碼，那麼請確保你經常運行該代碼。像這樣的警告內容當然是公平的(這樣的話，我會知道我的舊Lambda函數不會再被使用)，但這也表明了你將如何放棄一些控制權。
微軟為Azure服務提供服務水平協議，其承諾通過服務積分對故障時間進行經濟補償。這些承諾也適用於你的函數故障嗎?也許，只要你不使用一些測試版服務。如果你打算構建比兒童聊天室更重要的工作，那麼就值得花一點時間關注這些細節內容。
在大多數情況下，你真正想進行的是在亞馬遜、谷歌和微軟雲的其他功能和服務之間的比較，而不是函數層面。如果你對喜歡使用Office應用程序的用戶提供支持，則利用在OneDrive上的Office文件來觸發Azure Functions的功能，這對你是極具吸引力的。藉助谷歌Firebase平臺，可以輕鬆使用各種功能為Web應用提供消息傳遞和身份驗證等支持服務。AWS Lambda提供了許多亞馬遜服務，看起來天空真的是有極限的。
從技術上講，混合和匹配所有這些雲和函數是可能的，因為它們都使用相同的PUT和GET語言來調用HTTP API。你沒有理由不使用這些融合很多微服務的應用程序，因為這些應用程序集合了三個雲平臺中最好的功能。但是，當數據包離開本地雲，並在開放互聯網的荒野中傳遞時，你將最終遇到更大的延遲。然後，在解析和結構上會有細微的差異，這使得坐在一家公司的溫暖環境中工作變得更輕鬆。
因此，使用單個雲的安全部分可能是更合理的，至少在涉及相互關聯的應用程序時是這樣。你真的很喜歡谷歌地圖嗎?你是否想把它們用於你的項目?那麼，即使在你的心中，你也可以使用谷歌雲函數，而不是將F#語言與微軟的Azure Functions結合使用。亞馬遜的語音識別，或谷歌的圖像分析API，或任何數十種不同的服務和機器學習API也是如此。功能並不那麼重要，它們的相互連接才是真正重要的。
閱讀更多 OTPUB 的文章
