2020年DevOps的趋势会发生哪些变化？

　　Mike Loukides以图书形式发表O‘Reilly Media出版的《DevOps是什么?》文章时，有一个众所周知的副标题：基础架构即代码，这篇文章是只有20页，提出几点：
　　1.基础架构进入代码，运行软件的云系统是由代码创建的。
　　2.运维角色将进入到一个团队。
　　3.监控进入到一个平台，我们可以通过代码创建的用于企业服务软件的虚拟机将包括内置监控。

　　八年后，也许是时候问这些预言是否真实，我们学到了什么和接下来会发生什么。
基础架构即代码
　　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，这在云端意味着大量费用。他们还可以使网络需要增加大约一倍。我多次看到一家企业公司花数万乃至数十万美元加上数年的工程师人力来实施一套监控管理系统。但由于信息系统发展需求分析实际上影响了社会生产，到头来只好关闭监控技术系统。

更多产品了解

欢迎扫码加入云巴巴企业数字化交流服务群

产品交流、问题咨询、专业测评

都在这里！