云运维：应用架构即代码 - Gregor

自动化是云计算的重要组成部分。随着抽象出更多的基础设施管理，云自动化的角色也转向用应用程序方式管理。用代码方式而不是YAML配置方式管理云自动化将是未来趋势：
基于 YAML/XML文档的自动化语言不能很好地表示跨应用程序组件的数据或控制流，而这就是面向对象的自动化语言显示其优势的地方：对象语言可以公开流畅的接口，从而形成出色的内部 DSL。流畅的接口特别适合表达管道和过滤器链，因为它们是线性结构。

使用伪代码并想象实现流行集成模式的预​​构建云组件，这样的自动化脚本可能如下所示：

p = new pipeline()
        .fromSource(...)
        .via(Filters.MessageFilter(...))
        .via(Filters.Translator(...))
        .via(myFunction)
        .toTarget(myDatabase);

这样的自动化脚本将比大多数 YAML 风格的语言更好地表达数据流：

• 应用程序从消息队列等源读取数据，通过过滤器和转换器路由消息，然后将其传递给无服务器函数，然后将消息存储在一个数据库。
• 有些语言甚至会提供额外的语法糖，例如通过使用JavaScript 管道运算符，但我是一个Java 老头，所以对我来说流畅的 API 已经非常棒了。
• 上述这段代码背后的实现可以部署所需的云资源，并根据需要将它们与消息通道或事件总线连接。

以这种方式表达云应用程序的结构使得插入队列或另一个过滤器成为单行更改，这是一个称为可组合性的理想特性。您可能想要替换源或目标以便于测试，巧妙地使用可组合性来帮助可测试性。现在，如果这听起来不像我们正在将适当的软件工程引入云自动化......

一旦我们考虑到我们正在构建和运行的系统的这种完全不同的视图，我们就可以很容易地理解为什么无服务器开发人员更喜欢面向对象的自动化语言。

如果您所做的只是定义资源图，那么面向对象的自动化语言并不是特别有用。
但是，一旦您的编程模型不仅仅是定义一个简单的资源图，面向对象的自动化语言就会大放异彩。

组合和抽象之间的区别：
结论是找到好的抽象并不容易。
对自动化语言的讨论为我们提供了一种额外的见解：我们意识到，为了找到更好的抽象，我们不能只是向上抽象来寻找更高级别的构造。有时，最有用的抽象来自对系统采取完全不同的看法，有点像平行宇宙。考虑到对流程和数据流与包含和资源图的关注作为不同的宇宙，可能可以解释我们在自动化语言方面看到的激烈争论。
也许基础设施工程师来自火星，应用程序开发人员来自金星。