无服务器云哪家强？且看亚马逊、谷歌、微软直面PK

无服务器云：亚马逊AWS vs. 谷歌Cloud vs. 微软Azure 。...

如果你曾有过因为服务器故障在凌晨3点钟被叫醒过的经历，就会明白“无服务器”这个热门术词的吸引力之所在。机器需要花上数小时、数天有时甚至是数周时间进行配置，同时它们还需要经常更新以解决BUG和安全漏洞。这些更新通常会带来麻烦，因为新的更新会与其他的更新不兼容，这种情况似乎永无休止。

由于运行服务器而产生的这种令人头疼的死循环也是许多大型云公司选择“无服务器”架构的原因之一。他们知道，老板长期以来一直听到的借口都是“服务器这样啦，服务器那样啦”。老板肯定在考虑我们是否能够摆脱服务器。

这是一个很好的营销口号，唯一的问题是它在严格意义上并不正确。这些应用没有了服务器就如同饭店没有了厨房。如果你想点东西都在菜单上，并且你喜欢厨师准备它们的方式，那么坐在餐厅里是很棒的。但是如果你想吃一道与众不同的菜，或是吃到与众不同的口味，那么你最好有自己的厨房。

亚马逊、谷歌和微软这三家巨头目前正在激烈地争夺主机应用的未来，希望将它们写入自己的无服务器API并通过自己的自动化层进行管理。如果平台达到了我们的要求，同时新的模式普及起来，那么对于创建数十亿美元的独角兽级网络应用来说，它们无疑是最简单快捷的方式。我们只需要写少量的关键逻辑，平台会处理所有的细节。

无服务器函数正在成为能够将所有云功能连接起来的胶合或脚本语言。曾经相对独立的映射或AI工具如今也通过由事件驱动的无服务器函数连接到了一起。如今我们的许多工作都可以通过云端各个部分的响应和事件触发来完成。如果我们希望尝试机器学习并通过它们分析数据，那么最快的方式是创建一个无服务器应用，然后将事件发送至云端的机器学习部分。



这其中的关键是将所有东西进一步细化，让它们更容易共享云端上的资源。过去，所有的人都在疯狂地利用运行在自己的虚拟机上的Ubuntu服务器创建新实例。所有的人都在使用相同的操作系统，而这个操作系统会在被划分为多个虚拟Ubuntu服务器的真实服务器上大量复制。无服务器操作避免了这种复制，从而大幅降低了云计算的成本，尤其是对于那些只是零星运行，甚至从未让那些位于机房中的老服务器发生拥堵的工作。

当然所有的便利背后都有隐藏的成本。如果你想将代码迁移到另一个站点，你可能会为需要重写堆栈中的绝大部分而感到怵头。API则不同，虽然像JavaScript等流行的语言都进行了标准化，但是它们几乎已经变为了专利的。这使得用户极有可能遇到厂商锁定的情况。

为了介绍无服务器选项的吸引力，我花费了一些时间创建了一些函数并将它们放在堆栈上。我没有编写太多的代码，不过重点就在于此。我将更多的时间花在了点击按键和填写web表单以配置所有的东西。你是否还记得我们使用XML和JSON配置所有东西的时候？现在我只需要填写一个web表单，云会为我们完成剩下的工作。尽管如此，我们仍然要像程序员那样考虑问题，搞清楚云端上发生了什么以及哪些不在自己的控制之中。AWS Lambda正在成长为亚马逊整个云的shell脚本层。作为一个基础系统，其可让嵌入的函数对由亚马逊云基础设施的任意部分生成的事件做出响应。如果新的文件上传至S3，我们可以让其触发一个函数，让函数利用新文件做有趣的事情。如果某个视频正在使用亚马逊Elastic Transcoder（弹性转码器）进行转码，那么我们可以让Lambda函数等待至转码完成后再依次被触发。这些函数能够触发其他的Lambda操作，或是仅向某人发送更新。



你可以用JavaScript (Node.js)、Python、Java、C#和Go等编写Lambda函数。鉴于上述这些语言可以嵌入许多其他语言，这使得运行Haskell、Lisp甚至是 C++等其他代码成为了可能。

由于亚马逊为配置和优化提供了许多选项，因此我们会觉得编写Lambda函数会比预期的要复杂。尽管在技术上我们确实可以只编写几行代码就能够完成许多事情，但是我认为自己必须要分配更多的时间去配置代码的运行方式。许多工作是通过浏览器填写表单完成的，而不再是通过键入文本文件完成。有时我会觉得我们只是将文本编辑器换成了一个基于浏览器的表单。不过，这也是为了保留所有的灵活性所付出的代价，亚马逊希望将这些灵活性也提供给Lambda用户。

    关注 计算机世界