作为一种基于软件开发实践的基础设施自动化方法 ， 基础设施即代码（Infrastructure as Code ， 可缩写为IaC）如今较为常见 ， 但面临不断演变的技术与市场需求 ， 基础设施即代码也需与时俱进 ， 尤其在当下的云原生时代中 ， 更面临着一场前所未有的挑战与变革 。
作者 | Piotr Zaniewski 责编 | 郑丽媛
出品 | 新程序员
自软件行业形成至今 ， 已有几十年光景 ， 几乎每隔一段时间就会出现一些重大事件 ， 我们可以将其称为范式转变 。 在这种不断的转变过程中 ， 软件开发对基础设施管理提出了日益严苛的要求：产品要能跟上市场需求 ， 基础设施的响应速度必须提高；持续交付和DevOps的盛行 ， 要求产品团队需对部署和运维有更高的自主性；技术的不断迭代使基础设施的配置愈发频繁且烦琐……随着以上问题不断加剧 ， 便逐渐衍生出了基础设施即代码这一概念 ， 即在确保基础设施安全可靠的同时 ， 也要具备灵活管理的特点 。
基于Thoughtworks公司云实践领导人Kief Morris在《基础设施即代码》一书中对基础设施即代码的定义：“基础设施即代码是一种使用新的技术来构建和管理动态基础设施的方式 。 它把基础设施、工具和服务以及对基础设施的管理本身作为一个软件系统 ， 采纳软件工程实践以结构化、安全的方式来管理系统变更” ， 我们可将其理解为一种基于软件开发实践的基础设施自动化方法 ， 主要强调系统及其配置的日常置备和变更具有一致性和可重复性 ， 允许开发人员使用任意语言描述的配置管理虚拟化基础设施和辅助服务 ， 同时这些配置文件通常托管在源代码库中 。
点击图片查看整本内容
基础设施提供渠道的演变
基础设施即代码发展至今 ， 从概念到落地 ， 从小众到普及 ， 每一次推进都与软件行业的变化分不开 。
虚拟化
在虚拟化早期阶段 ， 开发人员需要根据需求文档 ， 经历漫长的瀑布式开发周期才能生产出软件 。 期间 ， 运维团队需要搭建服务器、提供基础设施组件、安装所有软件并完成配置等工作 。 然而 ， 在这一时期 ， 开发和运维这两个团队的工作通常没有联系 ， 交流主要通过任务单和往返邮件 ， 非常不便利（见图1） 。
文章图片
图1 虚拟化早期阶段 ， 开发和运维团队的工作方式
敏捷与开发运维的开端
后来 ， 我们经历了敏捷运动 ， 随之而来的就是开发运维文化 。 如今 ， 开发人员在给运维团队发送应用程序时 ， 还会送上一份配置手册 ， 甚至更先进的团队还会合作开发自动化工具（见图2） 。 在基础设施自动化工具的早期 ， Chef和Puppet等工具非常流行 。 这种方式无疑是巨大的进步 ， 但这往往会建立非常孤立的环境 ， 责任也很分散 。
文章图片
图2 敏捷与开发运维文化时期 ， 开发和运维团队的工作方式
公共云与容器编排
【基础设施即代码：一场变革即将到来】随着公共云的普及和自动化越来越强大 ， 这一切才逐渐步入正轨 。 大多数运维团队都会选择Terraform ， 与几年前的情况相比 ， 这是一个巨大的进步 ， 基础设施的数量也呈指数增长 。
整体而言 ， 这种方式在很长一段时间里都近乎完美 ， 唯在两个方面还有所缺失：
- 开发和运维团队的经验稍显不足 。 精心创建的基础设施一旦出现问题 ， 就需要耗费大量的人工和维护成本 。
特别声明：本站内容均来自网友提供或互联网，仅供参考，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系，我们将在24小时内删除。