管理服务器带来的无休止的麻烦是大型云服务公司采用“无服务器”架构的原因之一。他们知道老板已经听够了服务器出这样或那样问题的借口。如果我们能够摆脱那些服务器，那么老板一定会考虑。

借助AWS Lambda、谷歌云函数和微软Azure Functions，可帮你将很小的业务逻辑做得更好。

如果你因为服务器出问题而在凌晨3点被唤醒，你就会明白像“无服务器”这样的流行词如此具有吸引力的原因。这些设备可能需要数小时、数天甚至数周才能配置完毕，然后需要不断地更新以修复错误和安全漏洞。这些更新程序通常会给其自身带来麻烦，因为新更新程序会导致与其他更新程序不兼容，或者这一工作看起来永无休止。

管理服务器带来的无休止的麻烦是大型云服务公司采用“无服务器”架构的原因之一。他们知道老板已经听够了服务器出这样或那样问题的借口。如果我们能够摆脱那些服务器，那么老板一定会考虑。

这是一个很棒的销售语言，但唯一的问题是它并不完全正确。这些应用程序处于无服务器架构，就像餐厅里没有厨房一样。如果你想要的菜在菜单上，并且你喜欢厨师的烹饪方法，那么坐在餐厅里是很棒的选择。但如果你想要一种不同的菜肴，如果你想要不同的调料，那么你最好有自己的厨房。

亚马逊、谷歌和微软是三家大公司，正在为未来管理应用程序而战，他们希望将这些应用程序写入其无服务器API中，并通过其自动化层进行管理。如果这些平台可提供你想要的东西，而且这些新模型非常通用化，那么这些平台可能是创建自己的价值数十亿美元的独角兽网络应用的最简单和最快捷的方式。你只需编写关键的逻辑部分，而平台会处理所有的细节。

无服务器功能正在成为连接所有云功能的粘合剂或脚本语言。曾经相当独立的映射或人工智能工具现在通过事件驱动的无服务器功能进行链接。现在，更多的工作可以通过请求来解决，这些请求会通过每个云的各个部分产生波动和回弹，产生触发并由一系列事件触发。如果你想了解机器学习技术并使用它来分析你的数据，那么最快速的方法之一就是创建一个无服务器应用程序，并开始将事件发送到云计算的机器学习部分。

隐含的承诺是，将所有内容切割得更薄，这样可以更轻松地共享云端的资源。过去，每个人都会疯狂地创建新的实例，例如在自己的虚拟机上运行Ubuntu服务器。每个人都使用相同的操作系统，并且这个系统在同一个真实机箱上复制无数次，假装成十几个或更多的虚拟Ubuntu机箱。无服务器操作可以避免所有重复操作，使云计算成本大幅降低，特别是对于偶尔运行的作业，而且从未使在空调服务器机房中的旧机箱发生堵塞。

当然，所有这些便利都有隐性成本。如果你想离开或想将你的代码移动到另一个站点，你可能会陷入重写大部分堆栈的困境。这些API是不同的，尽管JavaScript等流行语言有一些标准化，但它们更接近于专有技术。使用者有很多被锁定的机会。

为了理解无服务器的吸引力，我花了一些时间来构建一些函数，并围绕堆栈进行研究。我没有写太多的代码，但这就是关键。我花了更多时间点击按钮并输入网页表单来配置一切。你还记得我们用XML和JSON配置过所有的东西吗?现在我们填写一个网络表单，云端就会为我们做这一切。尽管如此，你仍然必须像程序员一样思考，了解幕后发生的事情，以及你无法控制的事情。

AWS Lambda计算服务

AWS Lambda正在成长为亚马逊整个云端的shell脚本层。这是一个基本系统，可让你嵌入响应事件的函数，这些事件可能是由亚马逊云基础架构任何部分所产生的。如果一个新文件上传到S3，你可以让它触发一个函数，做一些有趣的事情。如果某些视频正在被Amazon Elastic Transcoder媒体转码工具进行转码，你可以在转码完成后等待其去触发Lambda函数。这些函数反过来可以触发其他Lambda操作，也可能只是向某人发送更新。

你可以使用JavaScript(Node.js)、Python、Java、C#和Go语言编写Lambda函数。鉴于这些语言可以嵌入许多其他语言中，所以很可能运行其他代码，如Haskell、Lisp甚至C ++。(关于将旧版C ++编译为库以与AWS Lambda一起使用的内容，请参阅本文案例。)

编写Lambda函数往往比你预想的要复杂得多，因为亚马逊提供了很多配置和优化选项。虽然技术上你可以只写几行代码，就能完成很不错的功能，但是我觉得，我必须花更多时间来配置代码的运行方式。这一工作的大部分内容是通过在浏览器中填写表单而不是在文本文件中输入来完成的。有时候感觉就像我们只是将文本编辑器换成了浏览器表单，但这就是使用亚马逊为Lambda用户提升灵活性的代价。

其中一些额外的步骤是由于亚马逊向用户提供更多的选项所带来的，并期待有更多首次函数编写者。一旦我在谷歌或微软上编写完一个函数后，我就可以将浏览器指向正确的URL并立即进行测试。亚马逊让我点击来配置API网关，并在防火墙中打开恰当的漏洞。

最后，所有这些点击会增加一层辅助工具，使得工作比一开始使用文本文件更轻松一些。当我创建一个函数时，浏览器会弹出一个警告，“这个函数包含外部库”。在纯节点的时代，这是我希望知道的事情，或者我可以通过谷歌来搜索错误信息，然后希望找到答案进行学习。而现在云端正急着来提供帮助。

如果无服务器意味着将你从管理服务器的杂事中解放出来，那么亚马逊还有许多其他如同AWS Lambda一样的“无服务器”选项。它具有像Amazon EC2 Auto Scaling和AWS Fargate这样的弹性工具，可以启动和关闭服务器，以及具有AWS Elastic Beanstalk工具可将你上传的代码部署到Web服务器并处理负载平衡和缩放。当然，拥有许多这些自动化工具，你仍然需要负责创建服务器映像。

AWS Step Functions是一种更有用的产品，它是一种无代码流程图工具，用于创建状态机以创建软件架构师调用工作流的模型。一部分问题是所有的无服务器函数都是完全没有状态的，当你执行非常基本的业务逻辑时，这些函数是正常的，但当你通过一个清单或流程图来处理客户端问题时，这些函数可能会是一场噩梦。你要不断地到数据库重新加载有关客户端的信息。Step Function可将Lambda函数与状态结合在一起。

谷歌云函数和Firebase平台

如果你的目标是摆脱配置服务器的麻烦，那么谷歌云提供了许多服务可以让你更轻松，例如输入根密码，甚至使用命令行等工作。

从2008年的Google App Engine平台开始，谷歌一直在慢慢地添加不同的“无服务器”选项，并将各种消息发送和数据透明度结合在一起。一个名为Google Cloud Pub / Sub的工具可对用户隐藏消息队列，因此你只需为数据生产者和消费者编写代码即可。谷歌云函数为许多主要产品(包括某些选取框工具和API)提供事件驱动的计算。然后是谷歌Firebase平台，这是一个很强大的数据库，可让你将JavaScript代码混合到数据存储层，该数据存储层将数据传送到客户端。

其中，Firebase平台是我最感兴趣的。一些人认为数据库是原始的无服务器应用程序，它将数据结构和磁盘存储工作抽象出来，通过TCP/IP端口传递所有信息。Firebase平台通过添加JavaScript代码和消息发送功能来完成你想在服务器端基础架构执行的几乎所有工作(包括身份验证)，使这种抽象性工作做到极致。从技术上讲，它只是一个数据库，但它可以处理堆栈的大部分业务逻辑和消息传递。你真的可以摆脱一些客户端的HTML、CSS、JavaScript和Firebase平台。

你可能会像对待Oracle一样，试图将Firebase平台的JavaScript层称为“存储过程”，但这样做会忽略更多内容。Firebase代码是用JavaScript编写的，因此它将以本地版本的Node.js运行。你可以在该层中嵌入大部分业务逻辑，因为节点环境中已经充满了处理此工作流的库。另外，你还会享受在客户端、服务器上运行的同构代码的乐趣，现在可以运行在数据库中。

引起我注意的部分是Firebase中内置的同步层。它可将整个网络中来自数据库的对象副本进行同步。其诀窍是，你可将你的客户端应用程序设置为另一个数据库节点，该节点可订阅所有相关数据(仅包含相关数据)的更改。如果数据在一个地方发生改变，它会在所有位置进行改变。你可以避免所有消息传递的麻烦，并专注于将信息写入Firebase中，因为Firebase会将其复制到需要的位置。

你无需只关注于Firebase。更基本的谷歌云函数是一种更简单的方法，可将定制代码嵌入整个谷歌云中。目前，云函数很大程度上只是编写Node.js代码的一个选项，该代码将在预配置的节点环境中运行。虽然谷歌云平台的其他部分可支持各种语言，包括Java、C#、Go、Python和PHP，但云函数却仅限于使用JavaScript和Node语言。有迹象表明，其他语言选择即将实现，如果这些选择很快出现，我不会感到惊讶。

至少在这一点上，谷歌云函数不会像AWS Lambda进入AWS一样深入到谷歌云中。当我尝试构建一个与Google Docs交互的函数时，我发现我可能不得不使用REST API并将代码写入名为Apps Script的应用程序中。换句话说，Google Docs环境拥有自己的REST API，其在无服务器这个流行词出现很久之前就处于无服务器状态。

值得注意的是，Google App Engine的功能持续变得强大。一开始，它提供了启动Python应用程序以满足访问者进入网站的需求，但多年来一直在扩展功能，目前可处理许多不同的语言运行环境。将代码打包成可执行文件后，App Engine将启动流程，开启足够的节点来处理流量，并在用户发送请求时按比例放大或缩减数量。

要牢记的是，仍存在一些障碍。与云函数一样，你的代码必须以相对无状态的方式编写，并且必须在有限的时间内完成每个请求。但是App Engine不会抛弃所有的scaffolding，也不会忘记各请求之间的所有东西。App Engine是无服务器革命中的重要组成部分，对于那些仍采用旧方法并使用Python，PHP，Java，C#或Go语言构建自己的堆栈的人来说，它仍然是最容易获得的平台。

微软Azure Function

当然，微软与其他公司一样在努力工作，以确保人们可以使用微软Azure完成所有的无服务器架构工作。微软公司已经为处理事件创建了自己的基本函数，即Azure Function，并且还构建了一些更复杂的工具，这些工具对于不太成熟的程序员来说更加易于使用。

微软拥有的最大优势可能是它的Office应用程序集合，这些前期的桌面可执行文件正在缓慢而稳定地迁移到云端。事实上，在云计算收入的一种财务核算方法上，微软已领先于亚马逊公司，这部分原因在于微软将其部分Office收入纳入到短期的“云”计算收入中。

Azure Functions文档中最好的一个示例说明了，当某人在将电子表格保存到OneDrive时，云函数是如何被触发的。突然间，云端的小精灵活跃起来，可以处理电子表格中一些事情。对于喜欢Excel电子表格(或其他Office文档)的IT支持团队来说，这绝对是天赐之物。他们可以编写Azure Function来做几乎任何事情。我们通常认为HTML和网络是云端的唯一接口，但没有理由不能通过Microsoft Word或Excel等文档格式连接至云端。

Azure的Logic Apps引起了我的注意，它的一个工具可以帮你填写表单，而不用担心语义和语法。你仍然需要像程序员一样思考，并对抽象概念和数据做出明智的决定，但是你可能会说服自己，你并没有像填写表格那样来编写“代码”。

像亚马逊的Step Functions一样，Logic Apps的目的是对“工作流”进行编码，这是一种流行词，比起普通的“函数”要复杂得多，这要归功于可使用某种状态。你仍然可以用类似流程图的方式编写链接各种函数和连接器的逻辑，但是你不会用像正式计算机语言那样进行详细说明。

Logic Apps的一大优势是预先构建的“连接器”，可深入到微软和第三方的一些更大应用程序中。你可以有效地从Logic Apps 以及Salesforce、Twitter和Office 365等程序中推送或提取数据。这些连接对于公司IT人员来说非常有价值，他们现在可以通过编写Logic Apps来连接外部工具，就像他们过去创建shell脚本一样。

Azure另一个有趣的地方是Azure Cosmos DB，它同时是NoSQL数据库和SQL数据库。微软已经复制了Cassandra和MongoDB的API，这样你就可以在不改写Cassandra或MongoDB代码的情况下输入和输出信息。或者，如果你想写SQL语句的话，你也可以这样做。Cosmos DB可以让内容很直观，并为所有内容建立索引，以使其快速运行。如果你有很多SQL和NoSQL代码需要同时使用，这将使它成为一个非常不错的中心连接。或者，也许你只是想在未来为采用不同的方法敞开大门。

无服务器云的比较

哪个无服务器平台适合你?在所有三个独立平台中编写基本函数几乎都是一样的，但是存在一些差异。最明显的区别可能是可使用的语言，因为这些平台在完成支持Node.js和JavaScript语言后都会使用自己偏好的语言。你可以为微软的Azure使用C#语言编写，这并不令人惊讶，但它对F#和TypeScript语言的支持是独一无二的。亚马逊可支持Java、C#和Python语言。谷歌目前的基本函数严格限于使用JavaScript语言，但它在App Engine中支持更多的语言。

对无服务器云进行对比最难的是掌握其价格和速度，因为更多的东西隐藏在底层。当我启动虚拟机，并按每小时价格收费时，我常常觉得自己像个疯狂的消费者。现在，提供商正在将其服务切分的如此精细，以至于你可以以不到一美元的价格获得数十万次函数调用。你会像在“王牌大贱谍”电影中的“邪恶博士”一样，反复去说“百万”这个词。

当然，这种明显的低价很快就会削弱我们大脑中理性的和预算意识的部分，就像我们在一个陌生的国家度假一样，这个国家使用完全不同的货币面额。不久之后，你将订购另外数百万次的数据库调用，就像你在墨西哥坎昆的酒吧喝酒一样，因为你无法快速换算价格以确定其实际成本。

当云计算为你提供一台原始的虚拟机时，你可以猜测其内存容量和CPU性能，但是在无服务器的环境中，你并不真正知道其中的内在配置。

值得注意的是，无服务器模式几乎会迫使你将数据存储在本地云数据库中，因为它不允许你在代码中保留任何状态。你必须相信这些后端架构。你的函数必须运行在没有任何本地缓存或配置的环境中，因为其他版本总是被创建和销毁。因此，数据库胶水代码会填满你的代码，就像在《怪奇物语》(Stranger Things)电影中表里世界(Upside Down)的那些藤蔓一样。

比较成本的唯一现实方法是在所有平台上构建应用程序，这是一项艰巨的挑战。可以在三者之间移动一些代码，因为它们都运行Node.js，但即便如此，你仍然会遇到并忍受一些差异。 (例如，你直接在Microsoft和Google中处理HTTP请求，但要通过AWS中的API Gateway进行处理。)

好消息是你不必如此偏执。在我的实验中，许多基本应用程序几乎不使用任何资源，你可以使用这三个平台所提供的免费资源很长时间，这些资源是为吸引那些不愿付费的开发人员。无服务器模式确实为我们节省了开销。除非你的服务器是始终接近满负荷运行，并且放置在拥有免费空调的机房，否则你将业务转向无服务器方式，这很可能最终会为你节省一些大笔资金。你会节省如此多的资金，你也就不会计较它每百万次函数调用的价格是1美元或1.50美元。

还有一个更深层的问题。如果你受够了这些云，你就会陷入困境。这并不是很轻松地就能将代码取出并在其他地方的商品服务器上运行，而是你可能要使用装满自己代码的Docker容器进行操作。如果幸运的话，你可以复制相同的原始架构和基本的JavaScript函数，但在此之后，你要在所有部位都重写数据库胶水代码。所有这三家公司都有自己的专有数据存储层。

目前还不清楚出现故障时会发生什么。运行你自己的服务器意味着，当你的老板不能正常工作时，你需要立即解决问题。目前还不清楚在这个领域会发生什么。在谷歌公司的一个页面中包含一个温和的警告，“这是谷歌云函数的测试版。此API可能会以不兼容的方式进行更改，并且不受任何服务水平协议(SLA)或弃用政策所约束。”

亚马逊的服务条款比它首次进入这一领域时要好一些，但它仍然包含一些你需要记住的警告内容，例如：“如果你上传到AWS Lambda的任何内容超过三个月未使用，那么我们会在30天内通知你，并可能将其删除，且不承担任何形式的责任。”如果你想在亚马逊云端保留你的代码，那么请确保你经常运行该代码。像这样的警告内容当然是公平的(这样的话，我会知道我的旧Lambda函数不会再被使用)，但这也表明了你将如何放弃一些控制权。

微软为Azure服务提供服务水平协议，其承诺通过服务积分对故障时间进行经济补偿。这些承诺也适用于你的函数故障吗?也许，只要你不使用一些测试版服务。如果你打算构建比儿童聊天室更重要的工作，那么就值得花一点时间关注这些细节内容。

在大多数情况下，你真正想进行的是在亚马逊、谷歌和微软云的其他功能和服务之间的比较，而不是函数层面。如果你对喜欢使用Office应用程序的用户提供支持，则利用在OneDrive上的Office文件来触发Azure Functions的功能，这对你是极具吸引力的。借助谷歌Firebase平台，可以轻松使用各种功能为Web应用提供消息传递和身份验证等支持服务。AWS Lambda提供了许多亚马逊服务，看起来天空真的是有极限的。

从技术上讲，混合和匹配所有这些云和函数是可能的，因为它们都使用相同的PUT和GET语言来调用HTTP API。你没有理由不使用这些融合很多微服务的应用程序，因为这些应用程序集合了三个云平台中最好的功能。但是，当数据包离开本地云，并在开放互联网的荒野中传递时，你将最终遇到更大的延迟。然后，在解析和结构上会有细微的差异，这使得坐在一家公司的温暖环境中工作变得更轻松。

因此，使用单个云的安全部分可能是更合理的，至少在涉及相互关联的应用程序时是这样。你真的很喜欢谷歌地图吗?你是否想把它们用于你的项目?那么，即使在你的心中，你也可以使用谷歌云函数，而不是将F#语言与微软的Azure Functions结合使用。亚马逊的语音识别，或谷歌的图像分析API，或任何数十种不同的服务和机器学习API也是如此。功能并不那么重要，它们的相互连接才是真正重要的。