无服务器计算：最终取决于开发人员
无服务器计算为那些希望减轻基础设施负担的开发人员提供了很好的机会。把所有东西都进行抽象化，而只留下代码，无服务器计算模型使得开发人员能够更快地迭代和部署新代码，预算不多的小团队能够干好以前只有大公司才能做的事情。或者，正如Cloudability的创始人兼首席执行官Mat Ellis在CloudCast episode中所说的“无服务器计算有可能把开发人员的工作成果实现工业化。”
当然，在后台，服务器仍然存在，嗡嗡作响。但是无服务器架构是没有状态的。它通过执行一点点的逻辑——一个函数去完成工作，并调用其他服务来做任何需要的事情。如果您是主要通过API使用服务构建应用程序或者需要响应事件的开发人员，那么，无服务器架构可能是完成工作最简单、最快、风险最小的方法。
在本文中，我们详细阐述无服务器架构的真正含义，仔细对比了主要的公共云选择，并简要介绍可口可乐正在进行的无服务器计算项目。
无服务器计算无非就是函数
无服务器是一种云计算服务模式——就像IaaS、PaaS、SaaS、BaaS和CaaS，依赖于无处不在的、方便的、按需访问的动态资源共享池，其中包括了可配置网络、存储和计算资源。然而，无服务器计算采用不同的方法来使用这些资源。无服务器计算还没有达成一致的定义，但是已经出现了关于概念的宣言。使用无服务器计算，函数是部署的基本单元。程序员看不到任何计算机、虚拟机或者容器。
云中无服务器计算的主要服务包括AWS Lambda、Azure Functions和Google Cloud Functions。在云中，“FaaS”（函数即服务）可能是一种更好的说法。当我们说“函数”时，我们真的是指一个函数。这是一个在Node.js中编写的AWS Lambda示例：
exports.myHandler = function(event, context, callback) {
console.log("value1 = " + event.key1);
// do stuff callback(null, "some success message");
}
就这么简单。上传函数并将其连接到一个请求或者事件。当您的无服务器计算主机提供商（在本例中是AWS）检测到已发出了请求（例如，某个REST调用），或者已经发生的事件（例如，将文件添加到S3存储桶中）时，采用传递变量调用该函数，把返回参数和结果一起传回来。当然，它在实际中会更复杂，您可以添加安全限制，而这是其精髓所在。
可以采用您的提供商支持的任何语言来编写您的函数。您要做的是把输入请求或者事件映射到函数调用。每个提供商都有自己的一整套支持语言、约定、过程、成本、能力和限制要求（参见下表）。这就是“无服务器计算宣言”所说的“带上自己的代码”。
您的函数可以任意复杂，它可以通过API调用所包含的库或者外部服务。为了能够扩展，无服务器计算函数必须只使用自身可扩展的服务。
取决于提供商，代码可以直接在在线编辑器中编写，也可以作为代码文件、.zip、. jar文件或者容器上传。这也是无服务器计算的一个缺点，因为通过发布周期进行代码上传和管理的工具仍然不是很好，还需要大量的框架来填补空白。
当然，代码不可能真的任意复杂，提供商会有一些相关的限制。每个主机都有代码上传最大限制（例如，AWS Lambda为50MB）。每个主机有最长函数执行时间（对于AWS Lambda，在1到300秒之间）。每个函数在其可用的存储容量和所使用的CPU能力方面也受到限制。想要更多的内存、更好的CPU，还是更长的执行时间？那您就得付更多的钱。费用结算是提供商之间的另一区别，我们将在下面看到。
幕后：没有空闲时间
当然，幕后会有服务器，但作为开发人员，您从来不需要考虑它们。您需要知道的是您的函数。您不用再去处理容量规划、部署、扩展、安装、修补程序等。这通常被视为NoOps或者LessOps，而实际上是DifferentOps。代码仍然需要被组织、开发、构建、测试、版本化、发布、记录和监控。
由于您所看到的只是函数，因此，您的提供商负责激活您的函数以响应任何请求或者事件。当有请求进入，并且函数的空闲实例不可用时，必须把代码分配给服务器并启动。作为开发人员，您什么也不用做。是由您的提供商保证有足够的容量来处理负载。当然，在冷启动情况下，延迟命中是无服务器计算的缺点之一。
使用无服务器计算，您只有消费时才付费，当您的服务运行时才付费。您从来不用为空闲计算时间付费。其影响是巨大的。您可以建立整套基础设施，而不用支付一分钱。操作、开发和扩展成本都降低了。
相反，PaaS/IaaS是要求您为所使用的资源量付费的。PaaS提供商会为您管理服务器，但您的应用程序具有长时间运行的进程，您始终要付费——即使它们处于空闲状态。可以通过构建负载敏感的自动扩展系统来管理所使用的资源量，但是您总是要为一些超额用量付费。
状态怎么样？
您所看到的只是一个函数，因此，没有存储状态。当执行一个函数时，其计算资源可以被垃圾式地收集并重用。状态必须存储在某些其他服务中，例如数据库或者高速缓存。
为了控制计费成本，提供商对函数设置了最大执行时间。目前，对于AWS Lambda和Azure Functions这是五分钟。执行限制存在缺点。例如，如果您正在升级数据库，该怎么办？或者您的函数要对其他服务进行很多调用才能返回结果？或者您的函数有很多输入要处理？在某些情况下，这些操作需要的时间可能会超过5分钟。
除非您的函数很简单，否则函数都需要被编码为无状态、等幂、由状态机驱动的事件驱动服务，在调用之间在连续存储中保存数据。这会变得很复杂。您正常的云方法仍然有效。例如，将输入划分成批次，并将其放入工作队列中。
为了在这方面提供帮助，AWS已经创建了一项名为步进函数的新服务，它实现了一个状态机，允许函数无限期地继续下去。实际上，AWS Lambda应该更好，它不要求使用完全不同的、昂贵的服务。
标准和记录：最大的挑战
尽管无服务器计算将服务接口缩减为单个函数，有时称为纳服务（nanoservice），但总归还是很复杂。使用PaaS，计算的最小单位是应用程序。这有好处也有坏处。由于应用程序很大，启动和停止会很慢；它可能很难响应需求进行扩展；可能很难在细粒度等级上进行计费。但PaaS也易于管理、监控和调试。
把代码分散到大量的函数上，无服务器计算真的很难调试。逻辑流的跟踪分布在许多不同的日志文件中，并且调用之间没有连接。需要记录和标准，但这还不够。这方面的工具还应该继续改进。
无服务器计算提供商
怎样开始？开始使用无服务器计算时有很多选项。两个使用最广泛的：使用公共云和内部部署解决方案。
无服务器计算已经成为任何公共云的基础，因此所有主要提供商都在开发自己的产品。亚马逊有AWS Lambda，自2015年4月以来一直是GA。微软有Azure Functions，自2016年11月以来一直是GA。谷歌有Google Cloud Functions，还处于封闭alpha测试状态中。
在这三者之间怎样进行选择，如果您已经在公共云中，最好使用当前提供商的产品。无服务器计算之所以实用，主要原因是您可以使用丰富的服务和事件。这些选择最好在您的云中。但是，如果您在云中开始，稳定性很重要，那么AWS Lambda时间最长，并且是迄今为止最安全的选择。
对 于AWS Lambda，函数是独立的，尽管在实践中它们通常使用类似Serverless的框架在群中进行管理。将根据您的函数请求数量和代码执行时间向您收费。如果您想要更多的CPU，您必须分配更多的内存。
使用Azure Functions，其Function App包括了一个或者多个不同的函数，这些函数是由Azure App Service 一起管理的。Function App可以使用Consumption托管计划或者App Service托管计划。使用Consumption计划，Function App会自动调整，您按照所有函数的内存大小和总执行时间付费，其计费单位是千兆字节秒。使用App Service托管计划计费更像是EC2。
由 于Google Cloud Functions仍处于封闭alpha测试状态中，因此还不清楚关于函数操作和付费的方法。我们知道有两类函数：HTTP函数和Background函数。HTTP函数通过HTTP（S）直接调用。Background函数通过Google Cloud Pub/Sub主题上的消息或者Google Cloud Storage存储桶中的更改间接调用。
本地无服务器计算
在您自己的数据中心托管无服务器计算并不简单，尽管它变得更容易了，并且有很多选项。您仍然要建立并维护基础设施。
这是一个变化很快的领域。供应商正在争夺位置，力争在公共云大提供商的阴影下开拓出一个市场。要小心翼翼地前行，应该谨慎地看待每个应用程序的可移植性承诺。
Azure Stack 如果您的目标是像公共云那样在本地运行，那么Azure Stack (2017年中可用)看起来是最好的选择。还不知道它是怎样工作的，但其前景很好，也是云供应商之间的关键区别所在。
IBM OpenWhisk OpenWhisk是可以托管或者内部部署的IBM的FaaS。它有一个API网关，自然支持Swift和Node.js，还支持Docker镜像。它是有很好支持的产品，因此，今年应用的会更多。
Iron.io Iron.io是第一个无服务器计算提供商，但现在也不得不在大的云提供商夹缝中谋得一席之地。它提供两种选择：IronFunctions和Project Kratos。
Project Kratos是一种接受策略：它使企业能够在任何云提供商中以及内部部署中运行AWS Lambda函数，从而避免了受限于供应商。
IronFunctions是扩展策略：它是一个基于Docker的开源无服务器/FaaS平台，可以在任何地方运行：公共云、私有云和混合云，甚至在您自己的笔记本电脑上。
Fission.io Fission.io是一个有趣的无服务器计算新方法，使用Kubernetes作为其云基础设施。Kubernetes负责群管理、调度和网络。有一种看法是，Kubernetes将成为开源云基础设施的赢家，因为它有一个充满活力而且工作效率很高的开发人员社区。在Kubernetes上构建无服务器计算产品能够替代本地堆栈，这引起了人们的兴趣。
OpenStack . OpenStack目前不能自然的支持FaaS，但名为Project Picasso的 项目比较重要。它有两个主要 组 件：Picasso API和IronFunctions。Picasso使用IronFunctions提供的后端容器引擎。
做好自己的选择 无服务器计算不是火箭科学。您可以在当前基础设施之上构建自己的无服务器计算平台，发挥其所有优势，而无需迁移到新堆栈。如果您不想把自己的数据中心当成云，那么这是一个很好的选择。
无服务器计算案例研究：可口可乐
无服务器计算在实际中是怎样工作的？这里有一个案例，“可口可乐：按照企业要求运行无服务器计算应用程序”，其中可口可乐北美技术战略主任Michael Connor解释了可口可乐怎样使用AWS Lambda处理自动售货机上的交易。
一些发现：
无服务器计算比IaaS便宜三倍。每月约8千万笔交易，IaaS变得更有吸引力。
可口可乐现在强制要求采用无服务器计算解决方案，否则要解释清楚为什么不使用无服务器计算。
无服务器计算并不能解决所有问题，但它的确解决了对净收益没有贡献的问题。
无服务器计算不会浪费人力资源。它避免了垃圾工作，不必停下来给服务器打补丁。可口可乐对比了使用IaaS与无服务器计算时花费的时间（如下表所示）。
使用IaaS时，只有39%的时间花在交付业务项目上。在转向无服务器计算后，可口可乐花了68%的时间用于业务项目，这还有改进的余地。
转到亚马逊之后，启动服务器会有几分钟的冲击，而过去需要几星期的时间。当您意识到服务器整个生命周期中的维护成本时，这种冲击就显得微不足道了。据可口可乐公司Connor的说法，无服务器计算简化了这方面的工作。
可口可乐还希望开发人员开发，而不是履行开发职责。转到无服务器计算大大减少了所需的操作量，而且开发人员还能更好的应对那些仍在使用的操作。
自动售货机示例涉及到以下：
当您在自动售货机买东西时，刷自己的卡。
交易从自动售货机发送到支付网关。
支付网关向Amazon API网关提交REST API调用。
API网关调用Lambda函数。
该函数处理所有的业务逻辑：交易、信用、借记等。
通过Apple/Android推送通知服务把通知发送回用户。相应的将其提交回Apple Pay/Android Pay，因此您可以在您手机钱包中看到有一笔支出。
在这些交易之前还可能会有“买10免费送一”和其他促销。
采用Lambda，所有这一切发生在一秒钟之内，亚马逊收取的费用是一分钱的1/1,000。而且，只有客户进行交易时，可口可乐才会付费。否则，可口可乐不支付任何费用。对于Lambda，每月大约3000万次调用，每年的费用为4490美元。
使用AWS IaaS方法，T2中型服务器的成本约为每月56美元。而完全负担的成本几乎是其五倍：250美元 = 56美元（服务器）+ 150美元（管理：补丁、调用、记账）+ 30美元（安全：防病毒）+ 14美元（自动化：Puppet，Chef，Ansible）。使用六台T2中型服务器，每年的成本为12,864美元，因此，Lambda解决方案比IaaS解决方案便宜65%。
当然，有一个盈亏平衡点。如果您运行大量的交易，使用自己的设备会更便宜。对于这个例子，每月大约8000万次交易，转到IaaS看起来对可口可乐更有吸引力。
这个案例研究的另一个细节是无服务器计算怎样处理长尾生命周期。假设您刚推出首批10台自动售货机使用IaaS，您为该群支付13,000美元。那么寿命终了时会怎样？当最后这10台机器还没有完全报废时，您每年仍然要为IaaS支付13000美元。而无服务器计算可以轻松的进行调整。当您每月交易少于100万次时，这节省了99%的成本。
无服务器计算的成本非常吸引人，除非您是大批量运行。有多少服务是小批量运行的？
Todd Hoff是一名资深的分布式系统程序员，创建了highscalability.com。我不只是写，我还用。如果要试用我编写的无服务器计算软件，请访问Probot。
原文网址：
http://www.infoworld. com/article/3175761/cloudcomputing/serverlesscomputing-freedom-fordevs-at-last.html
