自2012年以来DevOps发生了怎样的变化？
- 基础架构进入到代码。运行该软件的云端系统由代码创建。
- 运维角色将进入到团队。
- 监控进入到平台。我们通过代码创建的用于服务软件的虚拟机将包括内置监控。
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服务器，可能还面向数据库服务器。眼下，专职工程师将只好习惯于在异构操作环境下工作，在这种环境下传统运维人员将继续发挥作用。