被吹得天花乱坠的无服务器架构，究竟是什么？(5)

“运维”的意义远不止系统管理，它还包括并不限于监控、部署、安全、网络、支持、生产环境调试以及系统伸缩。这些事务同样存在于 Serverless 应用中，你仍旧需要相应的方法处理它们。某些情况下 Serverless 的运维会更难一些，毕竟它还是个崭新的技术。

系统管理的工作仍然要做，你只是把它外包给了 Serverless 环境。这既不能说坏也不能说好——我们外包了大量的内容，是好是坏要看具体情况。不论怎样，某些时候这层抽象也会发生问题，就会需要一个来自某个地方的人类系统管理员来支持你的工作了。

对比存储过程即服务

还有一种说法把 Serverless FaaS 看做“存储过程即服务(Stored Procedures as a Service)”，我想原因是很多 FaaS 函数示范都用数据库访问作为例子。如果这就是它的主要用途，我想这个名字也不坏，但终究这只是 FaaS 的一种用例而已，这样去考虑 FaaS 局限了它的能力。

我好奇 Serverless 会不会最终变成类似存储过程那样的东西，开始是个好主意，然后迅速演变成大规模技术债务。— Camille Fournier

但我们仍然值得考虑 FaaS 是否会导致跟存储过程类似的问题，包括 Camille 提到的技术债。有很多存储过程给我们的教训可以放在 FaaS 场景下重新审视，存储过程的问题在于：

通常依赖于服务商指定的语言，或者至少是指定的语言框架/扩展

因为必须在数据库环境中执行所以很难测试

难以进行版本控制，或者作为应用包进行管理

尽管不是所有存储过程的实现都有这些问题，但它们都是常会碰到的。我们看看是否适用于 FaaS：

第一条就目前看来显然不是 FaaS 的烦恼，直接排除。

第二条，因为 FaaS 函数都是纯粹的代码，所以应该和其他任何代码一样容易测试。整合测试是另一个问题，我们稍后展开细说。

第三条，既然 FaaS 函数都是纯粹的代码，版本控制自然不成问题;最近大家开始关心的应用打包，相关工具链也在日趋成熟，比如 Amazon 的 Serverless Application Model(SAM)和前面提到的其他 Serverless 框架都提供了类似的功能。2018 年初 Amazon 还开放了 Serverless Application Repository(SAR)服务，方便组织分发应用程序和组件，也是基于 AWS Serverless 服务构建的。

（编辑：ASP站长网）