安全且一致地管理、维护和部署应用程序和基础设施仍然是一项极其复杂的挑战。
译自 Infrastructure as Code Is Dead: Long Live Infrastructure from Code，作者 Asif Awan。
随着我们大规模实现计算现代化，配置管理工具应运而生，以简化和标准化基础设施管理。随着组织转向云端，配置和管理需求呈爆炸式增长，使得以前的手动任务几乎不可能完成。
DevOps 被创造出来是为了帮助将我们从软件中学到的自动化最佳实践实施到基础设施实践中。
云计算的转变和 DevOps 的兴起引入了 代码即基础设施 (IaC)，使我们能够像管理软件一样配置和管理基础设施。不幸的是，IaC 并没有完全兑现其轻松快速部署和维护云资源的承诺。
代码即基础设施起源于 2000 年代中期，当时我们看到亚马逊网络服务(AWS) 在 2006 年发布了亚马逊弹性计算云 (Amazon EC2) 的第一个版本，而 Puppet 和 Chef 分别在 2005 年和 2009 年引入了声明式领域特定语言 (DSL) 来帮助系统管理员自动化配置和配置。突然之间，每个人都可以根据需要使用尽可能多的计算资源，并且需要新的工具来管理他们新的、更庞大的基础设施。
当容器、微服务和 Kubernetes 在 2010 年代中后期得到更广泛的应用时，配置管理需求再次发生变化。Kubernetes 发布的同一年， HashiCorp 的 Terraform 也发布了，它提供了一种标准化云配置的新方法，并创造了“基础设施即代码”一词。
从一开始，配置管理工具就提高了配置和部署基础设施的效率，通过简化的流程和自动化工作流实现了更快的部署。通过自动化任务和最大程度地减少手动错误，IaC 降低了与基础设施管理相关的运营开销，并降低了手动管理中可能发生的错误的可能性。
希望是，由于 IaC 融入了最佳代码实践，开发人员将能够与系统管理员和其他基础设施工程师一起轻松大规模地部署代码，从而实现开发和运营团队之间的更紧密协作。
但正如 IaC 扩展了部署到云端的能力一样，它也增加了部署的复杂性，因为它将具有不同经验和专业知识的团队结合在一起，并要求他们找到新的合作方式。
尽管 IaC 带来了明显的规模和自动化优势，但它仍然非常复杂，因为云基础设施很复杂且不断变化。随着越来越多的团队参与云配置，他们必须就如何最好地使用 IaC 工具达成一致，并了解他们选择的每种工具的细微差别。随着这些额外压力的出现，有望改善开发人员体验而不增加风险的新解决方案正在涌现。为了创建下一代解决方案，组织需要了解开发、平台工程和安全团队真正面临的问题所在。
由于有多种工具和框架可供选择，对于经验源于手动基础设施配置或编写应用程序代码的团队来说，学习新语言和工具可能会很困难。除了需要新的编程语言和界面外，大多数 IaC 工具都使用声明式语言来定义和支持基础设施和资源管理。
这意味着团队必须学习如何定义基础设施环境的期望状态，而不是概述实现结果所需的步骤，这对新手和经验丰富的程序员来说都是一个挑战。
此外，每个 IaC 工具在不同的类别中都很出色，通常会导致使用多个工具来有效地管理基础设施。拥有多个工具可能会导致更多复杂性和兼容性问题，而使用多个工具并不能消除对基础设施专业知识的需求。
与目标相反，IaC 可能会拖慢软件开发生命周期，因为不同的团队致力于提供应用程序云资源。不同的利益相关者必须掌握多种 IaC 工具和语言，管理具有错综复杂的资源依赖关系的复杂基础设施，并且具备安全实施 IaC 所需的专门知识。平台工程师不堪部署请求，必须梳理基础设施配置文件，以识别可能导致权限过大、不合规或过度消耗资源的问题。这一流程意味着应用程序交付速度显著降低，让开发者沮丧不已。
在多个环境中强制执行一致的配置很困难，尤其是在部署分散在云和本地环境中时。更糟糕的是，应用程序编码人员并不总是精通安全性和设计最佳实践，而运维团队和站点可靠性工程师可能会直接对云环境进行更改，以确保高可用性或安全性。尽管 IaC 工具提供了模板来标准化跨环境的应用程序和服务部署，但配置漂移仍然可能发生。这意味着检测、跟踪和修复每个环境的那些配置更改至关重要。不知何故，团队需要将为部署创建的 IaC 文件与实时环境中存在的 IaC 文件进行比较。
开发人员不断受到推动，要求更快地交付应用程序和更新。一些团队 每周发布更新，而其他团队甚至更频繁地发布代码。但在没有更广泛的应用程序、基础设施和业务需求背景的情况下，做到这一点非常困难。平台团队的任务是在没有做出明智决策所需信息的情况下执行 IaC 审查，从而导致延迟和不可避免的人为错误。
虽然 平台工程师和 DevOps 团队正在创建旨在 帮助开发人员根据最佳实践配置基础设施的黄金模板，但开发人员仍然必须始终如一地应用这些模板，并了解如何创建安全、一致且合规的 IaC。这对开发人员来说要求很高，他们只想构建一个按照他们设计的方式工作的出色应用程序。
基础设施即代码是一种思考和处理基础设施配置的新方式，它将应用程序代码置于一切的核心。您不是使用版本控制的黄金模板为基础设施创建配置，而是根据正在部署的应用程序版本生成应用程序所需的基础设施。
您不是让应用程序适应基础设施，也不是将基础设施当作软件，让开发人员学习新的语言和基础设施概念，而是让基础设施适应应用程序不断变化的需求，同时应用必要的标准并保留版本控制的优势。这种方法极大地改善了开发人员体验，帮助他们简化流程并加速交付，无需午餐学习或研讨会培训，因此开发人员可以专注于开发，而不是配置。
随着人工智能 (AI) 和机器学习提高开发人员的产出并改变应用程序的构建和维护方式，行业需要一种解决方案，该解决方案能够随着开发团队的产出扩展安全性、自动化和效率。随着云服务发布新产品和国家采用更多网络安全和数据隐私标准，组织必须确保他们构建的基础设施经过优化、安全且不会阻碍创新。即使是最好的模板也会很快过时，必须更新，而且无法保证每个团队都会使用更新的版本。
通过代码生成基础设施，您可以将黄金标准（适用于任何基础设施的规则、指南和最佳实践）应用于 IaC 的生成，从而确保与组织批准的最佳实践、配置、软件安装和设置保持一致。然后，输出基于标准且无错误，允许开发团队真正自助式地提供资源，而无需担心由于 错误配置或安全漏洞 而使公司面临风险，并且它跳过了当今大多数策略检查提供的“扫描、报告、修改”周期。
在基础设施供应和管理方面，我们生活在一个激动人心的创新时代。我们已经看到了许多改变基础设施面貌并帮助降低应用程序部署复杂性的新工具。Kubernetes、容器和微服务都使开发和部署软件变得更加容易，从而提高了敏捷性、弹性和可扩展性。这些技术还需要专业知识才能有效地管理和使用它们。
虽然 IaC 毫无疑问地改进了手动配置数百个云和本地环境，或运行容易中断的自定义脚本，但它给开发人员增加了学习复杂的基础设施架构和概念的负担，并且还要学习新语言以及改变他们对编程的看法。安全且一致地管理、维护和部署应用程序和基础设施仍然是一项极其复杂的挑战。
现在是不是该采用一种新的方法了，一种以应用程序代码为先的方法？