基础设施即代码的误区和规避方法

有两个行业趋势指向许多人选择 DevOps 工具的一项空白。运维团队需要的不仅是基础设施即代码的方法，而是一个完整的模型驱动的运维思想。

在 ThoughtWorks 洞见黄博文的一篇文章中，作者指出：

现代软件开发对基础设施的管理提出了更苛刻的要求：产品要适应瞬息万变的市场，要求基础设施有更快的响应速度。持续交付和 DevOps 的推行要求产品团队对部署和运维要有更高的自主性。技术的快速进步和演化，也使得基础设施的配置不得不频繁变化。在这种快速变化的过程中，要求基础设施既要灵活，也要安全、可靠。

而传统的基础设施运维管理具有以下几个问题：

• 被动响应。产品团队获取服务器资源采用的是申请制，中间存在若干审批过程，以及需要等待运维团队实施，响应不及时。

• 自动化缺乏串联。虽然有一定的自动化，但不能做到无人值守，需要执行一些临时命令介入。由于环境释放和重建的成本高，因而倾向于不释放，导致资源利用率低。

• 和产品团队脱节。很难根据需求随时动态增加环境。需要额外的文档来描述环境，可能更新不及时。

2020 年的两个 DevOps 趋势

让我们考虑以下两个趋势以及它们对 DevOps 的影响。

1.微服务将复杂性从应用程序端推到运维端

转换到微服务需要将复杂的大型应用程序分解成许多较小的服务单元。在“分而治之”的架构风格中，每个单元都更容易部署、扩展、更新以及独立移除。

然而，微服务体系结构可能会将复杂性推到运维端，而不是消除复杂性。

采用基础设施即代码工具可以减轻部分负担，但不是全部。突然间，你需要考虑网络延迟、消息格式和连接。每个新服务都需要连接到其他服务。

如果没有适当的工具，升级和迁移就会变得非常耗时，并且容易出错。

2.基于容器的部署可能导致性能损失

对许多应用程序来说，基于容器的部署平台（如Kubernetes）令人愉快。

但是，容器并非适合所有用例。数据库和其他中间件经常受到 I/O 条件的约束。当这些应用程序作为容器运行时，会导致性能损失。

大多数基础设施即代码工具都适合在单一平台上托管应用程序。但现实更为复杂。它们很少允许你跨平台部署应用程序。当容器和虚拟机搭配使用时，情况就更加复杂了。

系统工程师和运营团队希望提供最佳的性能，但他们也希望为编写应用程序的产品工程团队提供敏捷性。

最终，复杂性会影响业务。对工具进行整合的管理决策可能意味着将数据库转移到了 Kubernetes 集群中。

自动化软件出现

Canonical 开发Juju来解决这些问题。它的方法与其他 DevOps 工具的不同之处在于：

• 通过允许 DevOps 团队在更高的抽象级别上工作降低复杂性；

• 通过允许应用程序动态响应它们的部署提高稳定性；

• 通过将配置管理与应用程序的特定托管环境解耦增加灵活性。

Juju是一种简单、安全的 DevOps 工具，用于管理当今复杂的应用程序，而不管你在何处运行软件。计算、存储、网络、服务发现和健康监测都是免费的，适用于 Kubernetes、云计算和笔记本电脑。

Juju 允许你的软件基础设施始终保持最佳配置。当部署发生变化时，每个应用程序的配置操作都由 charms 动态调整。Charms 是与你的应用程序一起运行的软件包。它们对业务规则进行编码，以适应环境变化。

使用模型驱动的思想意味着提高抽象级别。Juju 的用户很快就会习惯这样一种灵活的、声明式的语法。这种语法与底层无关。

Juju 与基础设施提供者交互，但是操作代码总是保持不变。我们专注于为你的产品基础设施创建一个软件模型，这可以提高生产率并降低复杂性。

通过在较低的抽象级别上自动化基础设施，DevOps 让这个行业获得喘息空间。但这种喘息空间正在耗尽。

用一个可同时应对多种后端的工具有几个好处：生产率不仅提高，而复杂性保持不变。

有两个例子，大家可以进一步阅读：

• Open Source MANO (OSM) 是由 Telefonica、BT 和 Telenor 等全球电信服务提供商支持的 ETSI NFV MANO 栈的一个开源实现。通过提供一个实现服务编排功能的原生框架，Juju charms 被 OSM 社区选为开源 MANO 项目背后的引擎。

• Canonical 为OpenStack和Kubernetes提供的托管服务为私有云和容器编排平台提供最快且最经济的路径。成本降低是通过工具（即 Juju）的增强实现的。

英文原文：

Infrastructure-as-Code mistakes and how to avoid them