【译】Serverless架构 - 7

原文：

https://martinfowler.com/arti...

NoOps

Serverless并不意味着‘No Ops’。它也许表示‘无内部系统管理员’，取决于你在serverless这个兔子洞走了多深。这里有两个重要的地方需要考虑。

第一，‘Ops’比系统管理含义大得多。它至少还包含监控，部署，安全，网络，并且还表示一部分生产环境debug和系统伸缩。这些问题在Serverless应用中仍然存在，你仍然需要制定策略来处理他们。某种意义上说在Serverless世界中Ops更难，因为很多此方面的东西都太新了。

第二，系统运维工作仍然存在 - 你只是把它外包给了Serverless。这并不是一件坏事 - 我们外包了很多东西。取决于你努力的方向，也许好也许坏，而且无论哪种方式在某个点都会泄露抽象层，你需要知道有外部系统管理员在支持你的应用。

Charity Majors（https://twitter.com/mipsytipsy） 最近在Serverless会议上进行了一次不错的演讲，我建议在演讲线上发布时看一下。这之前你可以在这里（https://charity.wtf/2016/05/3...） 和这里（https://charity.wtf/2016/05/3...）
读她的作品。

存储过程即服务 （Stored Procedures as a Service）

我看到Serverless FaaS的另外一个主题是‘存储过程即服务’。 我想这是因为很多FaaS函数功能的例子（包括我在这个文章中的）是对数据库存取代码的包装。如果这是我们用FaaS的唯一部分那么这个名字倒是很合适，不过这只是FaaS能力的一个子集，所以这样的想法是不合适的。

那么FaaS是不是跟存储过程有一样的问题就值得考虑一下了，包括Camille在tweet中提到的技术债务。有很多关于使用存储过程的课程都值得在FaaS的背景下看一看是否适合。这是存储过程的问题：

1. 一般是供应商特定语言，或至少是供应商特有框架/扩展。

2. 由于必须要在数据库中执行所以很难斤西瓜测试。

3. 在版本控制上很难/做为应用的一等公民

记住这些并不适用于所有存储过程的实现，但在我遇到的情况中它们确实是很有问题。让我们看下是否适用于FaaS：

（1）在FaaS的实现中不是一个问题，所以我们可以先把这个问题划掉了。

对于（2），由于我们处理的是‘代码’，单元测试跟其他代码一样容易。集成测试是另外一个问题，稍后我们再讨论。

对于（3），一样的原因由于FaaS函数就是‘代码’所以版本控制也没问题。但对于应用打包还没有成熟的模式。我之前提到的Serverless框架提供它自己的格式，而AWS在2016年6月的Serverless会议上也声明他们正在做打包的事情（‘Flourish’），但这仍然是一个值得考虑的地方。

---

本文来自微信公众号「麦芽面包，id「darkjune_think」
转载请注明。
微信扫一扫关注公众号。