有两个行业趋势指向许多人选择 DevOps 工具的一项空白。运维团队需要的不仅是基础设施即代码的方法，而是一个完整的模型驱动的运维思想。
现代软件开发对基础设施的管理提出了更苛刻的要求：产品要适应瞬息万变的市场，要求基础设施有更快的响应速度。持续交付和 DevOps 的推行要求产品团队对部署和运维要有更高的自主性。技术的快速进步和演化，也使得基础设施的配置不得不频繁变化。在这种快速变化的过程中，要求基础设施既要灵活，也要安全、可靠。
而传统的基础设施运维管理具有以下几个问题：
被动响应。 产品团队获取服务器资源采用的是申请制，中间存在若干审批过程，以及需要等待运维团队实施，响应不及时。
自动化缺乏串联。 虽然有一定的自动化，但不能做到无人值守，需要执行一些临时命令介入。由于环境释放和重建的成本高，因而倾向于不释放，导致资源利用率低。
和产品团队脱节。 很难根据需求随时动态增加环境。需要额外的文档来描述环境，可能更新不及时。
Canonical 通过开发开源 DevOps 工具 Juju 解决这些问题，从而创建多个世界领先的产品。
2020 年的两个 DevOps 趋势
让我们考虑以下两个趋势以及它们对 DevOps 的影响。
1. 微服务将复杂性从应用程序端推到运维端
转换到 微服务 需要将复杂的大型应用程序分解成许多较小的服务单元。在“分而治之”的架构风格中，每个单元都更容易部署、扩展、更新以及独立移除。
然而，微服务体系结构可能会将复杂性推到运维端，而不是消除复杂性。
采用基础设施即代码工具可以减轻部分负担，但不是全部。突然间，你需要考虑网络延迟、消息格式和连接。每个新服务都需要连接到其他服务。
如果没有适当的工具，升级和迁移就会变得非常耗时，并且容易出错。
2. 基于容器的部署可能导致性能损失
对许多应用程序来说，基于容器的部署平台(如 Kubernetes )令人愉快。
但是，容器并非适合所有用例。数据库和其他中间件经常受到 I/O 条件的约束。当这些应用程序作为容器运行时，会导致性能损失。
大多数基础设施即代码工具都适合在单一平台上托管应用程序。但现实更为复杂。它们很少允许你跨平台部署应用程序。当容器和虚拟机搭配使用时，情况就更加复杂了。
系统工程师和运营团队希望提供最佳的性能，但他们也希望为编写应用程序的产品工程团队提供敏捷性。
最终，复杂性会影响业务。对工具进行整合的管理决策可能意味着将数据库转移到了 Kubernetes 集群中。
自动化软件出现
Canonical 开发 Juju 来解决这些问题。它的方法与其他 DevOps 工具的不同之处在于：
通过允许 DevOps 团队在更高的抽象级别上工作 降低复杂性 ;
通过允许应用程序动态响应它们的部署 提高稳定性 ;
通过将配置管理与应用程序的特定托管环境解耦 增加灵活性 。
Juju 是一种简单、安全的 DevOps 工具，用于管理当今复杂的应用程序，而不管你在何处运行软件。计算、存储、网络、服务发现和健康监测都是免费的，适用于 Kubernetes、云计算和笔记本电脑。
Juju 允许你的软件基础设施始终保持最佳配置。当部署发生变化时，每个应用程序的配置操作都由 charms 动态调整。Charms 是与你的应用程序一起运行的软件包。它们对业务规则进行编码，以适应环境变化。
使用模型驱动的思想意味着提高抽象级别。Juju 的用户很快就会习惯这样一种 灵活的、声明式的语法 。这种语法与底层无关。
Juju 与基础设施提供者交互，但是操作代码总是保持不变。我们专注于为你的产品基础设施创建一个软件模型，这可以 提高生产率并降低复杂性 。
通过在较低的抽象级别上自动化基础设施，DevOps 让这个行业获得喘息空间。但这种喘息空间正在耗尽。
用一个可同时应对多种后端的工具有几个好处： 生产率不仅提高，而复杂性保持不变 。