【编者的话】本文介绍了Serverless的演化过程，以及实施过程中可能存在的一些障碍，由此提出Funtainer（容器即函数）并简要阐述了其优势。
常言道：“Serverless并非没有服务器，而是不再需要关注服务器。”
在最近的Serverless会议上，我们看到了Serverless使用率的上升，并且这种上升令人印象深刻。
我很荣幸能够成为会议的一名主讲人。我所演讲的内容是开发者及DevOps世界中的剧烈变化，从容器管理和微服务部署到
函数和Serverless。
回首过去20年，上图向我们展示了演化历程。我们快速地从物理服务器管理迁移到虚拟机管理，而现在我们正在从容器运行转移到函数运行。
Docker的面世，使得Linux容器变得如此好用，以至于其迅速成为了主流。它们真正成为了帮助开发者构建、迁移和运行（应用）的有效工具。我们开始以一种舒服的方式开发微服务，并且认识到部署不再艰难。
2014年，AWS Lambda面世，这是一种允许用户运行代码而无需管理和关心服务器的服务。Lambda暗示着“遗忘容器，开始构建函数”。但如何联系两个概念是一个很大的问题。这两种技术变迁是否存在冲突，或者说能否以一种神奇的方式整合它们？
回答该问题前，让我们先从采用Serverless的障碍，容器的优点等方面开始讨论。
采用Serverless的障碍
1. 部署方法学的剧烈变迁
自古改变非易事。为了使用函数，我们需要从极小的构建开始，它甚至比微服务更小，本质上是微微服务（micro-microservice）。显然，我们将需要开发更多服务了。
2. 使用不同的接口
如果我们想要使用Spotinst Functions，Lambda或者Azure Functions，我们需要遵循特定的模板或签名。如下是我所说的一个例子：
Amazon的接口代码为白色，Google为蓝色，Azure为黄色。这意味着每个云对于代码的响应均有细微区别，使得形式的标准化变得更加困难。
3. 改变部署方式及其后的思想
我们已经习惯了VM、容器，蓝绿部署和健康检查或者按步就班地部署新版本的方式。函数需要我们处理一个些许不同的现实。再次，改变非易事。
4. 第三方依赖
在容器或者虚拟机上运行代码时，我们知道其所有的依赖将会在代码所运行的服务器上被找到。在Serverless中，我们需要将代码与其依赖一起打包到ZIP中，这样Serverless供应者才能够运行函数。此外，ZIP的大小被限制到50MB（包括依赖！），这使得在一个函数中运行复杂代码变得更加困难。
函数确实带来了一大堆优点，但它们被一些难以轻易踢开的绊脚石所阻碍。倘若我们能够将容器的优势应用到函数中，一切又会变得如何？
为了回答这个问题，让我们对AWS
Lambda背后的技术稍作深挖，一起来看看所谓的”Serverless计算”魔术是如何工作的？
其实一切都很简单：
- 上传代码（包括依赖）
- Function供应者（例如Lambda）拿到我们的代码，并将其注入到容器中
- 容器在服务器上运行函数，Lambda返回结果
如果我们跳过第2步，让函数的输入即为容器，而函数供应商拿到容器后直接运行会怎样？
我们将这种“容器运行即函数”的处理称为“Funtainer”。这让我们能够同时享受运行容器和运行函数带来的好处，例如高可用性，无需运维，以及Serverless计算，所有的一切运行在近些年来我们所悉知的容器之上。
Funtainer，或者说容器即函数，正在以惊人的速度发展，3个大项目在这种大环境下获益匪浅：
上述平台带来了难以置信的好处：
- 不像其他FaaS产品，没有编程语言的限制
- 无需担心依赖或者ZIP文件（所有的东西都被打包到容器）
- 不再是供应商锁定，随时随地运行Funtainer
- 无需关心不同的FaaS代码接口
所以，它是如何工作的？
- 编写代码
- 打包到容器
- 编写Dockerfile，包含容器运行所需的依赖
- 上传容器到Hub
- 创建函数，将输入代码修改为DockerHub/ContainerName
- 运行函数
换句话说，无论我们是否喜欢，剧变正在发生。真正的问题是，函数何时才会成为大多数公司运行代码的方式。
这种变化并不恐怖，不需要我们改变在容器上运行代码学到的方法学，转而学习新的（方法学）。运行容器即服务（Funtainer）让我们可以简单的搭上这波势头，享受容器和函数带来的优点。
原文链接：Funtainers: The Beauty of Running Containers as Functions（翻译：孙科）
本文转载自: 掘金