As-Code： 持续 IT 堆栈
任何技术趋势都会有一些术语，它们很快就会被过度炒作以致于实际上变得毫无用处。 一开始，云就是其中之一。 从某种程度上来说，现在依然如此。 DevOps 花了几年的时间才理清思绪（如果已经理清的话）。 机器学习和人工智能目前正在炒作浪潮中赤脚冲浪，并且短期内没有消亡的迹象。
紧随其后的是“代码”。
突然间，一切都变成了“代码”。 市场对“即代码”的需求永无止境，尽管大多数人无法区分 C、C++ 和 C# 之间的区别。 “作为代码”已经成为生命、宇宙和一切的答案。 没有什么问题是“即代码”解决不了的，而且每个人都在这么做。
当术语被毫无界限或没有明确定义地随意使用时，重要的是我们要停下来并确保我们清楚我们的定义。 如果有一个标准委员会并且有一个 RFC 风格的定义可以参考那就太好了，但是现在却没有。 我们最接近的机构是 NIST，并且我们看到了他们如何出色地解决云难题。
“as-code” 不仅仅是基础设施即代码 (IAC)。 Aiman Najjar @ Pythian撰写了一篇关于当前基础设施即代码格局的精彩概述。 虽然我不同意容器应该有自己的层（从网络和应用服务的角度来看它只是基础设施）并且 Jenkins 不属于这个层，但总的来说他的博客是理解“代码”层关系和为正确的工作映射正确的工具的绝佳方式。 而且，大多数基础设施即代码讨论都集中在持续交付上——即构建、测试、集成和发布应用程序到生产的流程。 这与持续部署的过程不同，持续部署的重点是将发布的应用连同所需的网络和应用服务一起部署到生产环境中。
注意在应用程序乌托邦中，交付和部署管道是融合的。 但是我们大多数人（仍然）生活在应用程序现实中，其中生产和开发是具有不同要求和约束的独立环境。 因此，当我们将自动化应用于管道时，需要认识到这种分离。
有三个不同的层次来涵盖 IT 和部署管道固有的怪癖。 其中最重要的是环境固有的复杂性。 我们在网络图中绘制的从客户端到应用程序的直线并不能欺骗任何人。 引擎盖下发生的事情比我们有时间（和耐心）绘制的要多得多。
管道本身的多样性 - 包括专用硬件以及部署在 COTS 上的虚拟和基于容器的软件 - 也为将“代码”切分为不同的层提供了动力。 虽然确实可以通过代码方式管理更现代的硬件，但传统（共享）硬件几乎不可能融入到这一过程中。 然后，分离各层以更紧密地反映部署过程本身，可以提供一种方法，将传统和现代的基于硬件的解决方案以及基于软件的服务纳入管道中。
目标是建立一个连续的 IT 堆栈，能够在多云环境中支持每个应用程序的部署计划和架构。 而且由于部署只是应用程序活跃生命周期的开始，因此需要有第四层来专注于部署后操作。 这是对涵盖基础设施配置和入职、服务配置和管理以及部署管道的三个核心层的补充。
该工具列表并不算是全部内容。 还有许多其他工具和工具集。 例如，我们从多项调查和研究中了解到，大部分 NetOps 更喜欢使用定制的 Python 脚本来完成网络和应用服务自动化的任务。 我们还知道，Cisco ACI、VMware NSX、OpenStack 和 Red Hat OpenShift 等网络自动化系统和堆栈是实现持续操作堆栈中许多功能的流行手段。 视觉效果中根本没有足够的空间来包含所有工具，因此我们根据工具在 DevOps 中的受欢迎程度进行抽样。 这是因为整个交付和部署流程的标准化是成功的关键要素，而且很难反对利用组织中最常用的工具来实现“即代码”交付流程。 值得注意的是，我没有列出任何“操作即代码”的工具，因为其中许多是定制的（自定义脚本）或特定于供应商技术 - 至少目前如此。
注意：代码操作相当于 IT 中的业务流程管理 (BPM)。 通过 BPM，业务流程实现自动化。 一些 BPM 仅关注非常具体的工作流程，其他 BPM 可能涵盖从购买到付款到交付的客户互动的整个过程。 如今，代码化运营是 IT 领域的一项新兴实践，但如果企业能够像利用 BPM 一样利用优化运营流程，那么它就需要发展成为运营流程管理。
持续运营堆栈
基础设施即代码 (IaC)
无论是在云端还是在数据中心，仍然有一个需要配置的网络。 即使是更高级别的服务（在第 4-7 层运行的服务，又称应用服务）也需要一些网络拓扑知识才能运行。 如果您正在部署全新的管道，则可能需要激活（即许可）其中一些。 基础设施即代码对于实现自助服务部署方式是必要的，因为如果没有基础设施（软件和服务），就无法配置或部署应用程序。
职责：基础设施入职、许可、配置
配置即代码（CaC）
这是与配置不同的一个问题，它具体说明了需要针对所讨论的服务配置特定的策略和行为。 每次重大应用更新时，配置可能会重复。 每次小更新后也可能再次出现。 对于与安全相关的服务，可能会紧急修补、更新或升级给定的服务。 配置即代码对于支持每个应用程序的部署计划和管道以及强制隔离应用数据路径（对于确保整个生产管道的稳定性很重要）至关重要。
职责：服务配置、升级和补丁
管道即代码 (PaC)
然后是从头到尾定义整个应用及其服务的总体过程。 它是整个管道，并被编码为可执行过程，可自动驱动部署。 管道即代码是 IaC 和 CaC 之间的链接，将它们联系在一起以描述我们所谓的部署管道。 在管道中可以最大程度地提高速度和效率，因为它可以消除流程中所需步骤之间的等待时间。
职责：部署流程自动化
操作即代码 (OaC)
此层为正在进行的业务层。 它是监控和警报、自动扩展和发现发生的地方。 在此层中，我们关心的是将操作流程编码为能够自行执行的系统。 自动扩展是最常见的编码操作流程之一，涉及多个系统。 但是，收集遥测数据进行分析是另一个需要注意的操作过程，基于遥测数据采取的可能行动也需要注意，这些行动可以进行（自动）调整以优化数据路径或应用性能。 这些操作流程有自己的配置，并在部署过程完成后发挥作用。
职责：运营工作流程自动化
通过持续操作堆栈的视角来查看持续部署可以为自动化生产流程提供一种战略方法。 通过分离层次和职责，可以更轻松地完成自动化 IT 职责这一艰巨的任务，从而实现许多组织所期望的、业务日益要求的自助服务方式。 它还通过代码操作实现了持续操作，这是 IT 内部使用自动化的必要发展。
现在，这可能不是查看与部署管道相关的自动化工作的“唯一正确方法”。 但这是一种方式，它确实为市场提供了清楚地表达他们做什么或不做什么的能力。
这意味着当我说基础设施即代码或配置即代码时，您可以确定我的意思，尤其是对于 F5 产品而言。