Funtainer：容器即函数之美

回首过去20年，上图向我们展示了演化历程。我们快速地从物理服务器管理迁移到虚拟机管理，而现在我们正在从容器运行转移到函数运行。

Docker的面世，使得Linux容器变得如此好用，以至于其迅速成为了主流。它们真正成为了帮助开发者构建、迁移和运行（应用）的有效工具。我们开始以一种舒服的方式开发微服务，并且认识到部署不再艰难。

2014年，AWS Lambda面世，这是一种允许用户运行代码而无需管理和关心服务器的服务。Lambda暗示着“遗忘容器，开始构建函数”。但如何联系两个概念是一个很大的问题。这两种技术变迁是否存在冲突，或者说能否以一种神奇的方式整合它们？

自古改变非易事。为了使用函数，我们需要从极小的构建开始，它甚至比微服务更小，本质上是微微服务（micro-microservice）。显然，我们将需要开发更多服务了。

2. 使用不同的接口

如果我们想要使用Spotinst Functions[2]，Lambda[3]或者Azure Functions[4]，我们需要遵循特定的模板或签名。如下是我所说的一个例子：

3. 改变部署方式及其后的思想

我们已经习惯了VM、容器，蓝绿部署和健康检查或者按步就班地部署新版本的方式。函数需要我们处理一个些许不同的现实。再次，改变非易事。

4. 第三方依赖

在容器或者虚拟机上运行代码时，我们知道其所有的依赖将会在代码所运行的服务器上被找到。在Serverless中，我们需要将代码与其依赖一起打包到ZIP中，这样Serverless供应者才能够运行函数。此外，ZIP的大小被限制到50MB（包括依赖！），这使得在一个函数中运行复杂代码变得更加困难。

函数确实带来了一大堆优点，但它们被一些难以轻易踢开的绊脚石所阻碍。倘若我们能够将容器的优势应用到函数中，一切又会变得如何？

为了回答这个问题，让我们对AWS Lambda背后的技术稍作深挖，一起来看看所谓的"Serverless计算"魔术是如何工作的？

其实一切都很简单：

1. 上传代码（包括依赖）
2. Function供应者（例如Lambda）拿到我们的代码，并将其注入到容器中
3. 容器在服务器上运行函数，Lambda返回结果

如果我们跳过第2步，让函数的输入即为容器，而函数供应商拿到容器后直接运行会怎样？

我们将这种“容器运行即函数”的处理称为“Funtainer”。这让我们能够同时享受运行容器和运行函数带来的好处，例如高可用性，无需运维，以及Serverless计算，所有的一切运行在近些年来我们所悉知的容器之上。

Funtainer，或者说容器即函数，正在以惊人的速度发展，3个大项目在这种大环境下获益匪浅：

1. IBM OpenWhisk[5]
2. 我们自己的Spotinst Functions
3. OpenFaas[6]

上述平台带来了难以置信的好处：

1. 不像其他FaaS产品，没有编程语言的限制
2. 无需担心依赖或者ZIP文件（所有的东西都被打包到容器）
3. 不再是供应商锁定，随时随地运行Funtainer
4. 无需关心不同的FaaS代码接口

所以，它是如何工作的？

1. 编写代码
2. 打包到容器
3. 编写Dockerfile，包含容器运行所需的依赖
4. 上传容器到Hub
5. 创建函数，将输入代码修改为DockerHub/ContainerName
6. 运行函数

换句话说，无论我们是否喜欢，剧变正在发生。真正的问题是，函数何时才会成为大多数公司运行代码的方式。