DevOps未来发展的 9 个趋势

Posted 2021-04-16 DevOps技术栈

DevOps究竟是什么

在2008年多伦多举办的敏捷大会（Velocity Conf 2008 ）上，Patrick DeBois 和AndrewClay Shafer 先生首次提议讨论“敏捷基础架构”这个话题。在第二年的敏捷大会上有一个具有里程碑的意义技术分享，来自Flickr公司《每天部署10次》的分享，它激发了随后Patrick DeBios在同年十月，在比利时的根特市举办的首届DevOpsDays活动，这个活动是两天的日程，为了大家方便在twitter上的传播，人们把DevOpsDays这个词简写为 “#DevOps” 。 此后，“DevOps”一词问世了，这个词所包含的理念和实践一时在越来越广大的人群中产生了共鸣，随后成为全球IT界在各种大会和论坛里热议和讨论的焦点话题，很多大型IT论坛也都开设出了DevOps专题讨论。这就是DevOps这个词的由来。

DevOpsDays活动随后在Patrick DeBios等相关核心发起人的推动下，在全球范围内蓬勃发展了起来。

DevOps（Development和Operations的组合词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。——维基百科

DevOps是一种文化转变，或者说是一个鼓励更好地交流和协作（即团队合作）以便于更快地构建可靠性更高、质量更好的软件的运动。——Mike Kavis

Mike Kavis是美国Cloud Technology Partners公司的副总裁兼首席架构师，他也更加详细地描述介绍说：DevOps是软件开发生命周期（SDLC）从瀑布式到敏捷再到精益的发展。DevOps超越了敏捷，它的关注点是从SDLC中移除浪费。通常情况下，发现浪费或者瓶颈的形式包括：不一致的环境，人工的构建和部署流程，差的质量和测试实践，IT部门之间缺少沟通和理解，频繁的中断和失败的协定以及那些需要珍贵的资源、花费重要的时间和金钱才能保持系统运行的全套问题。

他还看到另一个重复浪费是：一个DevOps团队的第一步通常是决定他们是否应该使用Chef或者Puppet（或者是Salt、Ansible等其他任何热门的东西）。他们甚至还没有定义自己打算解决的问题，即使他们手头的工具可以解决它们。这些团队通常会紧张地构建数千行脚本，但是这就产生了一个问题：“我们的职责是编写Chef脚本还是通过质量更好、更稳定的产品更快地进入市场？”。在大多数情况下，这些团队会将自己逼入绝境，大量的专有脚本实际上是增加了系统的浪费，而隐藏在DevOps运动之后的驱动力是从系统中移除浪费，这些团队并没有做到这一点。Mike Kavis原文

而目前对 DevOps 有太多的说法和定义，不过它们都有一个共同的思想：“解决开发者与运维者之间曾经不可逾越的鸿沟，增强开发者与运维者之间的沟通和交流”。而我个人认为，DevOps 可以用一个公式表达：

文化观念的改变 + 自动化工具 = 不断适应快速变化的市场

其核心价值在于以下两点：

1. 更快速地交付, 响应市场的变化。

2. 更多地关注业务的改进与提升。

刚刚过去的2018年对于 DevOps 来说是里程碑式的一年，各个行业都开始结合自身的业务特点，在落地 DevOps 这件事情上有了一些规划、探索。虽然大家对于 DevOps 究竟是什么依然未能完全达成一致，但每个企业确实又能找到符合自身能力需求的部分。DevOps 带有很强的实践色彩，解决实际问题才是王道，既然那么多的 DevOps 工具、流程和方法无法一次性落地，那么先解决一部分问题总是好的，这也很符合 DevOps 的实践精神。

2018年，容器技术和 DevOps 这对好兄弟会联手上演一场大戏，这是业内大家都认同的趋势。但具体落地的路径究竟如何，目前都还是经验积累阶段。闻道有先后、术业有专攻，在众多的工具、流程和方法中找到一个解决所有问题的“银弹”固然是不大可能，但总结一些经验和教训，对未来做一些预测总归是有备无患。

趋势1：微服务目前仍然是DevOps技术应用和发展的主要领域

微服务将单块应用系统切割为多个简单独立的应用。从技术上说，这是通过工具把应用程序的内部复杂度转化为外部复杂度，需要一系列工具支撑微服务本身以及服务之间的通信。从组织上说，微服务团队要满足“快速发布，独立部署”的能力，则必须具备DevOps的工作方式。

何拆解微服务一直是微服务技术应用的最大难点之一，领域驱动设计是比较理想的微服务拆解方法论。社会化代码分析帮助团队通过更精确的数据找到更加合适的拆分点。CodeScene是一个在线服务，它能帮助识别出热点和复杂且难以维护的子系统，通过分析分布式子系统在时间上的耦合发现子系统之间的耦合。此外，它还能帮你认识组织中的康威定律，这会大大降低微服务解耦的难度。

此外，微服务系统本质上是一个分布式系统，分布式系统之间的通信一直是很重要的问题。本期介绍的Kafka Streams和OpenTracing就是这类技术的条目。Kafka作为一个成熟的分布式消息系统已经被广泛采用，而Kafka Streams则将最佳实践以“库”的方式呈现给开发人员，使得操作Kafka更加自然和简单。而OpenTracing则弥补了跨越多个微服务之间请求追踪的空白。

另一方面，无服务器风格的架构（Serverless architecture）把DevOps技术在微服务领域的应用推向极致。当应用程序执行环境的管理被新的编程模型和平台取代后，团队的交付生产率得到了进一步的提升。一方面它免去了很多环境管理的工作，包括设备、网络、主机以及对应的软件和配置工作，使得软件运行时环境更加稳定。另一方面，它大大降低了团队采用DevOps的技术门槛。

然而，端到端交付以及微服务中的函数管理问题日渐突出。尽管AWS API gateway和AWS Lambda几乎成了Serverless架构的代名词，但这二者结合的开发者体验并不佳。于是出现了Serverless framework和CLAUDIA这样的管理工具。

AWS Lambda带来的优势也深深影响了企业级应用领域，Apache OpenWhisk就是企业级无服务器领域的选择之一，它使得企业级应用也可以采用无服务器风格的架构构建应用程序。

在微服务端到端交付流程上，Netflix开源了自家的Spinnaker，Netflix作为微服务实践的先锋，不断推出新的开源工具来弥补社区中微服务技术和最佳实践的缺失。而Spring Cloud则为开发者提供了一系列工具，以便他们在所熟悉的Spring技术栈下使用这些服务协调技术(coordination techniques)，如服务发现、负载均衡、熔断和健康检查。

而在微服务的安全上，最常见的需求之一 是通过身份验证和授权功能来保护服务或API。这部分功能往往是最重要且不断重复构造的。而Keycloak就是一个开源的身份和访问管理解决方案，用于确保应用程序或微服务的安全。且几乎不需要编写代码，开箱即用。它支持单点登录，社交网络登录和标准协议登录(如OpenID Connect，OAuth2和SAML等)。

趋势2：以Docker为核心的数据中心方案逐渐走向成熟

在过去的两年，Docker社区有了突飞猛进的发展，似乎每期技术雷达都会出现Docker相关的条目。而Docker往往和DevOps联系起来，被认为是推动DevOps发展的杀手级工具，以至于有些人会以团队是否采用Docker作为团队是否具备DevOps能力的标志。

而这一社区的创新数量则日渐平缓。一方面，开源社区激烈的竞争淘汰了一部分技术。另一方面，以Docker为中心的完整数据中心解决方案在不断的整合开源社区的零散工具并形成最佳实践。为端到端的开发和运维提供更完整的交付体验，各大厂商也相继开始推广自己的企业级整体收费解决方案，这表明Docker的使用已经走向成熟。

在本期的技术雷达里的条目中出现了Mesosphere DC/OS，这是构建统一技术栈数据中心的一个征兆。在这方面Docker EE和Rancher都是非常有力的竞争者。根据我的判断，在未来的Docker社区里，统一容器化数据中心的竞争者将会进一步减少。而之前的私有云方案则慢慢会被“以Docker为核心数据中心级全栈交付”取代。

趋势3：不完整的DevOps实践阻碍着DevOps的发展

很遗憾看到单一持续集成实例和不完整的持续集成（CI Theatre）这样的条目出现在技术雷达里。可以感到企业应用DevOps技术的紧迫性。这同时也暴露了DevOps领域里“缺乏门槛较低且成熟的技术实践”的问题。

大部分企业在DevOps转型中仅仅关注到了工具的升级。却忽视了价值流、生产流程中各个活动中的最佳实践以及DevOps团队文化的构建，这会使团队陷入“已经完成DevOps转型的假象“，而停止了团队的自我改进。

DevOps的实践包含组织改进和技术升级两个部分，技术往往是最容易的部分。而缺乏组织改进的技术提升往往很难给组织带来质的飞跃。具备DevOps文化的团队则会不断反思和学习，通过共担责任和相互合作不断完善组织的DevOps实践。

趋势4：领域特定的DevOps实践开始出现

evOps的最早实践来自于互联网企业的Web应用，相应的思想被引入企业级应用并促进了一系列工具的发展。虽然并不是每一种应用软件交付形式都适合DevOps，但随着DevOps的工具不断成熟。其它领域的DevOps实践也开始尝试借鉴Web应用领域的自动化工具，并逐渐形成领域级的DevOps实践。

在人工智能领域，TensorFlow就是这样一个例子，它可以有多种DevOps友好的安装和部署方式 ，例如采用Docker进行部署。

在区块链领域，超级账本(HYPERLEDGER) 就是这样一个例子，它提供了一套工具和服务，结合DevOps相关技术和实践形成了一个完整的解决方案。

随着DevOps相关概念和技术不断向各个产业领域的深入发展，可以看到DevOps技术和实践带来的巨大影响力。然而，每个技术领域都有自己所关注的特性，并不是以往的DevOps实践可以全覆盖到的，这恰恰成为了DevOps技术和实践发展的契机。我很期待领域特定的DevOps技术实践给DevOps带来的发展。

趋势5：采用DevOps进行技术债务重组和技术资产管理

技术债务类似于金融债务，它也会产生利息，这里的利息其实就是指由于鲁莽的设计决策导致需要在未来的开发中付出更多的努力。

投资银行业往往采用多种金融工具组合的方式来处理企业的不良债务。而清理技术债务的实践和工具却乏善可陈。

技术债务不光阻碍了企业通过新技术带来便利，还使企业偿还技术债务所承担的成本越来越高，例如技术人才的流失，技术利息等综合性风险。

虽然极少会出现企业因技术债务而走向衰败的案例，但新晋企业凭借新技术和商业模式颠覆传统行业并夺取市场份额的报道却不断发生。 这从另一方面说明技术债务综合提升了采用新技术的机会成本，使企业不断失去创新和领先的巨大潜力。

DevOps技术栈的多元化为分散遗留系统技术债务风险提供了一套灵活而又低风险的工具和方法论。不断帮助企业从遗留系统的负担中解脱出来。

而微服务则是首先通过领域拆分技术债，并用相应工具重组技术债。分离优质技术资产和不良资产，通过分散风险来降低抛弃成本。 而将API当做产品(APIs as a product)可以从一个全新的演进视角去看待技术债，通过可用性测试和用户体验研究帮企业剥离出技术债务中的优质资产和不良资产。

另一方面，本期技术雷达中出现了封装遗留系统这样的实践，它往往配合着Vagrant，Packer和Docker这样的工具一起使用。一方面它将技术债务的风险进行了隔离，另一方面它防止了遗留系统上产生的技术债利息的增长。

趋势6：安全成为推动DevOps全面发展的重要力量

安全是DevOps永远绕不开的话题，也往往是新技术在传统行业（例如金融和电信）应用中的最大阻碍。一方面，组织结构的转型迫使企业要打破原先的部门墙，这意味着很多原先的控制流程不再适用。另一方面，由于大量的DevOps技术来源于开源社区，缺乏强大技术实力的企业在应用相关技术时不免会有所担忧。

从代码中解耦秘密信息的管理则让我们避开了一些开发过程中可能会产生的安全隐患。采用git-crypt这样的工具可以帮我们保证在开发的过程中源代码内部的信息安全。而采用HashiCorp Vault则提供了脱离应用程序代码的秘密信息存储机制，使得应用在运行过程中的秘密得到了有效保护。

Linux Security Module则一直在技术雷达的“采用”区域，通过SELinux和AppArmor这样的LSM兼容帮助团队评估谁可以访问共享主机上的哪些资源(包括其中 的服务)。这种保守的访问管理方法将帮助团队在其SDLC流程中建立更好的安全性。以往这是Ops团队需要考虑的问题，而对DevOps的团队来说，这是每一个人的事情。

“合规性即代码”（Compliance as Code）是继“基础设施即代码”，“流水线即代码”之后的又一种自动化尝试。InSpec作为合规性即代码的提出者和实现者，通过自动化手段确保服务器在部署后的运维生命周期中依然保持安全与合规。它所带来的意义在于将规范制度代码化，得到了确定性的结果和解释。

在不远的将来，不难想象人们所面对的法律和法规规定不再是一堆会导致歧义的语言文字条目，而是一组由自动化测试构成的测试环境。

安全性和易用性往往被认为是鱼与熊掌不可兼得的两个方面。在DevOps之前，团队吞吐量和系统稳定性指标曾经也面临这样的境遇，然而DevOps使得二者可以兼得。同样我也有信心看到在未来DevOps的领域里，更多易用且安全的工具将会不断出现。在降低DevOps所带来的安全风险的同时，也提升团队开发过程的顺畅性和用户便利性。

趋势7：Windows Server和.NET平台下的DevOps技术潜力巨大

长期以来，Windows和.NET平台下的DevOps一直都是一个被低估的领域。一方面，社区缺乏对 Windows Server平台的兴趣。另一方面，Windows Server却有接近90%的市场占用率，在Web服务器领域则有33.5%的市场占有率。

有充足理由证明这是一个潜力巨大的市场。 我们看到了CAKE和FAKE这样的条目，作为.NET平台下替代MSBuild的构建解决方案， 它增强了.NET平台自动化方面的能力。而HANGFIRE则提供了更易用和灵活的自动化进程调度框架。我很期待未来有更多Windows Server和.NET平台领域的创新。不久前，Docker已经可以在Windows下运行。可以预见到，Windows Server和.NET平台将会是下一阶段DevOps技术实践中值得深入发掘的领域。

趋势8：非功能性自动化测试工具的逐渐完备

自动化测试水平往往是衡量DevOps技术能力高低的重要指标，尤其是针对生产环境应用程序的非功能性自动化测试工具。一直以来，技术雷达都在尝试从不同的角度宣扬自动化测试的重要性，从软件的开发阶段延展到了整个应用生命周期甚至整体IT资产的管理上。

这期的技术雷达仍然关注了非功能性自动化测试，TestInfra是ServerSpec的Python实现，它使得用Pytest测试基础设施成为可能。而MOLECULE旨在帮助开发和测试Ansible的Role 。通过在虚拟机或容器上为正在运行的Ansible Role测试构建脚手架，无需再手工创建这些测试环境。正如技术雷达所说的：“虽然这是一个相当年轻的项目，但我们看到了其蕴含的巨大潜力。”

趋势9：Python成为DevOps工作中所不可或缺的语言

早在DevOps刚刚开始盛行的时候，Python就是一个被寄予厚望的语言，因为大部分DevOps工具和实践都需要用到Python。虽然也有人尝试用Ruby或者NodeJS构建DevOps工具，然而都没有Python所构建的工具流行。与此同时，仍然不断有人把其它语言下编写的工具转化为Python的版本，TestInfra就是这样一个例子。

随着Python在大数据、人工智能、区块链、微服务以及Docker中的发展，可以预见Python在日后的领域仍然会发挥重要的作用。

- END -

推荐阅读：

 【含视频】

【含视频】

 

《四个过桥人》

有一处地势险恶的峡谷，涧底奔腾着湍急的水流，而所谓的桥则是几根横亘在悬崖峭壁间光秃秃的铁索。

一行四人来到桥头，一个盲人、一个聋子，以及两个耳聪目明的正常人。四个人一个接一个抓住铁索，凌空行进。

结果呢？盲人、聋子过了桥，一个耳聪目明的人也过了桥，另一个则跌下深渊丧了命。

难道耳聪目明的人还不如盲人、聋人吗？

是的！他的弱点恰恰源于耳聪目明。

盲人说：“我眼睛看不见，不知山高桥险，心平气和地攀索。”

聋人说：“我耳朵听不见，不闻脚下咆哮怒吼，恐惧相对减少很多。”

那个过了桥的耳聪目明的人则说：“我过我的桥，险峰与我何干？激流与我何干？只管注意落脚稳固就够了。”

【哲理与感悟】

积极地面对周围的环境，不要被虚张声势所威吓，要知道，那多半都是纸老虎，惟有一颗坦然面对而又积极进取的心才可排除虚张声势对你的威吓。

点亮，为你9012锦上添花