|
|
51CTO旗下网站
|
|
移动端

各大Serverless架构提供商的六项服务较量

在面对众多云服务提供商,并需要将现有服务迁移到某个无服务器架构之前,我们需要对各大Serverless架构提供商进行比较与分析。

作者:陈峻编译来源:51CTO|2019-03-26 09:00

【大咖·来了 第7期】10月24日晚8点观看《智能导购对话机器人实践》

【51CTO.com快译】根据RightScale云服务状况报告2018版(请详见:https://www.rightscale.com/lp/state-of-the-cloud)显示,无服务器(Serverless)架构的市场渗透率已增至75%。而且,这个市场里的玩家,已不再局限于AWS Lambda或Azure Functions等主流提供商。不过,在面对众多云服务提供商,并需要将现有服务迁移到某个无服务器架构之前,您是否真正了解他们的不同之处?下面让我们一起来深入探究一番。

无服务器架构的发展历史

近十多年来,随着云技术在商业中的广泛采用,整个市场也得到了迅速发展。我们可以看到,每年都有新的应用开发方法的出现。从逻辑层面来看:那些使用IaaS(基础设施即服务)的企业,主要是通过租用服务器资源,来将其基础设施迁移到云端。但是他们的IT团队仍然需要去动手设置各种服务器。而随着PaaS(平台即服务)的出现,IT团队逐渐摆脱了对服务器的手动操作。PaaS提供商能够提供更为完整的应用程序栈,包括:由提供商所管理的、运行在云中的操作系统和数据库等。

各大Serverless架构提供商的较量

如上图所示,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年也扩充了不少。我们将这些提供商分为主流和备选两大类。主流类一般是在共有云上提供无服务器架构。下面,我们将对各大主流与备选提供商进行介绍与比较。

AWS Lambda

Amazon Web Services于2014年推出了此类FaaS产品。自发布以来,Lambda已经成为了无服务器架构的代名词。凭借着最广泛的服务类别,Lambda一直保持着市场的领先地位。其***的案例,莫过于Netflix的无服务器公有云应用。

Microsoft的Azure Functions

作为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 Cloud Functions(GCF)

作为四巨头之一,Google直到2017年才发布了其解决方案。虽然GCF的起步晚于Azure和Lambda,但是Google在2018年奋起直追,它解决了各种早期错误,并在其官网上进行了公示。

IBM Cloud Functions

作为无服务器领域的新手,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看起来并不是一个非常可靠的选择。

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 MonitorGoogle 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】

【责任编辑:庞桂玉 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

订阅专栏+更多

这就是5G

这就是5G

5G那些事儿
共15章 | armmay

115人订阅学习

16招轻松掌握PPT技巧

16招轻松掌握PPT技巧

GET职场加薪技能
共16章 | 晒书包

371人订阅学习

20个局域网建设改造案例

20个局域网建设改造案例

网络搭建技巧
共20章 | 捷哥CCIE

758人订阅学习

读 书 +更多

ASP快速建站全程实录

本书从一个网站制作过程入手,详细介绍基于ASP技术建设网站的全过程。全书共10章。第1章,网站制作规划与流程;第2章,IIS安装与调试;第3...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊

51CTO服务号

51CTO官微