無伺服器的十大屬性

banq發表於2019-03-20

無伺服器計算或函式即服務(FaaS)正在不斷,亞馬遜正在透過將Lambda擴充套件到邊緣裝置和內容分發網路來推動創新。 IBM,  Microsoft和Google在公共雲中擁有自己的FaaS產品,有超過六個開源無伺服器專案正在引起開發人員的注意。預計今年將出現這一細分市場中出現的新平臺。
隨著無伺服器的所有興奮和炒作,瞭解真正定義平臺的內容非常重要。這是嘗試突出無伺服器計算平臺的關鍵屬性。對於客戶而言,它可作為選擇正確產品的清單,同時幫助平臺供應商最佳化其產品。

1.多語言平臺
FaaS的最大好處是選擇最適合特定任務的品種語言和執行時。每個函式都可以用不同的語言編寫,但對同一個應用程式有所貢獻。儘管  JavaScript似乎是Serverless的最低標準,但支援其他語言非常重要。
AWS Lambda以JavaScript開始,但  最終新增了對Python,Java和C#的支援。 Azure Functions支援所有流行語言,包括BASH指令碼語言。透過Docker整合,一些提供商將支援BYOI(自帶影像),支援遺留程式碼和二進位制檔案。IBM OpenWhisk就是這種FaaS的一個例子。Polyglot是客戶應該考慮的FaaS的一個重要方面。

2.支援同步和非同步呼叫
在FaaS中部署的函式可以是同步的或非同步的。某類app需要立即響應,而其他應用程式可能更喜歡非同步呼叫。例如,感測器生成的資料需要立即處理和分析,而上傳到物件儲存的影像可以透過批處理轉換為縮圖。
在FaaS中執行app類似於飛行無人機。
無論函式的樣式如何,FaaS平臺都應支援同步和非同步呼叫。當非同步觸發函式時,平臺返回可用於輪詢狀態的識別符號。IBM OpenWhisk支援這種模式,其中每個函式都被視為非同步,除非呼叫包含阻塞請求。
瞭解平臺支援的併發呼叫次數也很重要。

3. API閘道器整合
再怎麼強調與無伺服器平臺整合的API閘道器的價值都不過分。雖然在無伺服器環境中部署的函式通常由外部事件源(如流處理器和資料庫)觸發,但需要點亮函式的API閘道器,閘道器新增了將標準HTTP謂詞對映到各個函式的邏輯路由。
例如,可能有四個不同的函式負責資料庫上的CRUD操作,這些函式對映到GET,PUT,POST,DELETE動詞。這立即為開發人員帶來了熟悉的API外觀。API的消費者可能甚至沒有意識到他們正在處理無伺服器平臺。
AWS Lambda的採用僅在引入Amazon API Gateway之後才會飆升。致命的組合產生了一個強大的平臺,可以實現許多有趣的用例。
客戶應仔細評估無伺服器平臺是否與API閘道器良好整合。

4.開發人員生產力
今天開發人員使用的大多數IDE都不是為現代DevOps程式設計的  。原始碼控制系統,構建自動化,CI / CD和A / B測試的支援來自外掛和第三方附加元件。傳統IDE供應商需要很長時間才能支援FaaS。最近,微軟宣佈支援  Visual Studio中的Azure功能。AWS還為Visual Studio提供了一個外掛,以便在Lambda中開發和部署C#函式。但對於其他語言和框架,可用的選擇並不多。

5.支援DevOps和工具
有一種誤解,FaaS神奇地減少了對DevOps和工具的需求。無伺服器平臺應與原始碼控制系統緊密整合,並構建自動化工具。它們應該支援自動化和可重複的部署模式。亞馬遜再次引入  無伺服器應用程式模型(SAM),用於宣告包括AWS Lambda資源在內的整個堆疊。這些模板可以與git整合以實現一致的版本控制。Microsoft還支援透過ARM部署Azure功能。Google在部署管理器中包含雲功能之前還有很長的路要走。
IDE支援和與現有DevOps管道的整合是選擇FaaS平臺時要考慮的主要因素。
Serverless Inc正在構建工具,用於跨多個平臺自動部署FaaS應用程式。目前,在測試版中,該產品旨在成為開發基於FaaS的微服務的事實上的框架。

6.響應能力和表現
響應能力在設計基於FaaS的微服務應用程式方面發揮著關鍵作用。設計不良的平臺將引入啟動延遲並延遲呼叫過程,這對終端使用者來說是顯而易見的。輕量級的解釋語言(如JavaScript和Python)的響應速度比Java和.NET快。如果每次呼叫之間存在相當大的差距,則延遲變得明顯。保持函式“溫暖”的一個技巧是在迴圈中呼叫它。但對於許多客戶來說,這不是理想的解決方案。
一些新興FaaS平臺對Docker容器的使用令人擔憂。對函式的每個請求都將導致建立一個新容器,這將導致顯著的延遲。雖然與VM相比容器更快,但它們仍然不是FaaS的部署單位。我們需要一個比容器更好的執行環境來實現FaaS。
在部署微服務解決方案之前,客戶必須對每種語言和執行時的週轉視窗進行基準測試。

7.記錄和監控
在FaaS中執行應用程式類似於飛行無人機或無人駕駛飛機。兩者都可以控制的唯一方法是透過一個顯示當前狀態的強大儀表板。FaaS平臺應該對日誌記錄和監控提供廣泛的支援。寫入stdout和stderr的所有內容都應記錄到不同的流中。這對於瞭解應用程式的當前執行狀況和除錯各個功能至關重要。監視工具應提供有關每個函式的成功呼叫,不成功呼叫,呼叫時間,響應時間,記憶體消耗和CPU利用率的見解。
雖然FaaS定位為NoOps平臺,但DevOps團隊大量使用日誌記錄和監控功能。

8. REST端點和自動化
與大多數基於雲的交付模型一樣,FaaS必須完全自動化。只有當平臺支援用於執行透過門戶或CLI完成的所有操作的API時,才可以執行此操作。此功能使開發人員和操作員能夠有效地自動化部署和管理微服務的工作流程。
例如,CI / CD系統可以利用FaaS的REST API自動推送最新版本。此方案可以進一步擴充套件,以自動化在FaaS中實施A / B測試環境。

9.支援長期執行的作業和批處理
成熟的無伺服器平臺內建了對長期執行的預定作業的支援。可以定期呼叫FaaS中部署的功能以在ETL作業中執行。FaaS平臺可能支援相同的cron概念  來安排工作。
此功能進一步擴充套件到支援批處理。例如,上傳到物件儲存桶的大量高解析度影像可以由功能一次處理。這些方案與非同步呼叫模式不同。

10.可擴充套件性和整合
無伺服器平臺的真正價值在於廣泛的整合和可擴充套件性。例如,該平臺必須支援各種安全方案,包括  oAuth和基於LDAP的自定義身份驗證。它應該支援開箱即用的HTTPS端點以實現安全傳輸。
該平臺應具有足夠的掛鉤,以便與各種事件源輕鬆整合。AWS Lambda等專有平臺僅支援與S3,  Kinesis和  DynamoDB等服務的整合  。開源平臺應該使資料庫供應商和其他平臺公司能夠輕鬆支援FaaS。 OpenWhisk的Feed就是這種整合的一個例子。
 

相關文章