 |
VOOZH | about |
|
VOOZH | about |
如果你因為伺服器出問題而在凌晨3點被喚醒，你就會明白像「無伺服器計算」這樣的流行詞的吸引力。物理伺服器可能需要數小時，數天甚至數周才能配置，然後它們需要不斷更新以修復錯誤和安全漏洞。這些更新通常會帶來他們自己的麻煩，因為新更新會導致不兼容，從而導致其他更新，或者看起來似乎沒有盡頭。
運行伺服器導致的無窮無盡的連鎖問題是主流雲公司接受「無伺服器計算」架構的原因之一。 他們知道老闆們聽多了這樣的藉口，伺服器這個了，伺服器那個了，太多類似的問題。 如果我們能擺脫伺服器，老闆肯定想要。
無伺服器計算是一個很棒的銷售條款，唯一的問題是它不是完全正確的。這些應用程式是無伺服器的，就像餐廳沒有廚房一樣。如果你想要的在菜單上，並且你喜歡廚師準備的方式，那麼坐在餐廳里是很棒的。但如果你想要一種不同的菜餚，如果你想要不同的香料，那麼你最好有自己的廚房。
亞馬遜，谷歌和微軟是三家面向未來應用的大公司，他們希望將這些應用寫入無伺服器API並通過其自動化層進行管理。如果這些平台按你想要的方式做，而且新模型非常普遍，它們可能是創建價值數十億美元的獨角獸網絡應用的最簡單和最快捷的方式。你只寫關鍵的邏輯位，平台處理所有的細節。
無伺服器計算函數正在成為連接所有雲功能的粘合劑或腳本語言。曾經相當獨立的映射或AI工具現在通過事件驅動的無伺服器函數進行連結。現在，更多的工作可以通過請求來解決，這些請求會在每個雲的各個角落產生漣漪和反彈，觸發並由事件流觸發。如果你想探索機器學習，並使用它來分析數據，那麼最快速的方法之一就是創建一個無伺服器應用，並開始將事件發送到雲機器學習部分。
隱含的承諾是，將所有內容切割得更薄可以更輕鬆地共享雲中的資源。過去，每個人都會瘋狂地創建新的實例，例如運行在自己的虛擬機上的Ubuntu伺服器。每個人都使用相同的作業系統，並且在假裝成十幾個或更多的虛擬Ubuntu盒子的同一個真實盒子上複製了數十億次。無伺服器計算操作可以避免所有重複操作，使雲計算成本大幅降低，特別是對於零星運行且從未真正堵塞在空調伺服器機房中的舊伺服器的工作。
當然，所有這些便利都有隱藏的成本。如果你想離開或移動你的代碼到另一個站點，你可能會被迫重寫大部分堆棧。這些API是不同的，儘管JavaScript等流行語言有一些標準化，但它們與專有技術非常接近，會被廠商鎖定。
為了理解無伺服器計算的吸引力，我花了一些時間來構建一些功能，並圍繞堆棧進行探測。 我沒有寫太多的代碼，但這是關鍵。 我花了更多時間點擊按鈕並輸入網頁表單來配置所有內容。 你還記得我們什麼時候用XML和JSON配置了所有的東西嗎？ 現在我們填寫一個網絡表單，云為我們做。 儘管如此，你仍然必須像程式設計師一樣思考，了解幕後發生了什麼，並且無法控制。
AWS Lambda
AWS Lambda正在成長為亞馬遜整個雲的shell腳本層。這是一個基本系統，可讓你嵌入函數，響應幾乎任何AWS IaaS可能產生的事件。如果一個新文件上傳到S3，你可以讓它觸發一個函數，做一些有趣的事情。如果某些視頻正在被Amazon Elastic Transcoder轉碼，你可以在完成後等待Lambda函數被觸發。這些功能反過來可以觸發其他Lambda操作，也可能只是向某人發送更新。
你可以使用JavaScript（Node.js），Python，Java，C＃和Go編寫Lambda函數。鑑於這些語言可以嵌入許多其他語言，所以很可能運行其他代碼，如Haskell，Lisp甚至C ++。
編寫Lambda函數往往比你期望的複雜得多，因為Amazon提供了很多配置和優化選項。雖然技術上你可以只寫幾行代碼並完成很棒的事情，但是我覺得我不得不分配更多時間來配置代碼的運行方式。大部分工作是通過在瀏覽器中填寫表單而不是輸入文本文件來完成的。有時候感覺就像我們剛剛交換了瀏覽器表單的文本編輯器，但這是保留Amazon擴展到Lambda用戶的所有靈活性的代價。
其中一些額外的步驟是由於亞馬遜向用戶公開更多選擇，並期望更多的首次函數編寫者。一旦我在Google或Microsoft寫完功能後，我就可以將瀏覽器指向正確的URL並立即進行測試。亞馬遜讓我點擊來配置API網關，並在防火牆中打開正確的洞。
藉助AWS Lambda配置頁，可以單擊觸發函數的事件源和更多事件的目標。
最後，所有這些點擊都增加了一層手持式工具，使得工作比以文本文件開始更容易一些。當我創建一個函數時，瀏覽器有一個警告，「這個函數包含外部庫」。
亞馬遜還有許多其他選項，如同AWS Lambda一樣「無伺服器計算」，如果無伺服器計算意味著解除你的伺服器管理雜事。它具有彈性工具，如啟動和關閉伺服器的Amazon EC2 Auto Scaling和AWS Fargate，以及將你上傳的代碼部署到Web伺服器並處理負載均衡和縮放的AWS Elastic Beanstalk。當然，對於許多這些自動化工具，仍然需要負責創建伺服器映像。
AWS Step Functions是一種更有用的產品，它是一種無代碼流程圖工具，用於創建狀態機以模擬軟體架構師稱為工作流的模式。部分問題是所有的無伺服器函數都是完全沒有狀態的，當你執行非常基本的業務邏輯時，這些功能是有效的，但是當你通過一個客戶端走過一些客戶端時，這可能有點噩夢清單或流程圖。你經常到資料庫去重新加載關於客戶端的信息。步驟函數將Lambda函數與狀態粘合在一起。
Google Cloud Functions 和 Firebase如果你的目標是擺脫配置伺服器的麻煩，那麼Google Cloud提供了許多服務，從需要根密碼甚至使用命令行等方面提供各種各樣的自由。
從2008年的Google App Engine開始，Google一直在慢慢地添加不同的「無伺服器計算」選項，並且提供各種消息傳遞和數據透明組合。一個名為Google Cloud Pub / Sub的用戶隱藏了消息隊列，因此你只需為數據生產者和消費者編寫代碼即可。 Google雲端函數為許多主要產品（包括某些選取框工具和API）提供事件驅動的計算。然後是Google Firebase，這是一個資料庫，可將JavaScript代碼混合到將數據傳送到客戶端的數據存儲層。
其中，Firebase是我最感興趣的。一些人認為資料庫是原始的無伺服器計算應用，將數據結構和磁碟存儲雜事抽象出來，以通過TCP / IP埠傳遞所有信息。 Firebase通過添加JavaScript代碼和消息傳遞來將這種抽象極端化，以完成你可能想要對包括身份驗證在內的伺服器端基礎架構執行的任何操作。從技術上講，它只是一個資料庫，但它可以處理堆棧的大部分業務邏輯和消息傳遞。你真的可以擺脫一些客戶端的HTML，CSS，JavaScript和Firebase。
你可能會像Oracle一樣，試圖將Firebase的JavaScript層稱為「存儲過程」，但這樣做會忽略大局。 Firebase代碼是用JavaScript編寫的，因此它將以本地版本的Node.js運行。你可以在該層中嵌入大部分業務邏輯，因為Node的世界已經充滿了處理此工作流的庫。另外，你將享受在客戶端，伺服器上運行的同構代碼的樂趣，現在還可以享受資料庫。
引起我注意的部分是Firebase中內置的同步層。它將在整個網絡中同步來自資料庫的對象副本。訣竅是，你可以將你的客戶端應用程式設置為另一個訂閱相關數據（僅相關數據）更改的資料庫節點。如果數據在一個地方發生變化，它會隨處變化。你可以避免所有消息傳遞的麻煩，並專注於將信息寫入Firebase，因為Firebase會將其複製到需要的位置。
Google Firebase提供了一個錯誤控制台，可以顯示展示好壞事件的時間表。
你無需專注於Firebase。更基本的Google雲功能是一種更簡單的方法，可將定製代碼嵌入到Google雲中。目前，雲端函數在很大程度上只是編寫Node.js代碼的一個選項，它將在預配置的Node環境中運行。雖然Google雲端平台的其他部分支持各種語言--從Java和C＃到Go，Python和PHP雲功能嚴格限於JavaScript和Node。有人暗示其他語言選項即將到來，如果他們很快出現，我不會感到驚訝。
至少在這一點上，Google Cloud Functions不會像AWS Lambda，當我探索構建一個與Google Docs交互的函數時，我發現我可能不得不使用REST API並將代碼寫入名為Apps Script的應用程式中。換句話說，谷歌Docs世界擁有自己的REST API，很久就沒有伺服器了。
值得注意的是，Google App Engine持續強勁。一開始，它提供了啟動Python應用程式以滿足任何人進入網站的需求，但多年來一直在擴展以處理許多不同的語言運行時。將代碼捆綁到可執行文件中後，App Engine將處理啟動足夠的節點以處理流量的過程，並在你的用戶發送請求時向上或向下放大或縮小。
要牢記幾個障礙。與雲函數一樣，你的代碼必須以相對無狀態的方式編寫，並且必須在有限的時間內完成每個請求。但是App Engine不會拋棄所有的支撐，或者在請求之間忘記所有的東西。 App Engine是無伺服器革命中的一個重要組成部分，對於那些在老派方法中使用Python，PHP，Java，C＃或Go構建自己的堆棧的人來說，它仍然是最容易獲得的。
Microsoft Azure Functions當然，微軟和其他人一樣努力工作，以確保人們可以用Azure雲做所有這些聰明的無伺服器計算事情。該公司已經創建了自己的基本功能--Azure函數，並且構建了一些更複雜的工具，這些工具對於半程式設計師來說更加易於使用。
微軟可能擁有的最大優勢可能是它的Office應用程式集合，這些以前的桌面可執行文件正在緩慢而穩定地遷移到雲中。事實上，雲計算收入的一個核算使微軟領先於亞馬遜，部分原因在於將其部分Office收入納入了「雲」。
Azure Functions文檔中最好的示例之一顯示了某人在將電子表格保存到OneDrive時如何觸發雲功能。突然間，雲中的小精靈活躍起來，在電子表格中做些事情。對於喜歡Excel電子表格（或其他Office文檔）的IT支持團隊來說，這絕對是天賜之物。他們可以編寫Azure函數來做幾乎任何事情。我們經常認為HTML和網絡是雲的唯一接口，但沒有理由不能通過Microsoft Word或Excel等文檔格式。
Azure的邏輯應用程式引起了我的注意，它是讓你填寫表單而不用擔心語義和語法的工具之一。 你仍然需要像程式設計師一樣思考，並對抽象和數據做出明智的決定，但是你可能會說服自己，你並沒有像填寫表格那樣編寫「代碼」。
Microsoft Azure的Web IDE允許你編寫Azure函數，運行它並通過插入日誌記錄調用進行調試。
像亞馬遜的Step Functions一樣，Logic Apps的目的是對「工作流」進行編碼，這是一種流行詞，比起平均的「功能」要複雜得多，這要歸功於某種狀態的可用性。你仍然可以用類似流程圖的方式編寫連結各種功能和連接器的邏輯，但是你不會用官方的計算機語言拼出它。
Logic Apps的一大優勢是預先構建的「連接器」，可深入到那裡的一些較大的微軟和第三方應用程式中。你可以有效地將數據從SalesApp，Twitter和Office 365等Logic應用推送或提取出。這些連接對於公司IT人員來說非常有價值，他們現在可以通過編寫Logic Apps來連接外部工具，就像他們創建的一樣shell腳本。
Azure另一個令人感興趣的地方是Azure Cosmos DB，同時是NoSQL和SQL的資料庫。微軟已經複製了Cassandra和MongoDB的API，這樣你就可以在不改寫Cassandra或MongoDB代碼的情況下輸入和輸出信息。或者，如果你想寫SQL，你也可以這樣做。 Cosmos DB可以讓事情保持直線並為所有事情建立索引，以保持其快速運行。如果你有很多你想合作的SQL和NoSQL代碼，這使它成為一個有趣的中心聯繫。或者，也許你只是想在未來為不同的方式敞開大門。
無伺服器計算比較
哪個無伺服器計算平台適合你？在所有三個孤島中編寫基本函數幾乎都是一樣的，但是存在差異。最明顯的可能是可用語言，因為每個語言在完成支持Node.js和JavaScript之後都會播放收藏夾。你可以為Microsoft的Azure編寫C＃並不令人驚訝，但它對F＃和TypeScript的支持是獨一無二的。亞馬遜採用Java，C＃和Python。 Google目前的基本功能嚴格限於JavaScript，但它在App Engine中支持更多的語言。
比較無伺服器計算的最難的部分是掌握價格和速度，因為更多的東西隱藏在底層。當我將虛擬機以每小時價格定價時，我常常覺得自己像個瘋狂的消費者。現在，供應商正在將薩拉米香腸切片得如此薄，以至於你可以以不到一美元的價格獲得數十萬次函數調用。
當然，這種明顯的便宜很快就會削弱我們大腦理性的，預算意識的部分，就像我們在一個陌生的國家度假時一樣，這些國家的貨幣種類差別很大。不久之後，你將訂購另外數百萬次的資料庫，就像你在Cancun購買一杯酒時一樣，因為你無法快速分配以確定其實際成本。
當雲計算推出的是一台原始的虛擬機時，你可以猜測內存和CPU的能力，但是在無伺服器計算的世界中，你並不真正知道發生了什麼。
值得注意的是，無伺服器計算模式幾乎迫使你將數據存儲在本地雲資料庫中，因為你並不是真的被允許在代碼中保留任何狀態。你必須相信這些後端。你的函數必須運行沒有任何本地緩存或配置，因為其他版本總是被創建和銷毀。因此，資料庫膠水代碼填滿了你的代碼，就像在「陌生事物」中顛倒過來的那些藤本一樣。
比較成本的唯一真正方法是在所有平台上構建應用程式，這是一項艱巨的挑戰。可以在三者之間移動一些代碼，因為它們都運行Node.js，但即便如此，你仍然會遇到需要忍受的差異。 （例如，你直接在Microsoft和Google中處理HTTP請求，但通過AWS中的API Gateway處理。）
好消息是你不需要那麼偏執。在我的實驗中，許多基本應用程式幾乎不使用任何資源，你可以在免費的三層提供所有這三項優惠以吸引貧窮的開發人員。無伺服器計算模式確實為我們節省了開銷。除非你是一直在接近滿負荷運行你的伺服器的類型，並且獲得了免費空調，否則很可能你最終會通過轉向無伺服器方式來節省一些大筆資金。你將節省如此多的資金，以至於你不會爭論它是否為每百萬次調用1美元或1.50美元。
有一個更深層的問題。如果你受夠了這些雲，你就會陷入困境。這不是很容易，只需將代碼關閉並在其他地方的商業伺服器上運行它，你可以使用充滿自己的代碼的Docker容器進行操作。如果你幸運的話，你可以複製相同的原始架構和基本的JavaScript函數，但在此之後，你將在整個地方重寫資料庫膠水代碼。所有這三家公司都有自己的專有數據存儲層。
目前還不清楚事情出錯時會發生什麼。運行你自己的伺服器意味著，當不能工作時，你的老闆會窒息你的脖子。目前還不清楚在這個領域會發生什麼。 Google的一個頁面包含這個良性警告，「這是Google Cloud Functions的測試版。此API可能會以不兼容的方式進行更改，並且不受任何SLA或棄用策略的約束。「
亞馬遜的服務條款比他們第一次進入這個領域時的表現要好，但他們仍然包含警告要記住，例如「我們可能會在30天內通知你並且沒有任何責任的情況下刪除你的任何內容如果未超過三（3）個月，則上傳到AWS Lambda。「確保你的代碼在你想要保留的情況下運行。像這樣的警告肯定是公平的（我知道我的舊Lambda函數不會再被使用），但它顯示了你如何放棄一些控制。
微軟為Azure服務提供服務級別協議，承諾通過服務積分對停機進行經濟補償。這些適用於你的功能降級嗎？也許--只要你不徘徊在服務的某個測試區域。值得花一點時間關注這些細節，如果你打算建立比兒童聊天室更重要的任務。
↓↓↓ 點擊"閱讀原文" 【加入雲技術社區】
