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

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对话环节中，他表示该服务本身也是通过容器实现的。

配置AWS Lambda内存设置

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

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

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

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

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

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

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