为了真正发挥 IaC 的力量,组织需要超越工具选择和编排,关注一些至关重要的但经常被忽视的方面。
译自 Beyond Orchestration: A Comprehensive Approach to IaC Strategy,作者 Eran Bibi。
在过去十年中,随着云(原生)技术的广泛采用,基础设施即代码 (IaC) 成为实现前所未有的增长和管理极其复杂系统的核心。然而,与其他领域一样,IaC 领域也经历了相当大的变化。
仅今年一年,HashiCorp 就用更严格的许可证取代了其开源的 Terraform 许可证,社区也对此最普遍的工具进行了分叉。(我最近在 KubeCon 巴黎的一个小组讨论中谈到了这个问题,名为“IaC 的演变:关于开源和其他一切”。)
这使得我们,作为平台工程师和 DevOps 专业人员,在制定 IaC 策略时面临着两个主要难题:
虽然这些问题无疑至关重要,但它们只是全面 IaC 策略应该包含的内容的皮毛。随着 IaC 现在成为我们交付软件及其运行的关键系统的方式的支柱——CrowdStrike 停机 只是其中一个例子,说明了这可能会出错——我们的 IaC 策略将直接影响我们的业务运营。为了真正发挥 IaC 的力量,组织需要超越工具选择和编排。这些实际上只是实现细节。让我们探讨一下那些经常被忽视的方面,这些方面可能会成败您的 IaC 操作和系统工程。
IaC 覆盖率代表通过 IaC 管理的云资源的百分比。这一关键指标提供了对云基础设施管理的健康状况和成熟度的洞察。
为什么 IaC 覆盖率如此重要?
尽管它很重要,但大多数云提供商都没有提供对该指标的可见性。如果您不了解您的 IaC 覆盖率,您基本上就是在云管理工作中盲目行动。
我们多年来编写基础设施代码的经验表明,所有这些因素结合在一起,通过更好的护栏、治理和可维护性,随着时间的推移,可以提高系统健康状况和稳定性。当系统没有被编码时——这在很大程度上导致了下一条——这有时是旧系统和遗留系统的副产品,很难可视化、管理和维护系统,甚至从故障中恢复。
Lambda 今年将迎来 10 周年纪念,所以我们不要谈论 Amazon Elastic Compute Cloud (EC2),它将在 2026 年迎来 20 周年纪念。对于现在进入该行业的年轻工程师来说,云已经存在了很长时间——云之前没有时间。然而,对于更有经验的工程师来说,我们知道之前发生了什么(而且并不漂亮)。
我们发现,在采用 IaC 时,组织通常专注于新部署,而忽略了现有基础设施——一些预云或早期云时代,当时所有内容都是通过控制台管理的。这种疏忽会导致混合状态,其中一些资源通过 IaC 管理,而另一些资源仍然是“ClickOps”控制台创建(不受 IaC 管理,并且没有获得上面提到的 IaC 的好处)。
ClickOps 挑战在于:
如果没有针对现有资源的策略,组织就有可能延续分裂的基础设施,从而削弱 IaC 采用的优势。此外,我们都了解到,有时我们最传统的系统是我们的业务“摇钱树”和关键任务系统。这不仅仅是让它们保持未编码和未管理的问题。这些通常是当它们出现故障时会造成最大伤害,并且在没有快速恢复时会造成最大痛苦的主要系统。
在大型组织中,在所有部门强制执行单一的 IaC 工具通常是不切实际的。如今,有各种各样的工具可以满足不同的堆栈、优势和与开发人员的协作——从特定平台的原生工具(CloudFormation 或 Azure 的 ARM),到多云或云原生工具,从 Terraform 和 OpenTofu,到 Helm 和 Crossplane,以及针对开发人员的工具,如 Pulumi 或 AWS Cloud Development Kit (CDK)。不同的团队可能会根据其专业知识、用例或特定项目需求偏好不同的工具。
强大的 IaC 策略必须考虑:
忽略这种多 IaC 现实会导致孤岛、可见性降低和治理挑战。就像今天许多团队根据从性能到复杂性、开销维护等各种标准选择其云、编程语言和堆栈一样,IaC 也是如此。由于不同的工具针对不同的堆栈和用例进行了优化,因此了解如何在这一领域管理众多工具是强大 IaC 策略的一部分。
作为 DevOps 和平台工程师,我们开发了一个平台,我们在多年来管理大规模云集群时自己也需要这个平台。一个不仅解决工具和编排,而且解决全面 IaC 策略所有方面的平台,可以决定是凌晨 2 点的停机时间还是一夜好眠。
这样一个单一平台可以改变工程团队对 IaC 的方法,并随着不断变化的云环境而发展:
随着云变得越来越复杂和发展,我们管理它的方法也必须随之发展。通过超越工具选择和编排,并确保您的 IaC 策略侧重于包括 IaC 覆盖率、传统资源管理和多 IaC 支持在内的其他关键方面,组织可以释放其云基础设施的全部潜力。