什么是敏捷基础设施

我知道，这篇文章看起来可能比较枯燥，但是，内容非常重要，并且常常被忽略。这里面的内容可能是你看文章不能体会出来的，需要自己动手去体验一下。

如今的微服务架构，可以用势不可挡来形容，如果你告诉别人你的架构不是微服务架构，可能有被嘲笑的风险。在微服务架构爆发式增长的今天，大多数人看到了微服务架构带来的优势，但是真正实施的时候，心里的苦只有自己知道。而基础设施往往被忽略，但是它的重要程度一点都不比微服务架构低。前面我们说了，Cloud Native的基石是微服务架构、敏捷基础设施及公共基础服务。

那敏捷基础设施到底是干嘛的呢？能给我们提供什么价值呢？

那我们先说说基础设施运维的阶段：

第一阶段—人肉阶段。全部人肉，物理机安装软件，有专门的运维团队负责部署。A物理机是给订单用的，B物理机是给登录用的，绝对不能互相干扰。常常因为敲错命令，导致故障。标准化通过规范约束，效果甚微，效率十分低下。

第二阶段—脚本阶段。内部制定规范，要求必须严格执行。通过部分脚本实现部署、启停。部署还是要通过运维人员操作、配置，半自动化方式，仍然需要敲命令。使用虚拟机隔离，虚拟机数量很多，运维人员在窗口中来回切换，可能看错窗口，执行了错误的命令。申请机器需要提前，每年都要做服务器需求计划。中间加机器非常麻烦。

第三阶段—工具阶段。少数运维人员，通过私有云管理虚拟机。通过CI工具实现持续部署。运维人员通过虚拟机镜像来封装常用依赖环境。但是开发环境和测试环境、生产环境差距很大，可能会出现开发人员本地测试通过，测试人员说有问题，测试人员在测试环境测试通过，一上线就有问题。

第四阶段—敏捷基础设施。无需运维人员，全部自动化，通过容器封装环境，开发人员可以直接将所有软件和依赖直接封装到容器中，打包成镜像，生产环境直接部署镜像。可以实现所有环境都一样。容器调度平台管理容器，资源利用率更高，通过配置文件描述环境，例如我要部署8台Nginx，端口是什么，镜像用哪个，日志放在什么地方，配置文件用哪个，部署在什么地方等等，都可以直接描述出来。注意，这个描述文件以前是运维干的，现在开发就能搞定。

划重点！！！

敏捷基础设施实际上并不是一个全新的术语，是指使用脚本或文件配置计算基础设施环境，而不是手动配置环境的方法。

敏捷基础设施也可称为基础设施即代码（Infrastructure as Code）或者可编程基础设施（Programmable Infrastructure），基础设施即代码可以将基础设施配置完全当作软件编程来进行。实际上，这已经开始让编写应用和创建其运行环境之间的界限变得逐渐模糊起来。应用可能包含用于创建和协调其自身虚拟机或容器的脚本。这是云计算的基础，并且对DevOps至关重要。

基础设施即代码有何优势？

基础设施即代码可通过编程的方式管理虚拟机或容器，免去了手动配置、更新各个硬件的需要。这就使得基础设施极具弹性，能够快速、高效、准确的进行重复性扩展。开发人员使用同一套配置或代码，就可部署并管理成千上万台物理机。基础设施即代码能够得到更快的速度、更低的成本和更可靠的环境。用代码定义服务器配置意味着在众多服务器之间有绝对的一致性，容易形成标准化。手动调整配置往往会有一些微妙的差异，并且难以追溯，经常会导致诡异的问题并难以调试。

基础设施即代码与DevOps有何关系？

为了解决开发和运维之间的矛盾，催生了DevOps，DevOps使运维人员的职责发生了巨大的转变，快速构建环境必须通过自动化实现，基础设施即代码就是快速构建环境的基础。运行业务应用和配置基础设施在统一的CI/CD平台执行。

基础设施即代码和传统的配置管理有何区别？

基础设施即代码和传统的配置管理有一个非常大的区别，那就是整个过程由开发人员负责，无需运维人员的参与，传统的配置管理是由运维人员去操作，交接的流程越少，效率越高。这种做法意味着业务服务与基础设施的关系就更加紧密了。开发人员不仅可以写业务服务的代码，还可以定义运行业务服务的基础设施。

基础设施即代码或可编程的基础设施要想普及，还面临一些挑战。特别是要调整研发流程，改变角色的职责。之前听到过很多失败的案例都是由于利益之争，国内某旅游互联网公司进行的比较成功，他们的策略是让有代码能力的运维去开发云平台和工具，让没有代码能力的去做基础运维，也就是传说中的搬机器，所有的开发流程都是由全栈工程师主导，结果去得了比较好的效果。