无服务器是一种软件开发方法，用于快速构建和部署应用程序，实现松散耦合的模块和微服务。 根据Forrester的说法，“它提供了更好的软件开发经验，快速扩展构成应用程序的服务，降低成本，并在工作负载变化时提高基础架构利用率。“
无服务器显然是一个隐喻，就像云一样。 计算仍然需要服务器和其他物理设备。 自我管理或自主计算可能是更准确的术语。 无服务器平台通常意味着资源供应、容量规划和其他系统管理决策对开发人员和运营商完全隐藏，计算资源根据需要进行配置，定价基于其实际使用而不是预购容量。
十年前，云被视为一种有前途的技术，人们说 “有一个明确的共识：关于云计算是什么却没有真正的共识。” 这在当时很明显，虽然我们正在发生重大而深刻的事情。不完全确定它到底是什么。 十年之后，那些早期的定义辩论结束了。 云现在是公司IT战略的一个组成部分，其基础是实施变革的日常工具。
无服务器与云计算密切相关。 所有主要的云供应商都提供无服务器技术来动态管理硬件和软件资源的分配，包括亚马逊的AWS Lambda，谷歌的云功能，微软的Azure功能和IBM的云功能。还有一个开源的无服务器平台，Apache OpenWhisk，IBM的产品以及其他供应商提供的平台。 Serverless执行环境支持以各种语言开发轻量级应用程序或微服务。
我特别喜欢Mike Roberts最近关于无服务器架构的文章。Roberts认为无服务器是云系统的下一个发展方向。就像云早期的情况一样，没有人清楚地看到无服务器是什么。它包含两种不同但重叠的软件设计方法：后端即服务（BaaS），它显着地包含第三方，云托管的应用程序和服务，例如身份验证，搜索，业务服务和数据库; 和函数即服务（FaaS）， - 其中包括由应用程序开发人员编写的自定义代码，然后上传到云，仅在由特定事件触发时调用，并由云提供程序完全管理。
所有设计都涉及权衡。我发现将无服务器方法与传统的基于服务器的应用程序进行比较是有用的。 基于服务器的应用程序往往是长期存在的。 一旦加载并启动，应用程序就可以准备好并监听请求，以便他们可以快速处理它们。 开发人员负责配置支持其应用程序所需的资源，包括估计其类型和容量，如何在各个组件之间分配资源，以及如何根据应用程序的实际负载进行扩展。
云使这些活动更容易，但仍然必须完成。 必须为云提供商提供所需的估计资源，以便他们可以自行规划并有效地支持其各种客户。 而且，由于资源规划不是一项精确的活动，开发人员通常会估算出比预期更大的负载，并且无论是在内部还是通过云提供商，都会过度配置所需的资源。 最近的WSJ CIO期刊文章指出：
“通过购买更多的云计算容量，他们确实需要 - 即使是一种有意识的策略来防止关键系统崩溃 - 或购买他们永远不会使用的高级储备，所有行业的公司成本可能会平均超支42％，这是根据Densify编制的数据，Densify是一家与全球大公司合作的云优化公司。 该公司表示，根据云部署的规模，这可能会导致每年IT预算损失数十万甚至数百万美元。其估算基于去年200位云行业专业人士和70家全球公司的投入。“
无服务器基于非常不同的资源管理模型。 最大的开销是应用程序的设计。 无服务器应用程序由一组松散耦合的轻量级模块或微服务编织或组成。 每个这样的模块仅在被另一个应用程序模块触发或由外部函数调用时被赋予资源。
无服务器模块预计运行的时间相对较短，并且通常限制每次调用允许运行的时间。 模块完成运行后，其资源将返回到无服务器平台，并可供其他需要它们的模块使用。 这些模块是无状态的，意味着在调用之间不会传递或记住任何信息。 任何需要在调用中保持持久性的信息都必须明确存储在单独的文件或数据库中。
鉴于无服务器应用程序的特殊性，开发人员不再需要计划、分配或配置模块实例。 一旦模块被调用，无服务器平台将找出它所需的资源并自动配置它们。 在调用其他模块时，平台将自动为它们分配所需的资源，并在它们运行完毕后将其取出。开发人员只需为其模块实际运行期间使用的资源付费。 如果不经常调用，或者只是尖峰调用，则无需为简单资源计划和支付费用。
“无服务器架构可能会受益于显着降低的运营成本，复杂性和工程前置时间，但代价是增加了对供应商依赖性和相对不成熟的支持服务的依赖，”Roberts指出。 虽然在无服务器方面有很多需要，但他的文章也指出了一些权衡和缺点。
其中之一是响应请求可能会出现延迟。 与传统的服务器应用程序不同， 无服务器代码仅在实际调用函数时才实例化。对于某些应用程序， 这种冷启动延迟可能是不可接受的。 但是，如果频繁调用该函数，则很可能先前的调用仍在进行，并且延迟将显着缩短。无服务器供应商锁定是另一个潜在的缺点。 罗伯茨写道：“很可能你从一家供应商那里使用的无服务器功能将被另一家供应商以不同的方式实现。” “如果您想切换供应商，您几乎肯定需要更新您的操作工具（部署，监控等），您可能需要更改您的代码（例如，以满足不同的FaaS界面），并且您可能如果竞争厂商的实施行为存在差异，甚至需要改变您的设计或架构。“
测试是另一个潜在的问题。 虽然单元测试无服务器模块相对简单，但测试和调试由许多此类模块组成的无服务器应用程序非常困难。
“无服务器不是解决每个问题的正确方法，所以要警惕那些说它将取代所有现有架构的人，”Roberts写道。 “如果你现在投入无服务器系统，请小心，特别是在FaaS领域。 虽然有丰富的 - 扩展和节省的部署工作 - 需要被掠夺，但也有龙 - 调试和监控 - 潜伏在下一个角落...“作者：Irving Wladawsky-Berger