AWS Lambda, Google Cloud Functions, 和Microsoft Azure Functions，一点点业务逻辑可以走得很远。
如果你因为服务器出问题而在凌晨3点被唤醒，你就会明白像“无服务器计算”这样的流行词的吸引力。物理服务器可能需要数小时，数天甚至数周才能配置，然后它们需要不断更新以修复错误和安全漏洞。这些更新通常会带来他们自己的麻烦，因为新更新会导致不兼容，从而导致其他更新，或者看起来似乎没有尽头。
运行服务器导致的无穷无尽的连锁问题是主流云公司接受“无服务器计算”架构的原因之一。 他们知道老板们听多了这样的借口，服务器这个了，服务器那个了，太多类似的问题。 如果我们能摆脱服务器，老板肯定想要。
无服务器计算是一个很棒的销售条款，唯一的问题是它不是完全正确的。这些应用程序是无服务器的，就像餐厅没有厨房一样。如果你想要的在菜单上，并且你喜欢厨师准备的方式，那么坐在餐厅里是很棒的。但如果你想要一种不同的菜肴，如果你想要不同的香料，那么你最好有自己的厨房。
借助AWS Lambda配置页，可以单击触发函数的事件源和更多事件的目标。
最后，所有这些点击都增加了一层手持式工具，使得工作比以文本文件开始更容易一些。当我创建一个函数时，浏览器有一个警告，“这个函数包含外部库”。
亚马逊还有许多其他选项，如同AWS Lambda一样“无服务器计算”，如果无服务器计算意味着解除你的服务器管理杂事。它具有弹性工具，如启动和关闭服务器的Amazon EC2 Auto Scaling和AWS Fargate，以及将你上传的代码部署到Web服务器并处理负载均衡和缩放的AWS Elastic Beanstalk。当然，对于许多这些自动化工具，仍然需要负责创建服务器映像。
AWS Step Functions是一种更有用的产品，它是一种无代码流程图工具，用于创建状态机以模拟软件架构师称为工作流的模式。部分问题是所有的无服务器函数都是完全没有状态的，当你执行非常基本的业务逻辑时，这些功能是有效的，但是当你通过一个客户端走过一些客户端时，这可能有点噩梦清单或流程图。你经常到数据库去重新加载关于客户端的信息。步骤函数将Lambda函数与状态粘合在一起。
Google Cloud Functions 和 Firebase
如果你的目标是摆脱配置服务器的麻烦，那么Google Cloud提供了许多服务，从需要根密码甚至使用命令行等方面提供各种各样的自由。
从2008年的Google App Engine开始，Google一直在慢慢地添加不同的“无服务器计算”选项，并且提供各种消息传递和数据透明组合。一个名为Google Cloud Pub / Sub的用户隐藏了消息队列，因此你只需为数据生产者和消费者编写代码即可。 Google云端函数为许多主要产品（包括某些选取框工具和API）提供事件驱动的计算。然后是Google Firebase，这是一个数据库，可将JavaScript代码混合到将数据传送到客户端的数据存储层。
其中，Firebase是我最感兴趣的。一些人认为数据库是原始的无服务器计算应用，将数据结构和磁盘存储杂事抽象出来，以通过TCP / IP端口传递所有信息。 Firebase通过添加JavaScript代码和消息传递来将这种抽象极端化，以完成你可能想要对包括身份验证在内的服务器端基础架构执行的任何操作。从技术上讲，它只是一个数据库，但它可以处理堆栈的大部分业务逻辑和消息传递。你真的可以摆脱一些客户端的HTML，CSS，JavaScript和Firebase。
你可能会像Oracle一样，试图将Firebase的JavaScript层称为“存储过程”，但这样做会忽略大局。 Firebase代码是用JavaScript编写的，因此它将以本地版本的Node.js运行。你可以在该层中嵌入大部分业务逻辑，因为Node的世界已经充满了处理此工作流的库。另外，你将享受在客户端，服务器上运行的同构代码的乐趣，现在还可以享受数据库。
引起我注意的部分是Firebase中内置的同步层。它将在整个网络中同步来自数据库的对象副本。诀窍是，你可以将你的客户端应用程序设置为另一个订阅相关数据（仅相关数据）更改的数据库节点。如果数据在一个地方发生变化，它会随处变化。你可以避免所有消息传递的麻烦，并专注于将信息写入Firebase，因为Firebase会将其复制到需要的位置。
Google Firebase提供了一个错误控制台，可以显示展示好坏事件的时间表。
你无需专注于Firebase。更基本的Google云功能是一种更简单的方法，可将定制代码嵌入到Google云中。目前，云端函数在很大程度上只是编写Node.js代码的一个选项，它将在预配置的Node环境中运行。虽然Google云端平台的其他部分支持各种语言--从Java和C＃到Go，Python和PHP云功能严格限于JavaScript和Node。有人暗示其他语言选项即将到来，如果他们很快出现，我不会感到惊讶。
至少在这一点上，Google Cloud Functions不会像AWS Lambda，当我探索构建一个与Google Docs交互的函数时，我发现我可能不得不使用REST API并将代码写入名为Apps Script的应用程序中。换句话说，谷歌Docs世界拥有自己的REST API，很久就没有服务器了。
值得注意的是，Google App Engine持续强劲。一开始，它提供了启动Python应用程序以满足任何人进入网站的需求，但多年来一直在扩展以处理许多不同的语言运行时。将代码捆绑到可执行文件中后，App Engine将处理启动足够的节点以处理流量的过程，并在你的用户发送请求时向上或向下放大或缩小。
要牢记几个障碍。与云函数一样，你的代码必须以相对无状态的方式编写，并且必须在有限的时间内完成每个请求。但是App Engine不会抛弃所有的支撑，或者在请求之间忘记所有的东西。 App Engine是无服务器革命中的一个重要组成部分，对于那些在老派方法中使用Python，PHP，Java，C＃或Go构建自己的堆栈的人来说，它仍然是最容易获得的。
Microsoft Azure Functions
当然，微软和其他人一样努力工作，以确保人们可以用Azure云做所有这些聪明的无服务器计算事情。该公司已经创建了自己的基本功能--Azure函数，并且构建了一些更复杂的工具，这些工具对于半程序员来说更加易于使用。
微软可能拥有的最大优势可能是它的Office应用程序集合，这些以前的桌面可执行文件正在缓慢而稳定地迁移到云中。事实上，云计算收入的一个核算使微软领先于亚马逊，部分原因在于将其部分Office收入纳入了“云”。
Azure Functions文档中最好的示例之一显示了某人在将电子表格保存到OneDrive时如何触发云功能。突然间，云中的小精灵活跃起来，在电子表格中做些事情。对于喜欢Excel电子表格（或其他Office文档）的IT支持团队来说，这绝对是天赐之物。他们可以编写Azure函数来做几乎任何事情。我们经常认为HTML和网络是云的唯一接口，但没有理由不能通过Microsoft Word或Excel等文档格式。
Azure的逻辑应用程序引起了我的注意，它是让你填写表单而不用担心语义和语法的工具之一。 你仍然需要像程序员一样思考，并对抽象和数据做出明智的决定，但是你可能会说服自己，你并没有像填写表格那样编写“代码”。
Microsoft Azure的Web IDE允许你编写Azure函数，运行它并通过插入日志记录调用进行调试。
像亚马逊的Step Functions一样，Logic Apps的目的是对“工作流”进行编码，这是一种流行词，比起平均的“功能”要复杂得多，这要归功于某种状态的可用性。你仍然可以用类似流程图的方式编写链接各种功能和连接器的逻辑，但是你不会用官方的计算机语言拼出它。
Logic Apps的一大优势是预先构建的“连接器”，可深入到那里的一些较大的微软和第三方应用程序中。你可以有效地将数据从SalesApp，Twitter和Office 365等Logic应用推送或提取出。这些连接对于公司IT人员来说非常有价值，他们现在可以通过编写Logic Apps来连接外部工具，就像他们创建的一样shell脚本。
Azure另一个令人感兴趣的地方是Azure Cosmos DB，同时是NoSQL和SQL的数据库。微软已经复制了Cassandra和MongoDB的API，这样你就可以在不改写Cassandra或MongoDB代码的情况下输入和输出信息。或者，如果你想写SQL，你也可以这样做。 Cosmos DB可以让事情保持直线并为所有事情建立索引，以保持其快速运行。如果你有很多你想合作的SQL和NoSQL代码，这使它成为一个有趣的中心联系。或者，也许你只是想在未来为不同的方式敞开大门。
无服务器计算比较
哪个无服务器计算平台适合你？在所有三个孤岛中编写基本函数几乎都是一样的，但是存在差异。最明显的可能是可用语言，因为每个语言在完成支持Node.js和JavaScript之后都会播放收藏夹。你可以为Microsoft的Azure编写C＃并不令人惊讶，但它对F＃和TypeScript的支持是独一无二的。亚马逊采用Java，C＃和Python。 Google目前的基本功能严格限于JavaScript，但它在App Engine中支持更多的语言。
比较无服务器计算的最难的部分是掌握价格和速度，因为更多的东西隐藏在底层。当我将虚拟机以每小时价格定价时，我常常觉得自己像个疯狂的消费者。现在，供应商正在将萨拉米香肠切片得如此薄，以至于你可以以不到一美元的价格获得数十万次函数调用。
当然，这种明显的便宜很快就会削弱我们大脑理性的，预算意识的部分，就像我们在一个陌生的国家度假时一样，这些国家的货币种类差别很大。不久之后，你将订购另外数百万次的数据库，就像你在Cancun购买一杯酒时一样，因为你无法快速分配以确定其实际成本。
当云计算推出的是一台原始的虚拟机时，你可以猜测内存和CPU的能力，但是在无服务器计算的世界中，你并不真正知道发生了什么。
值得注意的是，无服务器计算模式几乎迫使你将数据存储在本地云数据库中，因为你并不是真的被允许在代码中保留任何状态。你必须相信这些后端。你的函数必须运行没有任何本地缓存或配置，因为其他版本总是被创建和销毁。因此，数据库胶水代码填满了你的代码，就像在“陌生事物”中颠倒过来的那些藤本一样。
比较成本的唯一真正方法是在所有平台上构建应用程序，这是一项艰巨的挑战。可以在三者之间移动一些代码，因为它们都运行Node.js，但即便如此，你仍然会遇到需要忍受的差异。 （例如，你直接在Microsoft和Google中处理HTTP请求，但通过AWS中的API Gateway处理。）
好消息是你不需要那么偏执。在我的实验中，许多基本应用程序几乎不使用任何资源，你可以在免费的三层提供所有这三项优惠以吸引贫穷的开发人员。无服务器计算模式确实为我们节省了开销。除非你是一直在接近满负荷运行你的服务器的类型，并且获得了免费空调，否则很可能你最终会通过转向无服务器方式来节省一些大笔资金。你将节省如此多的资金，以至于你不会争论它是否为每百万次调用1美元或1.50美元。
有一个更深层的问题。如果你受够了这些云，你就会陷入困境。这不是很容易，只需将代码关闭并在其他地方的商业服务器上运行它，你可以使用充满自己的代码的Docker容器进行操作。如果你幸运的话，你可以复制相同的原始架构和基本的JavaScript函数，但在此之后，你将在整个地方重写数据库胶水代码。所有这三家公司都有自己的专有数据存储层。
目前还不清楚事情出错时会发生什么。运行你自己的服务器意味着，当不能工作时，你的老板会窒息你的脖子。目前还不清楚在这个领域会发生什么。 Google的一个页面包含这个良性警告，“这是Google Cloud Functions的测试版。此API可能会以不兼容的方式进行更改，并且不受任何SLA或弃用策略的约束。“
亚马逊的服务条款比他们第一次进入这个领域时的表现要好，但他们仍然包含警告要记住，例如“我们可能会在30天内通知你并且没有任何责任的情况下删除你的任何内容如果未超过三（3）个月，则上传到AWS Lambda。“确保你的代码在你想要保留的情况下运行。像这样的警告肯定是公平的（我知道我的旧Lambda函数不会再被使用），但它显示了你如何放弃一些控制。
微软为Azure服务提供服务级别协议，承诺通过服务积分对停机进行经济补偿。这些适用于你的功能降级吗？也许--只要你不徘徊在服务的某个测试区域。值得花一点时间关注这些细节，如果你打算建立比儿童聊天室更重要的任务。
,
