无休止的管理服务器的麻烦是大型云公司采用“无服务器”架构的原因之一。他们知道老板已经听够了服务器出现问题的借口。如果能把那些服务器干掉，老板肯定会考虑的。借助AWSLambda、GoogleCloudFunctions和MicrosoftAzureFunctions，您可以让小型业务逻辑变得更好。如果您曾经因为服务器宕机而在凌晨3点醒来，您就会理解为什么像“无服务器”这样的流行语如此吸引人。这些设备可能需要数小时、数天甚至数周的时间来配置，然后需要不断更新以修复错误和安全漏洞。这些更新通常会产生自己的问题，因为新更新会导致与其他更新不兼容，或者工作似乎永远不会结束。管理服务器永无休止的麻烦是大型云服务公司采用“无服务器”架构的原因之一。他们知道老板已经听够了服务器出现问题的借口。如果能把那些服务器干掉，老板肯定会考虑的。这是一种很棒的销售语言，但唯一的问题是它不太正确。这些应用程序是无服务器的，就像没有厨房的餐厅。如果菜单上有您想要的东西并且您喜欢厨师的烹饪方式，那么坐在餐厅里就很棒。但如果你想要不同的菜，如果你想要不同的调味料，那么你绝对有自己的厨房。亚马逊、谷歌和微软是三大玩家，它们正在为管理应用程序的未来而战，它们希望将这些应用程序写入到它们的无服务器API中，并通过它们的自动化层进行管理。如果这些平台提供了你想要的东西，并且这些新模型非常通用，那么这些平台可能是创建你自己的价值数十亿美元的独角兽Web应用程序的最简单、最快捷的方式。您只需编写关键的逻辑部分，平台会处理所有细节。无服务器功能正在成为连接所有云功能的粘合剂或脚本语言。曾经相当独立的地图或人工智能工具现在通过事件驱动的无服务器功能连接起来。现在可以通过请求在每个云的不同部分产生涟漪和反弹，生成触发器并被一系列事件触发来处理更多的工作。如果您想了解机器学习技术并使用它来分析您的数据，最快的方法之一是创建无服务器应用程序并开始将事件发送到云的机器学习部分。隐含的承诺是一切都将被切得更薄，这样云中的资源就可以更容易地共享。以前大家会疯狂的创建新的实例，比如在自己的虚拟机上运行UbuntuServer。每个人都使用相同的操作系统，这个系统在同一个真实的盒子上被复制了无数次，伪装成十几个或更多的虚拟Ubuntu盒子。无服务器操作避免了所有重复操作，使云计算成本更低，特别是对于偶尔运行的作业，并且永远不会堵塞空调服务器机房中的旧箱子。当然，所有这些便利都有隐性成本。如果你想离开或想将你的代码移动到另一个站点，你可能会被困在重写大部分堆栈中。这些API是不同的，虽然像JavaScript这样的流行语言有一些标准化，但它们更接近于专有技术。用户被锁定的机会有很多。为了了解无服务器的吸引力，我花了一些时间构建一些功能并尝试使用堆栈。我没有写太多代码，但这就是重点。我花了更多时间单击按钮和输入Web表单来配置所有内容。您还记得我们使用XML和JSON来配置所有内容吗？现在我们填写一个Web表单，云为我们完成了所有工作。不过，您必须像程序员一样思考并了解幕后发生的事情，以及您无法控制的事情。AWSLambda计算服务AWSLambda正在成长为亚马逊整个云的shell脚本层。这是一个基本系统，可让您嵌入响应事件的功能，这些事件可能由亚马逊云基础设施的任何部分生成。如果一个新文件上传到S3，你可以让它触发一个函数并做一些有趣的事情。如果有视频正在使用AmazonElasticTranscoder媒体转码工具进行转码，您可以等待转码完成后触发Lambda函数。这些功能反过来可以触发其他Lambda操作，或者可能只是向某人发送更新。您可以使用JavaScript(Node.js)、Python、Java、C#和Go编写Lambda函数。鉴于这些语言可以嵌入到许多其他语言中，运行其他代码如Haskell、Lisp甚至C++是很有可能的。（请参阅这篇关于将遗留C++编译为用于AWSLambda的库的文章。）编写Lambda函数通常比您预期的要复杂，因为Amazon提供了许多配置和优化选项。虽然从技术上讲，您可以编写几行代码并做一些不错的事情，但我觉得我必须花更多时间配置代码的工作方式。大部分工作是通过在浏览器中填写表格而不是输入文本文件来完成的。有时感觉就像我们只是将文本编辑器换成了浏览器表单，但这是为Amazon为Lambda用户提供的更高灵活性所付出的代价。其中一些额外的步骤是亚马逊为用户提供更多选择并期待更多黑客函数编写者的结果。一旦我在Google或Microsoft上编写了一个函数，我就可以将我的浏览器指向正确的URL并立即对其进行测试。亚马逊让我点击配置API网关，并在防火墙中打开相应的漏洞。***，所有这些点击都添加了一层辅助工具，使工作比使用文本文件开始更容易一些。当我创建一个函数时，浏览器弹出一个警告，“这个函数包含外部库”。在纯node的时代，这是我希望知道的，或者我可以google错误信息并希望找到答案来学习。而现在云正在赶来帮忙。如果无服务器意味着将您从管理服务器的繁琐工作中解放出来，那么亚马逊还有许多其他“无服务器”选项，例如AWSLambda。它具有弹性工具，如AmazonEC2AutoScaling和AWSFargate，可启动和关闭服务器，以及AWSElasticBeanstalk工具，可将您上传的代码部署到Web服务器并处理负载平衡和扩展。当然，对于其中许多自动化工具，您仍然需要负责创建服务器映像。更有用的产品是AWSStepFunctions，这是一种无代码流程图工具，用于创建状态机来模拟软件架构师所说的工作流。部分问题是所有无服务器功能都是完全无状态的，当您执行非常基本的业务逻辑时这很好，但是当您通过清单或流程图处理客户端问题时，这些功能可能会是一场噩梦.您经常去数据库重新加载有关客户端的信息。StepFunction将Lambda函数与状态相结合。GoogleCloudFunctions和FirebasePlatform如果您的目标是消除配置服务器的麻烦，GoogleCloud提供了许多服务来简化您的操作，例如输入您的root密码，甚至使用命令行。从2008年的GoogleAppEngine平台开始，Google一直在慢慢添加不同的“无服务器”选项，并整合各种消息传递和数据透明度。一个名为GoogleCloudPub/Sub的工具对用户隐藏了消息队列，所以你只需要为数据生产者和消费者编写代码。GoogleCloudFunctions为许多主要产品提供事件驱动的计算，包括某些选取框工具和API。然后是GoogleFirebase平台，它是一个功能强大的数据库，可让您将JavaScript代码混合到数据存储层中，从而将数据传递给客户端。其中，Firebase平台是我最感兴趣的。有些人认为数据库是原始的无服务器应用程序，将数据结构和磁盘存储的工作抽象出来，通过TCP/IP端口传递所有信息。Firebase平台通过添加JavaScript代码和消息传递功能来完成您想要在服务器端基础架构中执行的几乎所有操作，包括身份验证，从而使这种抽象发挥最佳作用。从技术上讲，它只是一个数据库，但它处理堆栈的大部分业务逻辑和消息传递。你真的可以摆脱一些客户端HTML、CSS、JavaScript和Firebase平台。您可能想像Oracle一样将Firebase平台的JavaScript层称为“存储过程”，但这样做会遗漏更多。Firebase代码是用JavaScript编写的，因此它将与本地版本的Node.js一起运行。您可以将大部分业务逻辑嵌入这一层，因为节点环境已经充满了处理此工作流的库。另外，您将享受到在客户端、服务器和数据库上运行的同构代码的乐趣。引起我注意的部分是Firebase中内置的同步层。它通过网络同步来自数据库的对象副本。诀窍是您可以将客户端应用程序设置为另一个订阅所有相关数据（并且仅相关数据）更改的数据库节点。如果数据在一个地方发生变化，则它会在所有地方发生变化。您可以避免所有消息传递的麻烦，并专注于将信息写入Firebase，因为Firebase会将其复制到需要的位置。您不需要只关注Firebase。更基本的GoogleCloudFunctions是在整个GoogleCloud中嵌入自定义代码的更简单方法。目前，CloudFunctions在很大程度上只是编写将在预配置的Node环境中运行的Node.js代码的一种选择。虽然其余的GoogleCloudPlatform支持多种语言，包括Java、C#、Go、Python和PHP，但CloudFunctions仅限于JavaScript和Node。有迹象表明其他语言选项即将出现，如果它们很快出现我也不会感到惊讶。至少在这一点上，GoogleCloudFunctions不会像AWSLambda进入AWS那样深入到GoogleCloud。当我尝试构建一个与GoogleDocs交互的功能时，我发现我可能必须使用RESTAPI并将代码写入一个名为AppsScript的应用程序。换句话说，GoogleDocs环境有自己的RESTAPI，在这个流行词出现之前很久就已经是无服务器的了。值得注意的是，GoogleAppEngine继续变得更加强大。它最初是作为启动Python应用程序以满足访问者进入网站的需求的一种方式，但多年来扩展了功能，现在可以处理许多不同的语言运行时。将代码打包成可执行文件后，AppEngine启动流程，打开足够多的节点来处理流量，并在用户发送请求时增加或减少数量。要记住的是，仍然存在一些障碍。与云函数一样，您的代码必须以相对无状态的方式编写，并且每个请求都必须在有限的时间内完成。但是AppEngine不会丢弃所有的脚手架，也不会忘记请求之间的所有内容。AppEngine是无服务器革命的重要组成部分，对于那些仍在采用旧方法并使用Python、PHP、Java、C#或Go语言构建自己的堆栈的人来说，它仍然是最易于访问的平台。MicrosoftAzure功能当然，Microsoft正在像其他所有人一样努力工作，以确保人们可以使用MicrosoftAzure进行所有无服务器架构工作。Microsoft已经创建了自己的处理事件的基本函数，即AzureFunction，并且还构建了一些更复杂的工具，这些工具对于不太熟练的程序员来说更容易使用。也许微软拥有的最大优势是它的Office应用程序集合，这些以前的桌面可执行文件正在缓慢但稳步地迁移到云端。事实上，微软在云计算收入的一项指标上领先于亚马逊，部分原因是微软将其部分Office收入计入短期“云”计算收入。AzureFunctions文档中最好的示例之一展示了当有人将电子表格保存到OneDrive时如何触发云函数。突然，云端的小精灵活了过来，可以用电子表格做点什么了。对于喜欢Excel电子表格（或其他Office文档）的IT支持团队来说，这绝对是天赐之物。他们可以编写AzureFunctions来做几乎任何事情。我们通常认为HTML和Web是连接云的唯一接口，但您没有理由不能通过MicrosoftWord或Excel等文档格式连接到云。Azure的逻辑应用程序引起了我的注意，它是一种可以帮助您填写表单而无需担心语义和语法的工具。您仍然需要像程序员一样思考，并就抽象和数据做出明智的决定，但您可能会说服自己，您编写“代码”的方式与填写表格的方式不同。与亚马逊的StepFunctions一样，LogicApps旨在对“工作流”进行编码，这是一个比普通“函数”复杂得多的流行词，这要归功于某种状态的可用性。您仍然可以以类似流程图的方式编写链接各种功能和连接器的逻辑，但您不会像正式的计算机语言那样指定它。LogicApps的一大优点是预建的“连接器”可以深入Microsoft和第三方的一些较大的应用程序。您可以高效地从逻辑应用程序以及Salesforce、Twitter和Office365等程序中推送或提取数据。这些连接对于企业IT人员来说非常有价值，他们现在可以编写逻辑应用程序来与外部工具交互，就像他们过去创建外壳脚本。Azure的另一个有趣方面是AzureCosmosDB，它既是NoSQL数据库又是SQL数据库。Microsoft已经复制了Cassandra和MongoDBAPI，这样您就可以在不重写Cassandra或MongoDB代码的情况下输入和输出信息。或者，如果您想编写SQL语句，您也可以这样做。CosmosDB使内容直观并为所有内容编制索引以使其快速。如果您有大量需要同时使用的SQL和NoSQL代码，这将是一个非常好的中央连接。或者，也许您只是想为将来采用不同的方法敞开大门。无服务器云比较哪种无服务器平台适合您？在这三个不同的平台上编写基本函数几乎是一样的，但也有一些不同。最明显的区别可能是可用的语言，因为这些平台中的每一个都会在完成对Node.js和JavaScript语言的支持后使用它们的首选语言。微软的Azure可以用C#编写并不奇怪，但它对F#和TypeScript语言的支持是最好的。Amazon支持Java、C#和Python语言。谷歌目前的基础功能严格限于使用JavaScript语言，但在AppEngine中支持更多语言。比较无服务器云最困难的事情是掌握它们的价格和速度，因为隐藏在幕后的东西太多了。当我启动虚拟机并按小时收费时，我常常觉得自己是个疯狂的挥霍者。现在，提供商正在将他们的服务切分得如此精细，以至于您只需不到一美元就可以获得数十万个函数调用。你会像电影《王牌大战》中的“邪恶博士”一样一遍又一遍地说“百万”这个词。当然，这种明显的低价很快侵蚀了我们大脑中理性和精打细算的部分，就好像我们在一个面额完全不同的陌生国家度假一样。不久之后，您将像在墨西哥坎昆的一家酒吧喝酒一样订购更多的数百万次数据库调用，因为您无法足够快地转换价格来确定实际成本。当云计算给你一个原始的虚拟机时，你可以猜测它的内存容量和CPU性能，但在无服务器环境中，你并不知道内部配置。值得注意的是，无服务器几乎迫使您将数据存储在本地云数据库中，因为它不允许您在代码中保留任何状态。您必须信任这些后端架构。您的函数必须在没有任何本地缓存或配置的情况下运行，因为总是会创建和销毁其他版本。因此，数据库胶水代码将填充您的代码，就像《怪奇物语》（怪奇物语）电影中颠倒的那些藤蔓一样。比较成本的唯一现实方法是在所有平台上构建应用程序，这是一项艰巨的挑战。可以在这三者之间移动一些代码，因为它们都运行Node.js，但即便如此，您仍然会遇到并忍受一些差异。（例如，您在Microsoft和Google中直接处理HTTP请求，但在AWS中通过API网关。）好消息是您不必如此偏执。在我的实验中，很多基础应用几乎不占用资源，你可以长期使用这三个平台提供的免费资源。这些资源旨在吸引不想付费的开发者。无服务器模型确实为我们节省了开销。除非你的服务器总是接近满负荷运行并且在一个有免费空调的机房里，否则你正在将你的业务转移到无服务器上，这可能最终会为你节省一些大笔资金。您将节省很多钱，以至于您不计算每百万次函数调用是1美元还是1.50美元。还有一个更深层次的问题。如果你受够了这些云，那你就有麻烦了。这不像将代码取出并在别处的商品服务器上运行它那么容易，但您可能希望使用装满您自己的代码的Docker容器来完成它。如果幸运的话，您可以复制相同的原始架构和基本的JavaScript功能，但在那之后，您将到处重写数据库胶水代码。这三个公司都有自己专有的数据存储层。目前还不清楚如果出现故障会发生什么。运行您自己的服务器意味着当您的老板无法正常工作时，您需要立即解决问题。目前尚不清楚该地区会发生什么。GoogleInc.页面包含一个温和的警告，“这是GoogleCloudFunctions的测试版。此API可能会以不兼容的方式更改，并且不受任何服务水平协议(SLA)或弃用政策的约束。”约束。”亚马逊的服务条款比刚进入这个领域时要好一些，但它仍然包含一些您需要牢记的注意事项，例如：“如果您上传到AWSLambda的任何东西都没有被使用，我们将在30天内通知您并可能会删除它而不承担任何责任。”如果您想将代码保留在亚马逊云中，请确保您经常运行它。像这样的警告当然是公平的（这样我就知道我的旧Lambda函数将不再使用），但它也表明您如何放弃一些控制权。Microsoft为Azure服务提供服务级别协议，承诺通过服务积分对停机时间进行经济补偿。这些承诺是否适用于您的函数也有故障？也许，只要您不使用某些测试版服务。如果您要构建比儿童聊天室更大的东西，花一点时间注意这些细节是值得的。在大多数情况下，什么你真正想做的是比较亚马逊、谷歌和微软云中的其他功能和服务，不在功能层面。如果你支持喜欢使用Office应用程序的用户，那么使用OneDrive上的Office文件触发AzureFunctions的功能对你来说是最有吸引力的。借助GoogleFirebase平台，可以轻松使用各种功能为Web应用程序提供消息和身份验证等支持服务。AWSLambda为许多Amazon服务提供支持，似乎没有任何限制。从技术上讲，混合和匹配所有这些云和功能是可能的，因为它们都使用相同的PUT和GET语言来调用HTTPAPI。你没有理由不使用这些集成了很多微服务的应用程序，因为这些应用程序结合了三个云平台的最佳功能。但是，当数据包离开您的本地云并穿越开放互联网的荒野时，您最终会遇到更大的延迟。然后，在解析和结构上存在细微差别，这使得在一家公司的温暖环境中坐下来工作更容易。因此，至少在涉及相互关联的应用程序时，使用单个云的安全部分可能更合理。你真的喜欢谷歌地图吗？您想将它们用于您的项目吗？好吧，即使在您的心里，您也可以使用GoogleCloudFunctions而不是将F#语言与Microsoft的AzureFunctions一起使用。亚马逊的语音识别、谷歌的图像分析API或数十种不同服务和机器学习API中的任何一种也是如此。功能并不那么重要，真正重要的是它们之间的相互联系。
