正文

关于无服务器，有一种说法我听过很多次：“无服务器是一种自找麻烦的解决方案”。

当一项新技术破坏了人们习惯的工作流程时，就会出现类似的防御性声明。这种声明也是在告诉无服务器社区里的所有人，无服务器的学习曲线有多陡峭。

如果人们理解了无服务器，他们就不会说出这么负面的话。因此，我提出了一个问题：如何驯服无服务器的学习曲线？

我给出的答案是一个Web应用程序。让我来解释一下。

去年春天，我第四次听到开头那句话。所以我问自己，“你能用无服务器构建的最简单的东西是什么？人们可以把它与自己已经知道的东西联系起来。”

我认为，我可以向人们展示他们可以如何做他们现在正在做的事情，只是以更简单的方式，以此来展示无服务器的价值。

因此，我构建了一个Web应用示例，称之为Guestbook。

就是每个人都知道的LAMP技术栈。

它很简单，并且提供了可选的组件，这可以说明它为什么在过去20多年里如此流行。我们甚至在Kubernetes（K8S）的学习曲线中看到了它的影响：

Guestbook是大多数人在第一次学习Kubernetes时最先部署的应用程序之一，尽管它使用NoSQL服务器代替了MySQL，但仍然是基本的LAMP结构。

有鉴于此，降低无服务器学习曲线的一种方法是向人们展示如何用更少的代码和配置构建同样复杂的Web应用程序。

使用AWS构建，则该Web应用程序如下所示：

虽然这只需要大约一半的代码和配置，但它也把你锁定在AWS中。

如果你可以创建一个类似LAMP的设计模式，但使用K8S上的无服务器概念来确保可移植性，那会怎么样？

AWS体系结构的组件分别是函数即服务（FaaS）运行时、对象存储和NoSQL服务器。

如果你在任何超过3000 star的GitHub项目或其他流行开源组件上使用了五个FaaS运行时之一，那么整个技术栈就可以像下面这样安装在K8S上：

把它们都放在一起，就可以得到一个简洁的无服务器设计模式缩写：

（我把这个动物图标归功于我的女儿，她说：“FONK听起来就像是鹅说的话。”）

今年9月，我和一些朋友试着推出了fonk-apps.io，这是一个开源项目，目标是降低人们的无服务器学习曲线。它提供了各种语言的简单Web应用程序示例。

为了让人们更容易地从本地K8S过渡，这些Web应用程序中的第一个示例就是Guestbook。以下是我们的早期进展：

只有Create和List函数的Guestbook是自然而然的第一选择，不过，我们的计划是让这个应用程序变得更加复杂。我们希望添加待办（完整CRUDL操作）、博客（经过身份验证的CUD、公共RL）和论坛（经过身份验证的CRUDL）。

更长远来看，内置一些CI/CD功能，包括列测试自动化或跨行性能基准测试，这会很酷。

在构建第一组示例的过程中，我们学到了很多比较FaaS运行时的知识。

从开发人员体验的角度来看，以下是一些早期研究结果：

基于K8S运行时上的某些FaaS开发，其体验和本地K8S开发类似；它公开了函数将在其上运行的镜像的一些内部结构。其他的则更接近于屏蔽了镜像细节的AWS Lambda模型。

在这个领域，谷歌的Knative是那只重达800磅的大猩猩，它在GitHub上还没有达到3000星的门槛，过了这个门槛，我们就提供Guestbook示例。但是，我们正密切关注它的进展，因为它很可能会实现这一目标。

一旦开始实施这个想法，我们认为最好有一个以它为中心的社区。所以，我们试着让整件事成为成为一件有吸引力的事。

虽然并不是所有基于K8S运行时的FaaS都支持无服务器框架，但是Kubeless和OpenWhisk做得非常好。一个简单的入门方法是从头到尾做一个完整的示例：

我们很感激您的GitHub之星，但是，我们更希望看到一个新的FaaS运行时/语言组合PR。

你可以检出我们在GitHub上的FONK项目，自己尝试一些例子。或者，你可以提出任何FaaS/语言组合请求，我们会构建所有可能的Guestbook！

FONK：一个面向 K8S 的无服务器 LAMP 技术栈