任何技术趋势都会催生一些术语，而这些术语往往很快就被过度炒作，几乎失去实际意义。云最初就是如此，在某些方面至今依然如此。DevOps历经数年才逐渐厘清（甚至可能至今仍未厘清）。机器学习和AI目前正赤脚踏浪，乘着炒作浪潮前行，短期内丝毫没有跌落浪头的迹象。
紧随其后的热词是“即代码”。
突然之间，一切都成了“即代码”。市场对“即代码”趋之若鹜，尽管其中大多数人连C、C++和C#都分不清。“即代码”俨然成了生命、宇宙以及一切问题的答案。似乎没有什么问题是“即代码”解决不了的，而且人人都在这样做。
当术语在缺乏明确边界或定义的情况下被随意使用时，我们有必要停下来，确保清楚说明*我们*所采用的定义。如果有一个标准委员会制定可供参考的RFC式定义，当然再好不过，但现实并非如此。目前最接近这一角色的是NIST，而他们在平息云计算概念之争方面的成效，我们也有目共睹。
“即代码”并不只是基础设施即代码（IAC）。Pythian的Aiman Najjar撰写了一篇精彩的概述，介绍当前基础设施即代码领域的整体情况。虽然我不认同容器应单独作为一层（从网络和应用服务的角度来看，它只是基础设施），也不认同Jenkins不应归入其中，但总体而言，他的博客非常有助于理解各个“即代码”层之间的关系，并为不同任务选择合适的工具。此外，大多数关于基础设施即代码的讨论都侧重于持续交付，即通过流水线构建、测试和集成应用，并将其发布到生产环境。这与持续部署并非同一流程。持续部署侧重于将已发布的应用及其所需的网络和应用服务部署到生产环境中。
注意在理想的应用环境中，交付流水线与部署流水线融为一体。但现实中，生产环境与开发环境通常仍彼此独立，各自有不同的要求和限制。因此，在对流水线实施自动化时，需要认识到这种差异。
目前已形成三个不同的层次，用于应对IT和部署管道固有的复杂特性。其中首要的是环境本身的复杂性。我们在网络图中绘制的那条从客户端直达应用的直线并不能反映实际情况。底层实际发生的事情远比我们有时间（和耐心）绘制出来的多。
管道本身具有多样性，既包括专用硬件，也包括部署在商用现成（COTS）平台上的虚拟化软件和容器化软件，这也促使我们将“即代码”方法划分为不同层。较新的硬件确实可以通过即代码方法进行管理，但传统的共享硬件几乎无法纳入这一流程。因此，将各层分开，使其更贴近部署流程本身，有助于在管道中同时纳入传统和现代的硬件解决方案以及软件服务。
目标是构建一个持续运行的IT堆栈，以支持多云环境中按应用制定的部署计划和架构。由于部署只是应用活跃生命周期的起点，因此还需要增加第4层，专注于部署后的运维。这是在3个核心层之外新增的一层；这3个核心层分别涵盖基础设施预置和接入、服务配置和管理，以及部署流水线。
此工具列表并非详尽无遗。除此之外，还有许多其他工具和工具集。例如，多项调查和研究表明，大多数网络运维人员更倾向于使用定制的Python脚本来自动化网络和应用服务。我们还了解到，Cisco ACI、VMware NSX、OpenStack和Red Hat OpenShift等网络自动化系统和技术栈，也是实现持续运营技术栈中多项功能的常用方式。图中空间有限，无法列出所有工具，因此仅根据这些工具在DevOps中的普及程度选取了部分示例。这是因为，交付和部署流水线的标准化将是取得成功的关键要素，而利用组织现有的技能和专业知识，并采用最常用于实施“即代码”交付流水线的工具，无疑是合理的选择。需要说明的是，我没有列出任何用于“运营即代码”的工具，因为其中许多工具都是定制的（自定义脚本），或专用于特定厂商的技术，至少目前如此。
注意代码化运维相当于IT领域的业务流程管理（BPM）。BPM可实现业务流程自动化。有些BPM仅专注于非常具体的工作流，有些则可能涵盖从购买、付款到交付的整个客户交互过程。如今，代码化运维在IT领域仍处于起步阶段，但企业若要像利用BPM一样，通过优化运维流程获得收益，就需要将其发展为运维流程管理。
持续运营技术栈
基础设施即代码（IaC）
无论是在云端还是数据中心，都仍需配置网络。即使是更高层的服务（即运行在第4至第7层的应用服务），也需要掌握一定的网络拓扑信息才能运行。如果要部署全新的流水线，其中一些服务可能需要激活（即获得许可）。要实现自助式部署，基础设施即代码必不可少，因为如果基础设施（软件和服务）尚未就绪，就没有可供配置或部署应用的环境。
职责：基础设施接入、许可和配置
配置即代码（CaC）
这是一个与配置不同的问题。配置具体是指需要针对相关服务设置相应的策略和行为。每次应用进行重大更新时，可能都需要重新配置；每次小幅更新时也可能如此。对于安全相关服务，可能还需要紧急进行配置，以便对特定服务进行修补、更新或升级。配置即代码对于支持按应用制定部署计划和构建部署流水线，以及强制隔离应用数据路径至关重要，而这种隔离有助于确保整个生产流水线的稳定性。
职责：服务配置、升级和修补
流水线即代码（PaC）
此外，还有一个从头到尾定义整个应用及其服务的总体流程。这就是完整的流水线，它被编写为可执行流程，可自动推动部署。流水线即代码是连接IaC与CaC的纽带，将二者整合起来，形成我们所说的部署流水线。流水线能够消除流程中各个必要步骤之间的等待时间，因此可显著提升速度和效率。
职责：部署流程自动化
运营即代码（OaC）
这一层是持续运行的运维层，负责监控和告警、自动扩缩容以及服务发现。在这一层，我们关注的是将运维流程代码化，使系统能够自行执行这些流程。自动扩缩容是最常被代码化的运维流程之一，涉及多个系统。此外，收集遥测数据以供分析也是一个需要关注的运维流程；同样需要关注的还有根据这些遥测数据可能采取的操作，这些操作可通过（自动）调整来优化数据路径或应用性能。这些运维流程有各自的配置，并在部署流程完成后发挥作用。
职责：运维工作流自动化
从持续运营堆栈的视角审视持续部署，可以为生产流水线自动化提供一种战略性方法。通过划分不同层级和职责，可以更轻松地应对IT职责自动化这一艰巨任务，从而实现许多组织所期望、业务部门也日益需要的自助服务模式。此外，还可以通过运营即代码实现持续运营，这是IT自动化应用的必然演进方向。
当然，这可能并不是看待部署流水线相关自动化工作的“唯一正确方式”。但它确实提供了一种视角，让市场参与者能够清楚说明自己能做什么、不能做什么。
这意味着，当我提到“基础设施即代码”或“配置即代码”时，尤其是在涉及F5产品的情况下，您可以确切了解我的含义。
关于作者
Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师，在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构，还是探索可扩展系统的极限，她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前，她曾担任技术编辑，并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位，著述颇丰，出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏，并且对奶酪有着毫不掩饰的鲜明见解。
Lori Mac Vittie 的更多博客文章相关博客文章
Thingbot正转变为攻击平台
Lori MacVittie重点介绍了F5 Labs对2018年1月至6月全球物联网设备攻击的研究，并指出了其中令人警醒的影响。物联网设备不仅持续遭到利用，还被转变为攻击平台，这意味着攻击者可以更充分地利用这个必然增长的市场。
借助F5全新Quick Start，在AWS上快速开展业务
在AWS re:Invent开幕前，我们很高兴与大家分享F5与AWS之间全新的Quick Start集成。F5的Tom Atkins将介绍该服务如何启动、配置和运行在AWS上部署工作负载所需的计算、网络、存储及其他AWS服务。