无服务器 = 自动驾驶操作

您将需要一个自动化和编排平台。 无服务器可能正是您所寻找的。

无服务器（又名 函数即服务 (Function as a Service) 仍处于起步阶段。 任何刚刚起步的技术往往需要回答这样一个问题：“但它有什么用？” 在几乎每天都有新发展或新技术引起我们关注的时代，情况尤其如此。

无服务器的典型用例围绕其利用云的强大功能来处理特定类型的工作负载（例如图像处理或数据挖掘）的能力。 但是，如今有些组织使用无服务器来实现更多不那么吸引人的目的，比如自动化操作。

事实上，我可能会争辩说（而且我认为我会这样认为，因为，我自己）无服务器可能是当今最有效的自动化操作手段之一。 以下是我建议您认真考虑将无服务器作为自动化操作平台的四个原因。

1. 它是事件驱动的

在事件驱动系统中，动作会导致事情发生。 事件（有时称为动作）可以通过多种方式触发，但最有可能通过 REST API 调用通过命令行（例如“curl”）或从简单的 Web 界面调用。 这包括提供服务、更新配置或禁用防火墙规则等任务。 基本上，应用投入生产（以及随后所需的网络和应用服务）被分解为一系列“操作”。 管道中的许多操作都是由前一个操作的完成触发的，这很好地映射到OpenWhisk等无服务器环境中的“操作序列”概念。 毕竟，部署编排是一个由许多较小的、单独的自动化任务组成的流程的自动化。 每一个都可以通过对无服务器环境的 API 调用来正确表示，并由总体 API 调用启动整个序列。

2. 它促进基础设施即代码和重复使用

模板和脚本符合基础设施即代码的概念，但基于无服务器的系统实际上满足该标准。 通过将部署工件和构造封装为注入到流程中的代码，可以进一步促进对部署工件和构造的重用。 这意味着可预测、可重复且一致的流程，并且可以随着时间的推移进行衡量和优化。 “一项任务、一项功能”方法进一步提高了可组合性，并能够更流畅地创建流程，可以通过基于动态生成的管道注入不同的功能来轻松驱动。

3. 它是“无服务器的”

现在，我们都知道无服务器并不是真正没有服务器。 但是同样的概念——底层硬件（和软件）基础设施对于使用它的人来说是“不可见的”——使得它对开发人员具有吸引力，也应该使它对基础设施和网络运营具有吸引力。 请记住，一旦开始自动化和协调部署管道，您将需要软件和系统来管理它。 这意味着服务器和软件必须获得许可、维护、管理、扩展和保护——好吧，你明白了。 您已经知道管理面向消费者的应用程序有多么繁重，想象一下面向运营的应用程序也是如此。 无服务器基础设施一旦建立，就会提供一个一致的平台，您可以在其上构建任意数量的工作流程，而无需担心底层基础设施。 这意味着吸引开发人员使用无服务器的相同好处也可以通过运营实现。

4. 它是多功能的 

您可能会想这到底有什么关系？ 好吧，让我告诉你。 没有一个数据中心在异构基础设施上运行，即使在单个供应商的子集中，组织也会运行多种型号和版本的硬件和软件。 组织面临的挑战之一是管理整个环境中的各种设备和版本。 大多数无服务器环境已经支持多种语言和工具集（一个操作可以用 Python 编写，另一个操作可以用 node.js 编写）以及“基于图像的”操作，这些操作是可以运行的容器。 当您试图协调由自动化如此多样化的系统的任务组成的流程时，使用最有效（也许是唯一的）工具的能力对于运营来说是一种福音。

问题在于，与大多数不断被消费者和企业用户访问和使用的应用不同，操作任务很少执行，有时（尽管我们不愿意承认）没有太多警告，作为对更广泛环境中的安全或可用性事件的响应。 这意味着像无服务器这样的事件驱动系统似乎很适合。 它提供了一个“始终在线”的平台，可以在整个操作范围内执行各种各样的任务。 一分钟它可能会执行与安全相关的任务——更新防火墙规则。 接下来，它可能会启动一项行动，将新的应用服务（比如 WAF）注入到应用的数据路径中，作为对需要立即补救的零日漏洞的响应。 同一平台可以提供以自动化和可扩展的方式执行几乎所有所需的操作任务的机制。

事件甚至可能通过票证创建或来自 Slack 等支持 ChatOps 的系统中的机器人命令来触发，并自动从票证或命令中提取所需的信息，以便在调用适当的操作来完成任务时使用。

无服务器专注于开发人员，但其底层原理和机制使其成为构建自己的运营编排系统或依赖一组松散耦合的系统（带来自身的集成和运营挑战）的有吸引力的替代方案。

如果您刚刚开始运营自动化之旅，您可能需要认真研究企业无服务器平台，看看它是否能满足您的需求。