自2012年以来DevOps发生了怎样的变化?

wishli 2020-04-02

自2012年以来DevOps发生了怎样的变化?

  1. 基础架构进入到代码。运行该软件的云端系统由代码创建。
  2. 运维角色将进入到团队。
  3. 监控进入到平台。我们通过代码创建的用于服务软件的虚拟机将包括内置监控。

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服务器,可能还面向数据库服务器。眼下,专职工程师将只好习惯于在异构操作环境下工作,在这种环境下传统运维人员将继续发挥作用。

相关推荐