4007654355
NEWS
网站建设、网站制作、网站设计等相关资讯

无服务器应用程序开发的最新趋势

日期:2024-04-03 访问:465次 作者:admin

作者 | Ankur Kumar译者 | 刘志勇策划 | marsxxl

无服务器计算已经在主流应用中站稳脚跟,并开始出现在企业组织的技术路线图中。研究公司和业界领袖预测,在 2022 年无服务器的采用将会有更大的发展势头。虽然在存储、计算和网络等基础设施要素方面,无服务器有不同的方面,但是本文主要讨论无服务器应用开发的最新趋势。

随着人们越来越关注将运营方面的工作交给云服务提供商或以平台为中心的解决方案,无服务器架构将作为一种 功能即服务(Function-as-a-Service,FaaS)的编程风格(见下图)继续在微服务应用开发中发挥关键作用。无服务器应用开发的最新趋势将继续随着新出现的模式、技术产品和云原生社区的创新而发展。

无服务器计算是一项关键技术,正在重新定义企业构建、消费以及整合云原生应用的方式。“无服务器架构使开发人员能够专注于他们应该做的事情——编写代码,优化应用设计——为业务敏捷性让路。”

——Gartner:《CIO 无服务器计算指南》( CIO’s Guide for Serverless Computing )

趋势一:抽象是无服务器应用开发的新口号

无服务器架构 在开发者中普及了 FaaS 的编程风格;它通过独立构建和部署的功能来帮助开发者专注解决核心业务问题,这些功能对某一事件作出响应,运行业务流程,在此过程中生成其他事件,并将规模缩小到零。

——ThoughtWorks Technology Radar

从历史上看,无服务器产品已经被 亚马逊云科技 Lambda、Microsoft Azure Functions、Google Cloud Functions、Alibaba Cloud Function Compute 和其他云提供商等无服务器平台普及推广。这些平台提供了对核心基础设施的抽象,并与云托管服务本地集成。

随着多云部署的兴起,下一个趋势是在公共云服务提供商的产品之上建立一个抽象层(见下图)的演变。这将有助于将业务服务与云提供商的专有技术脱钩,并且可以根据服务的具体要求灵活选择无服务器平台的提供商。

提供一个无服务器应用开发层作为另一个抽象层,在构建基于功能即服务的应用时提供一个供应商中立的接口,从而有助于应用开发生命周期。

企业可以组建一个平台工程团队构建无服务器应用开发层,也可以使用开箱即用的解决方案。

无服务器抽象层在无服务器平台之上提供开发者平台

趋势二——容器和无服务器作为基础平台

容器和无服务器将成为应用平台的基础设施。 

——Gartner:《2022 年云计算和边缘计算规划指南》( 2022 Planning Guide for Cloud & Edge Computing )

与无服务器功能相比,容器被认为是更粗粒度的,并被当作一种替代选择。

最近的趋势是两个世界力量的结合,因为无服务器平台已经开始支持容器来打包和部署应用程序代码(主要的无服务器提供商及其对容器的支持见下表)。

趋势三:开源在构建无服务器平台中的崛起

开源云原生开发以服务网格和无服务器为目标。 

——Forrester Research

虽然亚马逊云科技 Lambda 使用其专有技术来实现无服务器,但新兴的参与者正在使用开源技术来构建无服务器平台。

这有助于区分他们作为提供商中立的能力,以及他们对更加开放和透明的倾向。此外,在混合云部署模式中,它有助于为使用相同开源技术的企业内部无服务器平台建立一个一致的方法。

云服务提供商的无服务器平台

与可观察性相关的功能(OpenTracing、OpenTelemetry、Grafana 和 Jaeger)也被无服务器平台广泛集成。

开源为无服务器的企业级混合云平台提供了许多选择。主要框架有:Apache OpenWhisk、OpenFaaS、Knative、Fn Project、Kubeless(由 VMWare 归档)和 Fission。

无服务器的开源框架

趋势四:无服务器作为端到端应用开发平台的推动者

我们预测 2022 年是无服务器最终达到临界质量的一年,接近主流接受度,成为目前软件开发的最佳实践模式。 

——2021 年 InfoQ 《趋势报告》( Trends Report 2021 )

不仅主要的云服务提供商(亚马逊云科技、Azure 和 Google Cloud)在推动无服务器的采用,而且新的参与者也在简化无服务器的采用。有趣的是,这些参与者中的大多数可能在幕后使用公共云服务提供商,或者通过在供应商之上添加抽象层,让最终用户选择云供应商。

与 2021 年类似,今年将继续看到新的功能或产品发布,如:亚马逊云科技扩展 SAM 平台(SAM 加速 等新功能),Azure 扩展其 无服务器平台,以及 Cloudflare 扩展 JAMStack 的 Workers 和 Pages 等无服务器功能。

这些关键研究表明,表明提供数据库、应用框架、GraphQL 等能力的技术服务提供商正专注于推出具有无服务器产品的端到端应用开发平台的趋势。

Akka Serverless(2021 年 6 月推出):使用托管 Serverless 平台构建实时应用程序。

MongoDB Realm(2021 年 6 月推出):利用 MongoDB 数据库作为一个集成平台来构建应用程序。

Nimbella Service Platform 被 DigitalOcean 收购,他们宣布将在 2022 年推出测试版产品。

Cloudflare 通过 Cloudflare Workers 提供无服务器计算服务,并不断建立新的功能,如 Workers Durable Objects,这些新功能在 2021 年普遍用于构建有状态的无服务器应用程序。

趋势五:边缘的无服务器将使计算更贴近终端用户

无服务器边缘计算平台利用 5G/6G 的毫秒延迟和人工智能优化,将促进远程应用的云连续。——IBM 无服务器预测

新的应用程序将开始被设计为利用边缘的计算、存储和网络能力。这将涵盖云 / 边缘连续体中应用程序的整个生命周期。

随着使用边缘计算的延迟降低(<1-5 毫秒),无服务器应用的性能、可扩展性和可用性预期将更高。突发性工作负载(遵循工作负载模式来处理突然和意外的负载高峰)将继续成为无服务器应用程序的执行趋势。

其他有趣的观察和发现

根据 Datadog 的《无服务器状态》(State of Serverless)、IBM 和 IEEE Research 的结论,亚马逊云科技 Lambda 仍然是使用最广泛的功能即服务(FaaS)产品。

根据 IEEE 对 89 个以上应用程序的数据研究,典型的无服务器应用程序使用托管云服务,具体趋势表明在以下领域的使用情况:云存储(61%)、云数据库(约 47%)和云消息传递(约 38%)。

托管云服务的无服务器应用程序使用情况

Python 和 JaScript 是无服务器应用开发中最流行的语言(约 30%~40%),其次是 Ja(约 10%~15%)、C/C++(约 10%~15%)、Golang(约 4%~5%)和 Ruby(约 1%~2%)。

无服务器应用主要用于 API、流 / 异步处理、批处理作业、工作流处理和操作任务。

无服务器框架是使用亚马逊云科技 CloudFormation 部署亚马逊云科技 Lambda 应用的主要方式,其次是亚马逊云科技 CloudFormation、亚马逊云科技 CDK、亚马逊云科技 SAM。

总而言之,无服务器将继续成为云供应商的重点领域,这些趋势表明,新的创新产品将继续在以下领域出现:功能即服务、后台即服务、数据库等领域即服务、存储即服务、Kubernetes 和容器编排即服务、机器学习即服务等等。

无服务器应用程序开发的最新趋势摘要

参考:

https://medium.com/bbc-design-engineering/bbc-online-a-year-with-serverless-ffc2ae474277

https://thechief.io/c/editorial/ten-serverless-frameworks-watch-2021/

https://www.datadoghq.com/state-of-serverless/

https://github.com/OWASP/Serverless-Top-10-Project

https://www.forrester.com/report/The-Forrester-We-FunctionAsAService-Platforms-Q1-2021/RES161673

https://www.gartner.com/en/documents/3984294

原文链接:

https://www.infoq.cn/link?target=https%3A%2F%2Fvedcraft.com%2Ftech-trends%2Fthe-latest-trends-in-serverless-application-development

点击底部阅读原文访问 InfoQ 官网,获取更多精彩内容!

今日好文推荐

95后百度员工对领导不满,删改公司数据库被判刑;微软在美取消竞业协议;TikTok中国管理团队与海外员工冲突引发离职潮 |Q资讯

GitHub官宣“报废”Atom编辑器,创始团队不甘心表示正用Rust重写

印度萌新令人绝望的操作:提交PR“轰炸”近40万开发者,GitHub负责?

是 Rust 太难了,还是主流编程本来就这么折磨人?

点个在看少个 bug👇