Funtainer：容器即函数之美

来源： SDK.cn 类型：技术文章发布：2017-12-05 14:35:03

常言道：“Serverless并非没有服务器，而是不再需要关注服务器。”

在最近的Serverless会议[1]上，我们看到了Serverless使用率的上升，并且这种上升令人印象深刻。

我很荣幸能够成为会议的一名主讲人。我所演讲的内容是开发者及DevOps世界中的剧烈变化，从容器管理和微服务部署到函数和Serverless。

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

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

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

回答该问题前，让我们先从采用Serverless的障碍，容器的优点等方面开始讨论。

采用Serverless的障碍

1. 部署方法学的剧烈变迁

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

2. 使用不同的接口

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

未命名1512455793.png

Amazon的接口代码为白色，Google为蓝色，Azure为黄色。这意味着每个云对于代码的响应均有细微区别，使得形式的标准化变得更加困难。

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

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

4. 第三方依赖

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

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

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

其实一切都很简单：

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

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

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

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

所以，它是如何工作的？

未命名1512455897.png

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

这种变化并不恐怖，不需要我们改变在容器上运行代码学到的方法学，转而学习新的（方法学）。运行容器即服务（Funtainer）让我们可以简单的搭上这波势头，享受容器和函数带来的优点。