容器之后的下一波浪潮?Amazon CTO谈无服务器计算

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
简介:

“我们也许再也不用为服务器分神了。”Amazon公司CTO Werner Vogels博士在上周于伦敦召开的AWS峰会上谈到无服务器计算的价值,“我们发现一场新的革命正在孕育,即应用程序正整体从服务器当中剥离出来,意味着只需代码即可实现运行。已经有相当一部分企业在进行应用程序拆分并替换其中的服务器部分,具体而言虚拟机与容器等运行平台都属于纯代码方案。”

容器之后的下一波浪潮?Amazon CTO谈无服务器计算 

Amazon公司CTO Werner Vogels博士在伦敦接受采访。

由于整个行业都开始考虑利用容器取代虚拟机,包括利用Amazon的ECS(即EC2容器服务)实现管理工作,那么随之而来的剥离潮流自然也在情理之中。当然,要让这一切成为现实,大家可能需要以更为开放的心态接纳云计算即托管平台——而非IaaS。

S3与DynamoDB等早期AWS服务方案并不要求用户使用虚拟机或者容器,Vogels表示。“如果大家回顾我们的DynamoDB设计思路,就会发现我们着眼于其它各类NoSQL数据库并发现其管理难度甚高。我们的最终目标就是承担起缓冲区管理以及连接池等任务,从而为用户提供一致的数据库性能表现。”

“在设计DynamoDB的同时,我们想到为什么不干脆为其提供所需性能水平的管理能力?用户可以向服务供应商提供自身需要的读取与写入操作强度,而我们则确保这一切都以稳定的性能表现完成。”他解释称。

这些早期服务并不允许大家直接运行代码,但Amazon公司于2014年11月启动的Lambda则完全改变了这一切。该项目最初作为一种利用JavaScript编写代码的方式存在,可由S3内的文件归档等事件所触发,但同时又潜在支持多种应用程序类型,并最终在发布后的这段时间内迎来显著演变。

如今的Lambda已经能够支持Java、Node.js以及Python,同时支持预定功能并可由事件进行触发,且可接入AWS VPC(即虚拟专有云)以实现对专有网络的访问。其代码存储容量上限已经由原本的5 GB提升至75 GB。Lambda还能够与负责构建API的API Gateway或者用于定义AWS资源组的CloudFormation等AWS服务顺畅对接。

“大家只需要编写代码,我们负责运行代码,”Vogels指出。“部署模式由代码实现。大家仍然需要进行版本控制。每项功能的运行只耗时数秒,或者最多数分钟。另外,每项功能都拥有单一线程与单一任务。大家仍然可以根据需求并发执行数万乃至数十万项Lambda功能。其计费模式不再基于每虚拟机每小时,而是按照特定时间段内的内存使用量以及所处理的请求数量进行计算,”Vogels表示。

但他在解释中回避了一个问题,即Lambda的使用方式相当复杂,绝不止上传代码那么简单。大家需要指定必要的内存容量以及特定功能的运行时长,一旦超出时间即会产生错误。然而,这项服务确实将虚拟机或容器以抽象形式从其运行基础中剥离了出来——事实上,在接下来的Lambda对话环节中,他表示该服务本身也是通过容器实现的。

容器之后的下一波浪潮?Amazon CTO谈无服务器计算 

配置AWS Lambda内存设置

Amazon公司并不是惟一提供此类服务的供应商。微软推出了Azure Functions,而谷歌则在自家云计算平台上拿出了Cloud Functions。

同样的趋势也开始出现在其它云平台上,微软、谷歌以及Salesforce都已经允许大家在无需管理虚拟机或者容器的前提下实现应用程序运行。谷歌方面的App Engine则始终遵循这样的起效方式。微软的Azure App Service帮助我们管理虚拟机,不过其实例并非完全抽象。

也就是说,“无服务器计算”通常是指那些负责承载由众多小型微服务类功能构成的应用——而非整体式应用程序。无服务器平台最为典型的使用方式就是用于与其它云服务相对接。这种能力对于云服务供应商而言非常重要,也许这也正好解释了其积极投向于其中的原因。举例来说,我们可以利用Lambda配合其它AWS服务。

“在无服务器计算中,大家不必为容器费心,而只需要编写应用代码。我们可将不同片段结合起来并加以整体管理。”Vogels指出。

正如分析师James Governor指出,无服务器是一种“对按需计算模式的自然总结”,意味着大家只需要在代码执行时付费,即“客户价值点”。

那么无服务器模式是否代表着未来的发展方向?其负面因素在于,用户对于代码运行方式的控制能力有所削弱,而且现有应用程序往往很难直接被移植至这种新兴模式。

即使大家热衷于无服务器模式,但从尝试到最终实现仍然是个漫长而艰难的过程,Vogels坦率地承认。尽管如此,在着手建立新的容器类项目之前,无服务器模式仍是一种值得考量的重要选项。






原文发布时间为:2016年7月14日 
本文作者:作者:赵东
本文来自云栖社区合作伙伴至顶网,了解相关信息可以关注至顶网。
相关实践学习
【文生图】一键部署Stable Diffusion基于函数计算
本实验教你如何在函数计算FC上从零开始部署Stable Diffusion来进行AI绘画创作,开启AIGC盲盒。函数计算提供一定的免费额度供用户使用。本实验答疑钉钉群:29290019867
建立 Serverless 思维
本课程包括: Serverless 应用引擎的概念, 为开发者带来的实际价值, 以及让您了解常见的 Serverless 架构模式
目录
相关文章
|
28天前
|
机器学习/深度学习 弹性计算 人工智能
阿里云服务器架构有啥区别?X86计算、Arm、GPU异构、裸金属和高性能计算对比
阿里云ECS涵盖x86、ARM、GPU/FPGA/ASIC、弹性裸金属及高性能计算等多种架构。x86架构采用Intel/AMD处理器,适用于广泛企业级应用;ARM架构低功耗,适合容器与微服务;GPU/FPGA/ASIC专为AI、图形处理设计;弹性裸金属提供物理机性能;高性能计算则针对大规模并行计算优化。
|
1月前
|
运维 Serverless 数据处理
Serverless架构通过提供更快的研发交付速度、降低成本、简化运维、优化资源利用、提供自动扩展能力、支持实时数据处理和快速原型开发等优势,为图像处理等计算密集型应用提供了一个高效、灵活且成本效益高的解决方案。
Serverless架构通过提供更快的研发交付速度、降低成本、简化运维、优化资源利用、提供自动扩展能力、支持实时数据处理和快速原型开发等优势,为图像处理等计算密集型应用提供了一个高效、灵活且成本效益高的解决方案。
98 1
|
1月前
|
运维 监控 Serverless
Serverless架构在图像处理等计算密集型应用中展现了显著的优势
Serverless架构在图像处理等计算密集型应用中展现了显著的优势
38 1
|
2月前
|
运维 Serverless 数据处理
Serverless架构通过提供更快的研发交付速度、降低成本、简化运维、优化资源利用、提供自动扩展能力、支持实时数据处理和快速原型开发等优势,为图像处理等计算密集型应用提供了一个高效、灵活且成本效益高的解决方案。
Serverless架构通过提供更快的研发交付速度、降低成本、简化运维、优化资源利用、提供自动扩展能力、支持实时数据处理和快速原型开发等优势,为图像处理等计算密集型应用提供了一个高效、灵活且成本效益高的解决方案。
63 3
|
2月前
|
存储 固态存储 安全
阿里云服务器X86计算架构解析与X86计算架构云服务器收费价格参考
阿里云服务器架构分为X86计算、Arm计算、高性能计算等多种架构,其中X86计算是用户选择最多的一种架构,本文将深入探讨阿里云X86计算架构的云服务器,包括其技术特性、适用场景、性能优势以及最新价格情况。
|
2月前
|
编解码 弹性计算 应用服务中间件
阿里云服务器Arm计算架构解析:Arm计算架构云服务器租用收费标准价格参考
阿里云服务器架构分为X86计算、Arm计算、高性能计算等多种架构,其中Arm计算架构以其低功耗、高效率的特点受到广泛关注。本文将深入解析阿里云Arm计算架构云服务器的技术特点、适用场景以及包年包月与按量付费的收费标准与最新活动价格情况,以供选择参考。
|
2月前
|
网络安全 Docker 容器
VScode远程服务器之远程 远程容器 进行开发(五)
VScode远程服务器之远程 远程容器 进行开发(五)
52 1
|
2月前
|
运维 Serverless 数据处理
Serverless架构在图像处理等计算密集型应用中展现了显著的优势
Serverless架构在图像处理等计算密集型应用中展现出显著优势,包括加速研发交付、降低成本、零运维成本、高效资源利用、自动扩展、实时数据处理及快速原型开发,为高并发、动态需求场景提供高效解决方案。
66 1
|
2月前
|
运维 Serverless 数据处理
Serverless架构在图像处理等计算密集型应用中展现出显著优势
【10月更文挑战第6天】Serverless架构在图像处理等计算密集型应用中展现出显著优势,包括加速研发交付、成本效益、零运维成本、高效资源利用、自动扩展能力、实时数据处理及快速原型开发,为高并发、动态需求场景提供高效、灵活的解决方案。
51 4
|
2月前
|
运维 Oracle 关系型数据库
服务器数据恢复—浪潮服务器硬盘出现坏道的数据恢复案例
服务器数据恢复环境: 一台浪潮服务器中有一组由6块SAS硬盘组建的RAID。服务器上划分了1个卷,存放Oracle数据库文件。 服务器故障&检测: 服务器上有两个硬盘指示灯亮黄灯,RAID崩溃,服务器不可用。 将故障服务器中所有磁盘标记后取出。由硬件工程师检测故障服务器上的取出的6块硬盘是否存在硬件故障,经过检测发现变黄的指示灯所对应的2块硬盘存在坏道且SMART的错误冗余级别已经超过阈值。