【51CTO.com快译】Mike Loukides以图书形式发表O'Reilly Media出版的《DevOps是什么?》长文时，他取了一个后来众所周知的副标题：基础架构即代码。那篇文章只有20页，提出了几个要点：
基础架构进入到代码。运行该软件的云端系统由代码创建。
运维角色将进入到团队。
监控进入到平台。我们通过代码创建的用于服务软件的虚拟机将包括内置监控。
8年后，也许是时候问一下这些预测是否属实、我们学到了什么以及接下来会发生什么。
基础架构即代码
Loukides的文章举了几个有名的例子，比如Netflix的ChaosMonkey，它们是完成基础架构工作的成熟的计算机程序。当时最流行的想法是，运维人员将成为正宗的计算机程序员，用Python或Ruby编写程序来设置将运行应用程序代码的一系列虚拟机。客户需要管理资源、规模扩展和可用性等。
事实证明，这很难编写，调试起来就更难了，而且几乎不可能继续运行。
业界确实从几个方面作出了有力的回应。
首先在2013年的Python大会上，Solomon Hykes和Sebastien Pahl推出了Docker，这是面向Linux系统的轻量级虚拟化工具。一年后，谷歌开源了Kubernetes。Kubernetes和Docker引入了传统“基础架构即代码”之间的一大区别：它们与其说是受代码驱动，还不如说是受配置和命令驱动。
这方面的流行术语是声明性DevOps。简而言之，你无需编写常规的经典代码告诉计算机“如何”创建服务器，而是创建一个配置文件来告诉计算机那是“什么”并运行命令。用Kubernetes的术语来说，这是一个清单文件，而不是来自命令行的一系列Kubectl命令，或更糟糕的是运行kubectl命令的Python程序，在无限的“while”循环中运行，试图监控系统并采取纠正措施。顾问兼培训师Bob Reselman表示，清单文件将创建可重用的资产，该资产更易于审计和控制。
虽然“基础架构即代码”没有接管软件的所有方面，但对于促使微服务崛起起到了至关重要的作用，团队常常可以自行运行微服务。
运维进入到团队
至少对于微服务而言，可以说运维现在是软件开发团队的一部分。也就是说，对于新服务而言，我看到团队支持他们创建的服务。这倒不是说我接触的每家组织都如此，而是这些变化并非无处不在。
另一个创新是全新的工作类别，即软件可靠性工程师或SRE。SRE负责系统可用性、延迟、性能、紧急响应和容量等。他们监控大量网站和服务，并采取纠正措施。这是某种“DevOps”工作，原因是它把软件开发的严谨性带到了运维。我个人感到有点难过，因为我们发明了一种全新的工作类别，而不是开发团队和运维团队协同工作。它似乎确实适用于存在可扩展性问题的大公司。人数较少的小组只是把运维这块扔给了团队。
监控进入到平台
电话与路由器、Web服务器、微服务、数据库直至物联网设备之间的许多环节可能会出岔子。Kubernetes方面尚未出现的一件事就是支持我们一直希望的监控。云托管公司确实提供了出色的仪表板，便于查看服务器的运行状况，但跟踪消息(这是可观察性的一部分)是大多数小组要自行计划的事情。
这可能属于下一步。
下一步是什么
虽然Windows容器确实管用，至少从理论上来说适用于一款特定的操作系统，但我还没有看到哪家公司实际使用它。Kubernetes仍然主要是面向Linux系统的解决方案，尤其是面向Web服务器，可能还面向数据库服务器。眼下，专职工程师将只好习惯于在异构操作环境下工作，在这种环境下传统运维人员将继续发挥作用。
然后是监控。有一些软件包和开源系统(比如Istio)可以检测云系统，并自动创建监控系统和审计跟踪。我看到的问题是，它们需要大量的CPU/Member，这在云端意味着大量费用。它们还可能使网络需求大致翻番。我多次看到一家公司花数万乃至数十万美元加上数年的工程师人力来实施一套监控系统，但由于系统需求实际上影响了生产，到头来只好关闭监控系统。
原文标题：How DevOps has evolved since 2012，作者：Matthew Heusser
