Serverless 的承诺都兑现了吗？( 三 ) 2009年

2016年，亚马逊云科技发布了AmazonStepFunctions ，可以组合调用多个AmazonLambda函数和其它Amazon服务，将复杂的业务逻辑可视化地表达为低代码、事件驱动的工作流。
2017年， AmazonLambda的默认并发数提升到了1000 ，并提供了分布式跟踪工具X-Ray 。
2018年，亚马逊云科技发布了AmazonAuroraServerlessv1版本，正式宣告更复杂的关系型数据库（RDBMS）也能具备Serverless的特性，实现了云数据库基于负载的自动启停与弹性扩展。随着云服务的演化，亚马逊云科技相继发布了五项Serverless数据库服务，包括AmazonAuroraServerless、AmazonDynamoDB、AmazonTimestream（一种时间序列数据库服务）、AmazonKeyspaces（兼容ApacheCassandra的托管数据库服务）和AmazonQLDB（一种全托管的分类账数据库）。目前， AmazonAuroraServerless已从v1版进化到v2版， AuroraServerlessv2可以在一秒内将数据库工作负载从数百个事务扩展到数十万个事务，与为峰值负载配置容量的成本相比，最多可节省90%的数据库成本。
2019年，亚马逊云科技发布了AmazonEventBridge ，它是一种无服务器事件总线服务，作为集中式枢纽连接到AmazonWebServices服务、自定义应用程序和SaaS应用程序，提供从事件源到目标对象（例如AmazonLambda和其他SaaS应用程序）的实时数据流。现在AmazonLambda可与200多种AmazonWebServices服务和SaaS应用程序相集成。
同年，亚马逊云科技还推出了AmazonS3GlacierDeepArcHive ，进一步按读写冷热程度完善了S3存储服务的智能收费档次。
2021年AmazonLambda计费功能调整为了1ms级别，并且还提供了容器镜像支持，以及AmazonGraviton2处理器支持，与基于x86的同类产品相比， AmazonGraviton2性价比最高可提升34% 。
冷启动和厂商锁定
“冷启动”的性能改善算得上是一次标志性事件。 FaaS平台初始化函数实例需要一些时间。即使对于同一个特定的功能，不同的平台之间这种启动延迟可能会有很大差异，从几毫秒到几秒不等，取决于使用的库、函数配置的算力等大量因素。以AmazonLambda为例， AmazonLambda函数的初始化要么是“热启动” ，要么是“冷启动” 。 “热启动”是从前一个事件中重用AmazonLambda函数的实例及其宿主容器， “冷启动”需要创建一个新的容器实例，启动函数宿主进程。在考虑启动延迟时， “冷启动”更受关注。
亚马逊云科技在2019年提供了一项名为“预置并发（ProvisionedConcurrency）”的重要新功能，通过让函数保持初始化状态，从而更精确地控制启动延迟。用户需要做的就是设置一个值，指定平台需要为特定功能配置多少个实例， AmazonLambda服务本身将确保始终有该数量的预热实例等待工作。 “冷启动”无疑是无服务器技术批评者指出的最大问题，而亚马逊云科技这项功能的出现，代表着关于“冷启动”的争议已经结束。
除此之外， “厂商锁定”也是一个极具争议的地方。几年前，作为无服务器技术的反对方， CoreOS首席执行官AlexPolvi称AmazonLambda无服务器产品“是我们在人类历史上见过的最糟糕的专有锁定形式之一” 。而为MongoDB工作的MattAsay撰文反驳他说， “完全避免锁定的方法是自己编写所有底层软件（事件模型、部署模型等）” 。
总之，作为支持方，很多人认为“锁定”并不是一件非黑即白的事情，而是本身需要反复权衡的一种架构选择。还有技术专家表示，可以采用将应用程序和平台分离的设计方式，以及标准化技术的方法最小化迁移成本：如果使用标准化的HTTP ，那么可以使用AmazonAPIGateway将HTTP请求转换为AmazonLambda事件格式；如果使用标准化的SQL ，那么使用与MySQL兼容AmazonAuroraServerless ，可以自然地简化数据库的迁移路径......