Serverless

阿里云研究员叔同:Serverless 正当时!

拟墨画扇 提交于 2020-12-12 14:55:08
作者 | 叔同 来源 | Serverless 公众号 导读: Serverless 将开发人员从繁重的手动资源管理和性能优化中解放出来,就像数十年前汇编语言演变到高级语言的过程一样,云计算生产力再一次发生变革。Serverless 的核心价值是什么?阿里云发布了哪些 Serverless 生态产品,各有什么特别之处?阿里云函数计算的表现如何?阿里云研究员叔同将通过本文分享阿里布局 Serverless 的历程和决心。 引言 早在 2009 年,伯克利曾预测云计算将会得到蓬勃发展。近乎无限的云端计算资源,客户无需自建机房,按需要付费成为可能,企业在 IT 方面的投入显著降低,云计算所释放出的技术红利让越来越多的企业客户从云下搬到了云上。 然而,大部分客户在使用云服务时,仍然要面对复杂的运维、较高的闲置资源、无法做到真正按需付费,云计算的优势并未发挥到极致。 2015 年 AWS 推出了 Lambda 服务,2017 年阿里云推出了函数计算 FC,2019 年伯克利再次预测 Serverless 将取代Serverful 计算;由此,Serverless 引发业内的广泛关注。 Serverless 将开发人员从繁重的手动资源管理和性能优化中解放出来,就像数十年前汇编语言演变到高级语言的过程一样,云计算生产力再一次发生变革。与其说 Serverless 是云计算的升华,不如说

如何无缝迁移 SpringCloud/Dubbo 应用到 Serverless 架构

时光总嘲笑我的痴心妄想 提交于 2020-12-12 14:54:50
作者 | 行松 阿里巴巴云原生团队 来源 | Serverless 公众号,整理自 《Serverless 技术公开课》 背景 通过前面几节课程的学习,相信大家对于 SAE 平台已经有了一定的了解,SAE 基于 IaaS 层资源构建的一款 Serverles 应用托管产品,免除了客户很多复杂的运维工作,开箱即用、按用量付费;并且提供了丰富的 Open API 可以很容易地与其他平台做集成。 本文将为大家介绍 SAE 在微服务方面的一些能力,SAE 产品把 Serverless 技术和微服务做了很好的结合,天然支持 Java 微服务应用的托管和服务治理,对 SpringCloud/Dubbo 微服务应用能够在只修改配置和依赖,不修改代码的情况下迁移到 SAE 上,并提供服务治理能力,比如基于租户的微服务隔离环境、服务列表、无损下线、离群摘除、应用监控以及调用链分析等。 本次课程分为三部分来介绍,分别介绍微服务应用迁移到 SAE 的优势,如何迁移 SpringCloud/Dubbo 应用到 SAE 上,以及针对 SpringCloud 应用迁移的实践演示。 迁移到 SAE 的优势 在介绍迁移之前,先介绍下 SpringCloud/Dubbo 应用迁移到 SAE 的优势: SAE 内置注册中心: 所有用户共享注册中心组件,SAE 帮助用户运维,这就节省了用户的部署、运维成本

无服务计算应用场景探讨及 FaaS 应用实战

一世执手 提交于 2020-12-12 07:46:49
作者 | 宋文龙(闻可) 阿里云全球技术服务部高级交付专家 来源 | Serverless 公众号 什么是无服务计算 无服务器计算(Serverless Computing)在构建和运行应用时无需管理服务器等基础设施。它描述了一个细粒度的部署模型,在该模型中,应用被拆解为一个或多个细颗粒度的函数,在云端托管环境中被触发运行,然后根据需要执行、扩展容量并且计费。各大云厂商 Amazon、微软、Google、IBM、阿里云、腾讯云、华为云相继推出 Serverless 产品。 无服务计算本身是一个概念或者理论模型,落地到具体技术上主要有函数即服务(FaaS)以及后端即服务(BaaS)两种形式,阿里云提供函数即服务 FaaS 产品。 阿里云对于 FaaS 的定义如下: 函数计算是事件驱动的全托管计算服务。使用函数计算,您无需采购与管理服务器等基础设施,只需编写并上传代码。函数计算为您准备好计算资源,弹性地、可靠地运行任务,并提供日志查询、性能监控和报警等功能。 关于 FaaS 的详细介绍 官方文档 已经讲的很清楚,本文不再赘述。本文重点讨论无服务计算的应用场景以及应用实践。 无服务计算应用场景 1. 无服务计算的优势 无服务计算有很多优点,个人认为其中最主要的有三点: 使用无服务计算,用户无需考虑基础设施,可以更加专注于业务逻辑; 无服务计算支持弹性伸缩,按需使用,按量计费

无服务计算应用场景探讨及 FaaS 应用实战

你。 提交于 2020-12-12 01:42:20
简介: 无服务计算本身是一个概念或者理论模型,落地到具体技术上主要有函数即服务(FaaS)以及后端即服务(BaaS)两种形式,阿里云提供函数即服务 FaaS 产品。 作者 | 宋文龙(闻可) 阿里云全球技术服务部高级交付专家 什么是无服务计算 无服务器计算(Serverless Computing)在构建和运行应用时无需管理服务器等基础设施。它描述了一个细粒度的部署模型,在该模型中,应用被拆解为一个或多个细颗粒度的函数,在云端托管环境中被触发运行,然后根据需要执行、扩展容量并且计费。各大云厂商 Amazon、微软、Google、IBM、阿里云、腾讯云、华为云相继推出 Serverless 产品。 无服务计算本身是一个概念或者理论模型,落地到具体技术上主要有函数即服务(FaaS)以及后端即服务(BaaS)两种形式,阿里云提供函数即服务 FaaS 产品。 阿里云对于 FaaS 的定义如下: 函数计算是事件驱动的全托管计算服务。使用函数计算,您无需采购与管理服务器等基础设施,只需编写并上传代码。函数计算为您准备好计算资源,弹性地、可靠地运行任务,并提供日志查询、性能监控和报警等功能。 关于 FaaS 的详细介绍 官方文档 已经讲的很清楚,本文不再赘述。本文重点讨论无服务计算的应用场景以及应用实践。 无服务计算应用场景 1. 无服务计算的优势 无服务计算有很多优点

无服务计算应用场景探讨及 FaaS 应用实战

佐手、 提交于 2020-12-11 23:58:35
作者 | 宋文龙(闻可) 阿里云全球技术服务部高级交付专家 来源 | Serverless 公众号 什么是无服务计算 无服务器计算(Serverless Computing)在构建和运行应用时无需管理服务器等基础设施。它描述了一个细粒度的部署模型,在该模型中,应用被拆解为一个或多个细颗粒度的函数,在云端托管环境中被触发运行,然后根据需要执行、扩展容量并且计费。各大云厂商 Amazon、微软、Google、IBM、阿里云、腾讯云、华为云相继推出 Serverless 产品。 无服务计算本身是一个概念或者理论模型,落地到具体技术上主要有函数即服务(FaaS)以及后端即服务(BaaS)两种形式,阿里云提供函数即服务 FaaS 产品。 阿里云对于 FaaS 的定义如下: 函数计算是事件驱动的全托管计算服务。使用函数计算,您无需采购与管理服务器等基础设施,只需编写并上传代码。函数计算为您准备好计算资源,弹性地、可靠地运行任务,并提供日志查询、性能监控和报警等功能。 关于 FaaS 的详细介绍 官方文档 已经讲的很清楚,本文不再赘述。本文重点讨论无服务计算的应用场景以及应用实践。 无服务计算应用场景 1. 无服务计算的优势 无服务计算有很多优点,个人认为其中最主要的有三点: 使用无服务计算,用户无需考虑基础设施,可以更加专注于业务逻辑; 无服务计算支持弹性伸缩,按需使用,按量计费

2020 年国内 Serverless 用户规模:阿里云占比第一,达 66%

被刻印的时光 ゝ 提交于 2020-12-11 22:34:16
来源 | Serverless 公众号 在中国信息通信研究院重磅发布的国内首个《云原生用户调查报告》中,阿里云 Serverless 产品凭借在双十一的技术锤炼和丰富的应用实践, 在国内 Serverless 用户规模的占比达到 66%,远超其他云厂商总和,被认为是国内 Serverless 用户的首选 。 阿里云函数计算(简称 FC):用户规模最大、应用最广泛 阿里云是最早提供 Serverless 计算服务的云计算厂商。函数计算(简称 FC)是用户规模最大、应用最广泛的 Serverless 产品,也是首个支持预留/按量实例混合伸缩和预付费模式的 Serverless 产品 。函数计算 FC 支撑超过百万函数,月调用数千亿次,50ms 冷启动,3ms 热恢复,百毫秒极致弹性,稳定支撑阿里巴巴 双11 千万级 QPS 峰值。在今年 7 月信通院可信云大会上,阿里云函数计算 FC 以 21 项测试全部满分的成绩首批通过可信云函数即服务认证。 阿里云致力于打造领先的 Serverless 开发者生态 。函数计算 FC 提供了完备的后端云服务和开发者工具,如事件总线 EventBridge、Serverless 工作流、开发者框架、命令行工具、Web IDE 等,从开发者体验出发,推出 Serverless-tools 与 Serverless 应用中心,打造更加开放、标准

Why does Serverless produce an Invalid Cross-device link Error when trying to package or deploy?

回眸只為那壹抹淺笑 提交于 2020-12-09 09:57:02
问题 When running either command: sudo serverless package or sudo serverless deploy I get the following traceback: Error: ERROR: Exception: Traceback (most recent call last): File “/var/lang/lib/python3.6/shutil.py”, line 550, in move os.rename(src, real_dst) OSError: [Errno 18] Invalid cross-device link: ‘/tmp/pip-target-wqc5grcw/lib/python/setuptools’ -> ‘/var/task/setuptools’ During handling of the above exception, another exception occurred: Traceback (most recent call last): File “/var/lang

Why does Serverless produce an Invalid Cross-device link Error when trying to package or deploy?

蹲街弑〆低调 提交于 2020-12-09 09:56:59
问题 When running either command: sudo serverless package or sudo serverless deploy I get the following traceback: Error: ERROR: Exception: Traceback (most recent call last): File “/var/lang/lib/python3.6/shutil.py”, line 550, in move os.rename(src, real_dst) OSError: [Errno 18] Invalid cross-device link: ‘/tmp/pip-target-wqc5grcw/lib/python/setuptools’ -> ‘/var/task/setuptools’ During handling of the above exception, another exception occurred: Traceback (most recent call last): File “/var/lang

云原生应用架构转型不好做?阿里云这个平台让你一步到位

混江龙づ霸主 提交于 2020-12-08 11:48:05
云原生实践带来的挑战 阿里云云原生为企业提供了完善的容器服务、函数计算、微服务体系、中间件体系。每个服务都有伸缩性、弹性和组合性,通过产品选择或组合搭建,能轻松完成应用与运行环境解耦,和传统应用研发模式具有较大差异。从传统研发模式过渡到云原生时代,抑或传统应用和云原生长期并存过程中,云原生应用的实现、集成、部署、运维都面临较大的挑战。 1.存量应用与云原生应用长期并存的整合问题 虽然云原生可以覆盖绝大部分应用场景,甚至以往比较难解决的问题在云原生下都可迎刃而解,如营销场景的应用。但有些应用场景在云原生下并无决定性优势,且存在迁移成本,加之传统应用在系统架构上的约束,这些将导致存量传统应用将和云原生应用长期并存。如何整合这两种应用的研发链路,以及基础设施层面的互联互通,是云原生实践带来的一个挑战。 2.研发环境的成熟度问题 云原生新应用的实践或存量应用的云化,不仅仅是基础设施和平台的变化,在架构设计、开发方式、测试联调、部署维护等各阶段和各方面都要基于云的特点做出相应调整。传统线下IDE工具链将无能为力,在DevOps这条工具链上,需要一个集成度高、操作路径短的研发环境。 3.研发模式、组织阵型与云原生的适配问题 云原生通常以微服务架构进行服务开发,函数计算更细粒度到函数级别。松耦合的架构方式会减轻因需求变更导致的系统迭代成本,并加快交付速度。微服务使得单个服务的开发团队更小

云原生应用架构转型不好做?阿里云这个平台让你一步到位!

我怕爱的太早我们不能终老 提交于 2020-12-08 11:46:05
云原生实践带来的挑战 阿里云云原生为企业提供了完善的容器服务、函数计算、微服务体系、中间件体系。每个服务都有伸缩性、弹性和组合性,通过产品选择或组合搭建,能轻松完成应用与运行环境解耦,和传统应用研发模式具有较大差异。从传统研发模式过渡到云原生时代,抑或传统应用和云原生长期并存过程中,云原生应用的实现、集成、部署、运维都面临较大的挑战。 1.存量应用与云原生应用长期并存的整合问题 虽然云原生可以覆盖绝大部分应用场景,甚至以往比较难解决的问题在云原生下都可迎刃而解,如营销场景的应用。但有些应用场景在云原生下并无决定性优势,且存在迁移成本,加之传统应用在系统架构上的约束,这些将导致存量传统应用将和云原生应用长期并存。如何整合这两种应用的研发链路,以及基础设施层面的互联互通,是云原生实践带来的一个挑战。 2.研发环境的成熟度问题 云原生新应用的实践或存量应用的云化,不仅仅是基础设施和平台的变化,在架构设计、开发方式、测试联调、部署维护等各阶段和各方面都要基于云的特点做出相应调整。传统线下 IDE 工具链将无能为力,在 DevOps 这条工具链上,需要一个集成度高、操作路径短的研发环境。 3.研发模式、组织阵型与云原生的适配问题 云原生通常以微服务架构进行服务开发,函数计算更细粒度到函数级别。松耦合的架构方式会减轻因需求变更导致的系统迭代成本,并加快交付速度。微服务使得单个服务的开发团队更小