这将对在Kubernetes上运行的所有无服务器框架进行比较。
术语“无服务器”已经成为AWS Lambda的同义词。与AWS解耦有两个好处;它避免了锁定,提高了灵活性。
所谓的无服务器,是一组技术和完全抽象底层硬件的技术。显然,这些函数仍然运行在某个“服务器”上,但重点是我们并不关心。开发人员只需要将代码作为函数提供。然后通过API使用或使用函数,通常是REST,但也通过消息总线技术(Kafka, Kinesis, Nats, SQS等)。
这为Kubernetes平台提供了一个无服务器框架的比较和建议。
编辑:
- v1 02/09/18
- v2 02/09/18: OpenFaas信息的主要编辑感谢@alexellisuk, Richard Gee, @kenfdev。由于@sebgoa,从比较表中删除了Serverless。
- v3 10/09/18:编辑关于Fn项目,感谢@delabassee。
比较表
下面的表格提供了k8s的不同无服务器框架的高级比较。它们被分为流行度、稳定性、工具、技术和可用性。
像受欢迎程度这样的观点的问题在于它很难量化。我们不得不求助于代理人。例如,我很感兴趣的是每天有多少人在使用这个框架。但是很难找到这些数字,所以我们使用Github星数或谷歌搜索等代理度量。它们表示为。有关项目受欢迎程度的更多信息,请参阅此处。
因此,请注意,这些指标中的许多都是粗略估计。单个框架的表现可能比实际情况好,也可能比实际情况差。阅读时要对所有的证据和特征有一个整体的看法。
比较/框架 | OpenFaas | OpenWhisk | Kubeless | Fission | IronFunctions | Fn |
---|---|---|---|---|---|---|
流行度(Github Stars) | 20k | 5.3k | 6.5k | 6.1k | 2.9k | 4.9 |
流行 (相关谷 歌趋势 100 means most popular) |
37 | 58 | 24 | N/A (conflicts with fission) |
N/A (conflicts with serverless) |
3 |
流行度 (总StackOverflow posts) |
21 | 359 | 15 | 2 | 5 | 9 |
稳定度(Contributors) | 157 | 188 | 101 | 144 | 32 | 84 |
稳定度(Contributors > 10 Commits) | 10 | 33 | 7 | 6 | 9 | 19 |
稳定度 (Corporate Backer) | VMWare (1) | IBM (Apache Foundation) (3) | Bitnami | Platform9 | https://iron.io | Oracle |
稳定度 (Started) |
Dec 2016 | Feb 2016 | Nov 2016 | Aug 2016 | Feb 2016 | May 2016 |
稳定度( 开发语言) |
Go | Scala | Go | Go | Go | Go |
工具(打包 机制) |
Docker container | Docker container |
Docker container |
Docker container |
Docker | Docker |
工具 ( k8s部 署功能) |
Manifest with custom yaml | Manifest with custom yaml | Manifest |
Manifest with custom yaml |
Proprietary | Proprietary |
工具( 无服务 器部署) |
Yes (WIP) | Yes | Yes | No | No | Yes |
技术( 底层 技术) |
Alertmanager / Prometheus, Nats | CouchDB, Kafka, Nginx, Redis, Zookeeper |
None (optional Nats or Kafka) |
fluentd (optional Nats) |
Postgres, Redis | DB (sqlite3, PostgreSQL, MySQL), MQ (Bolt, Redis), Prometheus |
可用性 (Worked out of the box?) |
Yes | Yes |
No (serverless plugin failed) |
Yes (but |
Didn’t try | Didn’t try |
可用性 (文档质量) |
Good | Good |
(没有 很好的 组织) |
(组织不佳, 导航奇怪,文件缺失) |
(组织不佳) |
Good |
可用性 (Slack channel?) |
Yes but through email | Yes |
Yes (#kubeless channel of the k8s slack: |
Yes | Yes | Yes |
- 来自VMWare的开发团队全职工作在OpenFaas上。
- 包括无服务器,因为建议使用SDK。
- 用于IBM的云功能产品中
Serverless框架建议
用这个表做比较,我可以推荐:
- 使用无服务器框架作为软件开发工具包(SDK)
- 使用OpenFaas或OpenWhisk作为k8s上函数的编排器。
- OpenFaas是成熟的、易于使用和可扩展的,但是与OpenWhisk相比,核心项目上的活动开发人员更少(根据我对活动开发人员的定义),也更不受欢迎(根据我对流行度指标的选择)。
- OpenWhisk是成熟的,有许多活跃的开发人员支持,很流行,但是很复杂,用Scala编写,由IBM/Apache支持(可能是好事也可能是坏事,取决于你的看法)
最终的技术堆栈看起来如下:
无服务器框架的附加建议允许开发人员选择是要部署到lambda还是部署到k8s上的无服务器平台。如果lambda上已经有函数,这有助于迁移。
框架的笔记
OpenWhisk
OpenWhisk是一个成熟的无服务器框架,由Apache基金会和IBM支持。OpenWhisk构成了IBM云功能服务的基础。主要的提交者是IBM员工。
有许多底层组件,这增加了复杂性。它利用了CouchDB, Kafka, Nginx, Redis和Zookeeper。好的一面是开发人员明确地关注于可伸缩性和弹性。缺点是开发人员和操作人员需要这些工具的工作知识。另一个缺点是,它们复制了Kubernetes等编曲中存在的特性(例如自动缩放)。函数最终被绑定到与框架一起运行的Docker容器中。
OpenWhisk可以使用Helm图表安装,但不幸的是需要一些手动干预。可以使用CLI或无服务器框架部署应用程序。普罗米修斯度量标准被导出。
OpenFaas
OpenFaas是一个流行的(根据我对流行程度的估计,不像OpenWhisk那么流行),易于使用的无服务器框架。它不像OpenWhisk那么流行,并且提交是基于个人的。VMWare雇佣了一个团队来全职从事OpenFaas的工作,此外还有个人贡献者在业余时间完成的伟大工作。一家名为OpenFaas Ltd.的公司已经在英国注册成立,尽管尚不清楚该公司与该项目有何关联。
OpenFaas的架构相对简单。API网关可以通过Kafka、SNS、CloudEvents、CRON和其他触发器同步或异步调用。异步调用由NATS流处理。自动caling是执行使用普罗米修斯和普罗米修斯Alertmanager;但谢天谢地,这似乎可以用Kubernetes的HorizontalPodAutoscaler替换出来。
完全支持的Kubernetes安装程序可通过Helm或kubectl,包括一个操作员允许使用的CRDs,即kubectl得到功能。也有一个Kubernetes操作员是WIP,但我发现这工作得很好。
可以使用CLI或无服务器框架(WIP)部署应用程序。还提供了一个“函数库”,一个用于OpenFaas的函数列表。普罗米修斯度量被导出出盒子。
OpenFaaS®是英国的注册商标
Kubeless
我对Kubeless非常感兴趣,它是Kubernetes的函数本机框架。它通过在Kubernetes中添加作为自定义资源定义(CRD)的“函数”的思想来工作。加上一些巧妙的代码,这意味着它将Kubernetes变成了一个函数机,而不像其他框架那样添加消息总线这样的复杂性。
我喜欢管理像标准Kubernetes对象这样的功能,这意味着所有常见的Kubernetes产品都可以开箱即用(Helm, Ark等)。
交互是通过标准的kubectl进行的,所以没有额外的工具,并且内置了无服务器支持。
听起来完美!
但不幸的是,它还不够成熟,不能用于生产中。社区不够大,文档不够完善(必须依赖于博客文章),无服务器支持存在bug,这意味着它不能在ek上工作。
考虑到这些积极的基础,我确信在未来6个月内这将成为事实上的Kubernetes无服务器框架。
Fission
裂变很有趣,因为它位于Kubeless和OpenWhisk之间。它严重依赖于Kubernetes的特性,但并没有完全集成。这种方法的好处是,它可以利用Kubernetes擅长的东西,比如自动伸缩,但在需要时做了一些不同的事情来获得更好的性能。例如,它有一个相当复杂的冷启动池机制。
它由Platform9支持,可以通过Helm安装。它使用fluxdb来处理状态,并提供FluentD用于登出。它使用Nats作为消息总线,Redis用于缓存。如您所见,其他框架不提供缓存和登出功能,尽管添加它相当简单。
裂变有一个很好的额外的叫做裂变工作流。这是一个允许开发人员组合函数的工具。函数式编程。这是一个非常有趣的方向,我很想知道可以用它来做些什么。
然而,很少有用户(只有两个堆栈溢出问题——这意味着它很容易使用吗?)和很少有真正的贡献者——只有6个人提交超过10个。有一些烦恼,但这主要是由于缺乏用户和开发人员。而且文档组织得很糟糕。这使得我们很难弄清楚框架是如何工作的。我也不喜欢代码如何负责模板和启动豆荚本身;这很可能在将来造成破损。最后,我对裂变建造者非常困惑。我不知道它们是什么,为什么需要它们。
而且,这个名字也很难搜索。
Fn
另一个争夺这个愚蠢名字桂冠的竞争者是Fn。它是开源的,但主要贡献者是为Oracle工作的。主要工作流程使用Fn CLI,但在底层函数使用Docker容器。在这篇博文中有一些信息,文档在这里。并且可以使用Helm部署框架组件。还有一个新添加的称为Fn Flow的功能,它编排了多个类似于OpenWhisk工作流的函数。
但最重要的区别是你工作的方式。Fn专注于易于使用,但这使得它非常武断。它提供热函数(所有其他框架也可以提供)和流函数(这更独特——不完全清楚如何与其他框架一起工作)。
它成立于2016年,这使得它和OpenWhisk一样古老,并且有相当数量的贡献者。尽管如此,我还是被大量强加给开发者的意见所困扰,这些意见并不适合Kubernetes(你不能用Kubernetes来部署afict)。这是我的要求,所以我没有尝试。然而,它与无服务器框架是兼容的,可以稍微减轻这一点。
IronFunctions
Iron Functions是由一家同名公司支持的。这增加了一些初始的复杂性,因为github readme将你重定向到“文档”,这实际上是Iron公司的主页面。如果你点击“docs”,就不会看到Iron Functions。真正的文档在存储库的docs目录中。
它是基于Docker的,像许多其他框架一样,一个有趣的特性是它对AWS Lambda函数提供了类似的支持。你可以从Lambda中获取代码,然后直接在Iron上运行;这对迁移来说很好。
不幸的是,它似乎不支持将清单部署到Kubernetes,就像Fn一样,而且它也不受无服务器框架的支持。这使我不敢去尝试。谷歌的流行趋势中也没有出现。
Severless Framework
我在文章中已经多次提到了这一点,因此它本身就值得一节。
它不是一个平台,它运行任何函数。它是一个无服务器的软件开发工具包。事实上,它本质上只是一种包装机制。但美妙之处在于,一旦以无服务器方式打包,您就可以将相同的代码部署到Lambda、谷歌Functions、Azure Functions、OpenWhisk、OpenFaas、Kubeless或Fn。
这种可移植性非常有吸引力。它允许开发人员以标准的方式构建他们的代码,但仍然允许标准、定价、特性设置或可用性来决定在哪里部署。
此外,它允许我们稍微推迟框架的选择。我之前提到过,我喜欢Kubeless关于Kubernetes的方向,但它还不够成熟。如果我们使用Serverless,那么我们现在就可以在OpenFaas或Lambda上构建代码,然后很容易地移植到Kubeless上。
唯一的缺点就是名字都很蠢。每一个。单身。时间。我必须加上“没有服务器的框架,而不是技术”。再加上受支持语言的数量有限。但除此之外,我认为这是最安全的选择。
Funktion
Funktion是红帽公司已经失效的解决方案。
本文:http://jiagoushi.pro/node/1487
讨论:请加入知识星球【首席架构师智库】或者微信【jiagoushi_pro】或者QQ【2898908662】
- 登录 发表评论
- 548 次浏览
最新内容
- 13 hours 27 minutes ago
- 13 hours 32 minutes ago
- 3 days 14 hours ago
- 4 days ago
- 5 days 14 hours ago
- 6 days 8 hours ago
- 6 days 8 hours ago
- 6 days 8 hours ago
- 6 days 8 hours ago
- 6 days 8 hours ago