各大Serverless架構提供商的六項服務較量
譯文【51CTO.com快譯】根據RightScale云服務狀況報告2018版(請詳見：https://www.rightscale.com/lp/state-of-the-cloud)顯示，無服務器(Serverless)架構的市場滲透率已增至75%。而且，這個市場里的玩家，已不再局限于AWS Lambda或Azure Functions等主流提供商。不過，在面對眾多云服務提供商，并需要將現有服務遷移到某個無服務器架構之前，您是否真正了解他們的不同之處?下面讓我們一起來深入探究一番。
無服務器架構的發展歷史
近十多年來，隨著云技術在商業中的廣泛采用，整個市場也得到了迅速發展。我們可以看到，每年都有新的應用開發方法的出現。從邏輯層面來看：那些使用IaaS(基礎設施即服務)的企業，主要是通過租用服務器資源，來將其基礎設施遷移到云端。但是他們的IT團隊仍然需要去動手設置各種服務器。而隨著PaaS(平臺即服務)的出現，IT團隊逐漸擺脫了對服務器的手動操作。PaaS提供商能夠提供更為完整的應用程序棧，包括：由提供商所管理的、運行在云中的操作系統和數據庫等。
如上圖所示，IaaS也屬于另一種后端即服務(Backend-as-a-Service，BaaS)的云服務部署與開發模式。
2014年，一種新的應用程序開發方法：無服務器架構，或稱FaaS(功能即服務，Function-as-a-Service)出現了。簡而言之，FaaS是一種無服務器的計算形式，它使用的是完全由提供商托管的基礎架構，供用戶上傳和運行他們的功能函數，并按請求付費(pay-per-request)。
與其他云計算方法不同的是，無服務器架構讓開發人員完全從服務器中抽象出來，使得他們能夠專注于業務的邏輯。如果您想更深入地了解FaaS的相關概念，以及無服務器架構的優缺點，請閱讀：https://www.altexsoft.com/blog/cloud/pros-and-cons-of-serverless-architecture/?utm_source=DZone&utm_medium=referral。
無服務器架構的好處
話說回來，盡管無服務器架構已廣受歡迎，但是它不一定對每一家公司、每一類產品都合適。在此，我們首先來看看無服務器架構的整體優勢。當然，由于服務提供商的不同(如開源或是公有云)，各家的優勢也可能略有不同。
u 降低成本和具有可擴展性。如前所述，與傳統方法相比，無服務器架構降低了服務器運營和維護的成本。而與其他類型的云計算服務相比，大多數FaaS提供商都能夠貫徹按請求付費的定價機制。這就意味著您只需要為調用功能函數的時間和次數買單。此外，您還可以靈活地為功能函數分配一定數量的內存和CPU，并按需擴縮容。
- 更快的開發和部署。區別于整體(monolith)結構的構建方式，FaaS提供了更靈活的替代方案。開發人員可以編寫一組，由不同功能函數所組成的代碼，而不是將整體應用的代碼上傳到服務器上。因此，這使得整個結構更易于調試、更新和添加新的功能。
- 減少人力資源的支出。企業不必雇用DevOps工程師來進行運維，當然也不必購買特定的硬件。
- 高可用性和自動擴展。只有在客戶端發出請求時，功能函數才會被激活并運行，而在不需要的時候，它們處于關閉狀態。同時，隨著流量的增長，FaaS能夠自動擴展，它們通過為特定功能函數分配更多的資源，以實現高可用性，和在高負載下的平穩性能。
- 專注于業務需求。通過讓開發人員從服務器端(server-side)的工作抽象出來，您的團隊會更專注于應用的業務邏輯。
無服務器架構提供商概述
這兩年，隨著新玩家持續的入局，無服務器架構提供商的名錄在2018年也擴充了不少。我們將這些提供商分為主流和備選兩大類。主流類一般是在共有云上提供無服務器架構。下面，我們將對各大主流與備選提供商進行介紹與比較。
Amazon Web Services于2014年推出了此類FaaS產品。自發布以來，Lambda已經成為了無服務器架構的代名詞。憑借著最廣泛的服務類別，Lambda一直保持著市場的領先地位。其***的案例，莫過于Netflix的無服務器公有云應用。
作為AWS Lambda競爭對手，該服務于2016年被推出。Azure Functions提供了一組與Amazon類似的服務，它更關注于Microsoft體系產品的語言和工具。Azure Functions的一個案例是Have I Been Pwned。如果您對Azure上的應用程序結構、及其執行方式感興趣的話，您可以通過https://www.troyhunt.com/how-did-have-i-been-pwned-perform-on/，來查看有關該案例的分析和費用詳情。
作為四巨頭之一，Google直到2017年才發布了其解決方案。雖然GCF的起步晚于Azure和Lambda，但是Google在2018年奮起直追，它解決了各種早期錯誤，并在其官網上進行了公示。
作為無服務器領域的新手，IBM憑借著一系列具有競爭力的服務打入到了該市場。IBM Cloud Functions是Apache OpenWhisk在其云服務中唯一使用到的托管式架構方案。當然，如果您更偏好開源方案的話，那么Apache OpenWhisk可能更合適于您。
總的說來，上面提到的各大提供商都能夠提供相似的服務，也都能夠在托管式架構上運行各種應用。雖然表現形式各有不同，但是它們都能給用戶帶來FaaS的各種優勢。為了幫助您找出最適合于自己提供商，我們將從如下六個方面深入比較它們的服務：
- 定價模型和計費因素
- 支持的編程語言
- 功能函數觸發類型
- 每個請求和并發的執行持續時間
- 部署方法
- 監控和記錄
主流FaaS提供商的比較
定價模型和計費因素
如前所述，大多數FaaS提供商使用的是非常劃算的按請求付費的定價模型。為了能夠計算出某個應用的成本，他們通過各種服務來精準地預測出該應用的潛在費用。例如：Serverlesscalc就是一款能夠專門用來計算，目標應用在四大無服務器架構提供平臺上成本開銷的工具，不過它目前仍處于測試階段。當然，上述各大提供商也有著自己的計算工具：
如上圖所示，大多數提供商的價格體系基本相同，但由于Google對內存與CPU的使用單獨計費，因此它是其中最貴的。具體說來：
AWS Lambda提供一種免費套餐，它包括：每月100萬個請求和每秒400,000 GB的計算時間(computing time)。而對于超出免費套餐限額的所有請求，均按照0.00001667美元每GB每秒收費，這是市場上的***價格。在實際操作中，免費套餐完全足夠您在開始被計費之前完成自己應用的調試。那些分配給用戶的資源(內存和CPU)將被視為一個整體單元進行計費，畢竟它們都是等比例增長的。如果您在自己的Lambda功能函數中使用到了其他的AWS服務，那么就可能會產生額外的費用。
Azure的計費方式與Lambda相同，也提供免費的套餐。不過對于超出部分，它按照0.000016美元每GB每秒收費。可見，Azure平臺的重負載成本略低于Lambda，而平均負載則與Lambda相同。不過，Microsoft更希望對內存的使用量進行計費，而不是簡單地一次性分配給用戶。另外，對于用戶可能用到Windows和SQL，Azure也提供了較低的價格。
可見，對于上述兩個平臺的選擇，實際上取決于您所使用的環境，而非您所承擔的成本。
GCF的免費套餐為：每月200萬個請求和每秒400,000 GB的計算時間。而對于超出免費套餐限額的所有請求，均按照0.0000004美元每GB每秒收費，包括網絡流量。因此，對于那些運行耗時的功能函數或請求量大的應用來說，Google Cloud Functions的費用明顯更高。上面也提到過，GCF會對分配給用戶的內存和CPU進行分別計費。
IBM擁有與Lambda及Azure相同的免費套餐，而對于超出免費套餐限額的所有請求，均按照0.000017美元每GB每秒收費。在計費方面，IBM OpenWhisk會記錄功能函數處于活動狀態時所消費的資源。
總而言之，AWS Lambda的定價適中;Azure的費用取決于所使用的CPU和內存;而對于Windows環境來說，Azure提供了***的價位。
支持的編程語言
為了讓用戶可以在托管的環境中運行自己的應用，FaaS提供商往往會在它們所提供的共有云環境里支持多種語言。
Lambda涵蓋了廣泛的編程語言，其中包括：Node.js runtime、Python、Java和其他編譯語言、以及.net語言(C#、Visual Basic和F#)。
Azure Functions顯然將重點放在了Microsoft的語言系列上，包括：Node.js runtime、C#、F#、Python、PHP、Bash、Batch和PowerShell、以及編譯JavaScript語言。
Google Cloud Functions過去只支持JavaScript，如今它已宣布正在測試支持許多其他的語言。不過就目前而言，GCF看起來并不是一個非?？煽康倪x擇。
IBM目前支持Node.js runtime、Swift、Java、PHP和Python。同時，它可以與任何帶有Docker容器的編程語言相集成。
上圖便是四大提供商所支持的語言列表。目前，GCF的支持類型最為有限。
功能函數觸發類型
主流提供商都能夠提供用于調用功能函數的，可配置的動態觸發器類型。它們支持按需調用分別調度函數，并與其他云服務相集成。您可以在不同提供商的用戶文檔中找到相關的詳細信息。
Lambda和Azure通過API提供已配置的觸發器類型。其中，AWS使用API網關作為API觸發器，通過Amazon S3作為基于文件的觸發器，以及通過DynamoDB來執行動態觸發。而Azure則建議使用其他的Microsoft服務、Azure事件中心和Azure存儲，來實現Web API觸發和計劃性調用。
GCF服務在其文檔中提供了各種能夠支持的觸發器列表。GCF觸發器類型的主要功能是：讓用戶的應用能與任何Google服務相集成，進而支持cloud Pub/Sub與各種HTTP回調。
IBM雖然并沒有在觸發方面與太多的第三方服務相集成，但是它仍然能夠支持許多常見的觸發器類型，包括：基于瀏覽器的HTTP工具調用、以及計劃性的觸發。
因此，若是要根據觸發方法來選擇提供商的話，Azure與Lambda應該是***選擇，而如果您需要通過Google服務來觸發某些功能函數的話，也可以選擇GCF。
執行時間(Execution Time)和并發數
與功能函數調用相關的另一個重要方面是：執行時間和并發數。此處并發數表示在一段時間內并行執行不同功能函數的數量。
如上圖所示，Google具有***并發數，而AWS Lambda卻有著最長執行時間。
Lambda的并發數為1,000個，其最長執行時間為15分鐘。用戶既可以為整個帳戶，也能夠為單個功能函數配置并發數。
Azure為單個應用提供了***的并發率，但是單個功能函數的最長執行時間被限制為5分鐘。如果用戶需要長達10分鐘則需要進行升級。
GCF只允許對HTTP觸發器類型進行***次的調用。而對于其他觸發方法，其并發數與Lambda相同，也是一次只能執行1,000個。它將單個功能函數的執行時間限制為60秒，在升級后可達9分鐘。值得一提的是：AWS Lambda計算的是單個帳戶的并發數，而GCF統計的是項目中的并發數。這意味著：在AWS上，您只能運行一個具有1,000個并發量的調用函數，而在GCF上，您可以使用同一個并發來運行多個功能函數。
IBM對于單個功能函數的調用并不限制時間，但它的并發率并不清楚，當然也不作保證。
因此，如果您希望功能函數的性能平穩，則選擇Lambda、GCF和Azure皆可。如果您注重長時間的調用，那么Lambda和IBM將是更好的選擇。
部署方法
各大提供商的部署方法似乎沒有什么區別。在無服務器框架的部署中，開發人員通常會使用serverless.yml來配置功能函數，然后將函數的代碼打包到Zip文件中，進而推送到服務器上。
Lambda能夠更新用戶應用中的每一個單獨的功能函數;而Azure、GCF和IBM服務則傾向于通過插件來解析serverless.yml，當然它們上傳各種資源的順序也略有不同。
監控和記錄
由于所有的架構都是由提供商進行管理的，因此為了獲悉應用程序的狀態和參數指標，它們需要為每一項服務提供監控和日志記錄的工具。籍此，用戶也能夠概覽到資源的使用與分配、出現的錯誤、以及相應的監視日志等方面。
Amazon自家的Lambda服務工具 – CloudWatch，能夠觀察功能函數的調用與日志。但是，由于CloudWatch是一項付費的服務，因此也受到了一些批評。其他主流提供商的類似服務包括：Microsoft Monitor、Google Stackdriver、以及IBM logging and monitoring。
Amazon的另一項服務X-Ray，是一種監控多種AWS服務的分布式跟蹤系統。不過，它的主要用途是監控微服務類型的應用，而不是功能函數。下面是一些針對無服務器應用監視的第三方工具：
- Dashbird是一項免費的AWS監控服務，提供CloudWatch之外的功能，并有著更加友好的用戶界面。
- OpenTracing是一種獨立于提供商的監控服務，而并非工具。OpenTracing支持9種語言，包括：Go、JavaScript、Java、Python、Ruby、PHP、Objective-C、C++和C#。
- Thundra聚焦于JavaScript，能夠與AWS X-Ray相集成，并在其基礎上呈現監控和日志記錄。
其他備選考慮
如上所述，四大主流無服務器架構提供商都能提供“勢均力敵”的基礎服務。只是AWS Lambda和Azure Functions更為完整和多元化一些。因此您在選擇時，更多地取決于所用到的環境、對于編程語言和社區的支持要求。
如果您不想被上述主流共有云提供商的框架所“綁架”，需要對自己的產品具有更多控制的話，可以考慮如下開源的無服務器框架：
- IronFunctions是一款開源的無服務器計算平臺，它同時支持私有、共有和混合云。其背后的理念是：為開發人員提供可在任何地方運行的無服務器平臺。IronFunctions使用的是Go語言，這在其他無服務器選項中并不常見。
- Oracle Fn Project也是一款開源的無服務器平臺，它原生于容器化(containerization)、且獨立于語言和云環境。與IronFunctions類似，Fn Project也可被用于私有、共有和混合云。
- Kubeless是由Kubernetes提供的容器驅動的原生無服務器架構。它能被用于自動化容器化應用的部署、管理和擴展。
- Firebase是移動應用開發的后端平臺，由Google提供托管架構。它能夠與Google的其他云服務順利集成，當然也最適合于Google的產品。
- Webtask是一款完全免費的FaaS平臺。它最適合于不需要繁重后端的移動應用，并能支持各種集成方案。
原文標題：Comparing Serverless Architecture Providers: AWS, Azure, Google, IBM, and Other FaaS Vendors，作者：Ihor Lobastov
【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】
