当前位置: 首页 > 科技观察

9DevOps发展趋势不完善的实践阻碍了DevOps的发展_0

时间:2023-03-14 20:46:25 科技观察

DevOps包含了太多的技术和实践,很难通过统一的工具链描述其发展。尽管如此,我们仍然可以看到一些趋势。今年,我有幸作为主编参与了科技雷达第一期的翻译工作。作为一名DevOps爱好者,我很高兴在这个过程中看到DevOps未来发展的几个趋势,总结在本文中。趋势一:微服务仍然是DevOps技术应用和发展的主要领域。微服务将单个应用系统划分为多个简单且独立的应用。从技术上讲,这是通过工具将应用内部的复杂性转化为外部的复杂性,需要一系列的工具来支持微服务本身以及服务之间的通信。从组织的角度来说,一个微服务团队想要满足“快速发布、独立部署”的能力,就必须具备DevOps的工作方式。如何拆解微服务一直是微服务技术应用中最难的点之一。领域驱动设计是拆解微服务的理想方法。社交代码分析通过更精准的数据帮助团队找到更合适的分裂点。CodeScene是一个在线服务,可以帮助识别热点和复杂难维护的子系统,通过及时分析分布式子系统的耦合度,发现子系统之间的耦合度。此外,它还可以帮助你理解组织中的康威定律,这将大大降低微服务解耦的难度。另外,微服务系统本质上是一个分布式系统,分布式系统之间的通信一直是一个非常重要的问题。本期介绍的KafkaStreams和OpenTracing就是这类技术的入口。Kafka作为一个成熟的分布式消息系统,已经被广泛采用,而KafkaStreams将最佳实践作为一个“图书馆”呈现给开发者,让操作Kafka变得更加自然和简单。OpenTracing填补了跨多个微服务请求跟踪的空白。另一方面,无服务器架构(Serverlessarchitecture)将DevOps技术在微服务领域的应用推向了极致。当应用程序执行环境的管理被新的编程模型和平台所取代时,团队的交付生产力得到进一步提高。一方面省去了很多环境管理工作,包括设备、网络、主机,以及相应的软件和配置工作,使软件运行环境更加稳定。另一方面,大大降低了团队采用DevOps的技术门槛。然而,微服务中端到端的交付和功能管理的问题越来越突出。虽然AWSAPI网关和AWSLambda几乎成为了Serverless架构的代名词,但两者结合的开发者体验并不好。于是出现了Serverless框架、CLAUDIA等管理工具。AWSLambda带来的优势也深深影响了企业级应用领域。ApacheOpenWhisk是企业级无服务器领域的选择之一,它使企业级应用程序能够使用无服务器风格的架构构建应用程序。在微服务端到端的交付过程中,Netflix开源了自己的Spinnaker。作为微服务实践的先行者,Netflix不断推出新的开源工具,以弥补社区中微服务技术和最佳实践的不足。SpringCloud在熟悉的Spring技术栈下,为开发者提供了一系列工具来使用这些服务协调技术(coordinationtechniques),如服务发现、负载均衡、断路器和健康检查等。在微服务的安全中,最常见的需求之一是通过认证和授权功能来保护服务或API。这部分功能往往是最重要和重复建设的。Keycloak是一种开源身份和访问管理解决方案,用于保护应用程序或微服务。并且几乎不需要编码,开箱即用。支持单点登录、社交网络登录和标准协议登录(如OpenIDConnect、OAuth2和SAML等)。趋势二:以Docker为核心的数据中心解决方案逐渐成熟。近两年来,Docker社区发展突飞猛进。似乎与Docker相关的条目出现在每个技术雷达中。Docker常常与DevOps联系在一起,被认为是推动DevOps发展的杀手级工具,以至于有些人会将团队是否采用Docker作为团队是否具备DevOps能力的标志。这个社区的创新数量正在趋于平缓。一方面,开源社区的激烈竞争淘汰了一些技术。另一方面,以Docker为核心的完整数据中心解决方案,也在不断整合开源社区的零散工具,形成最佳实践。为了给端到端的开发运维提供更完善的交付体验,各大厂商也开始推广自己的企业级整体计费方案,可见Docker的使用已经成熟。MesosphereDC/OS出现在本期技术雷达的词条中,是构建统一技术栈数据中心的一个征兆。DockerEE和Rancher都是这方面非常有力的竞争者。根据我的判断,在未来的Docker社区中,统一容器化数据中心的竞争者会进一步减少。之前的私有云解决方案将逐渐被“以Docker为核心的数据中心级全栈交付”所取代。趋势3:不完整的DevOps实践阻碍了DevOps的发展看到像单一持续集成实例和不完整持续集成(CI剧院)这样的条目出现在技术雷达上,真是令人遗憾。可以感受到企业应用DevOps技术的紧迫性。这也暴露了DevOps领域“缺乏低门槛、成熟的DevOps实践”的问题。大多数企业在DevOps转型中只关注工具的升级。但忽视价值流、生产过程中各项活动中的最佳实践,以及DevOps团队文化的建设,这会让团队陷入“DevOps转型已经完成的假象”,阻碍团队的自我发展。改进。DevOps的实践包括组织提升和技术升级两部分,而技术往往是最容易的部分。但是,没有组织改进的技术改进,往往难以给组织带来质的飞跃。具有DevOps文化的团队会不断反思和学习,并通过共同责任和相互合作不断改进组织的DevOps实践。趋势4:特定领域的DevOps实践开始出现。DevOps最早的实践来自于互联网公司的Web应用,相应的思想被引入企业级应用,推动了一系列工具的发展。尽管并非每种应用软件交付形式都适合DevOps,但随着DevOps工具的不断成熟。其他领域的DevOps实践也开始尝试借鉴web应用领域的自动化工具,逐渐形成了领域级的DevOps实践。在人工智能领域,TensorFlow就是这样一个例子,它可以有多种DevOps友好的安装部署方式,比如使用Docker进行部署。在区块链领域,HYPERLEDGER就是这样一个例子。它提供了一套工具和服务,并结合DevOps相关技术和实践,形成一个完整的解决方案。随着DevOps相关概念和技术向各个工业领域的不断深入发展,我们可以看到DevOps技术和实践所带来的巨大影响。但是,每个技术领域都有自己值得关注的特点,这是以往的DevOps实践无法完全涵盖的。这恰好成为DevOps技术和实践发展的契机。我很期待特定领域的DevOps技术实践给DevOps带来的发展。趋势5:采用DevOps进行技术债务重组和技术资产管理技术债务与金融债务类似,它也会产生利息。这里的利益其实是指由于草率的设计决策,需要在未来的发展中付出更多的努力。投资银行业往往采用多种金融工具的组合方式来处理企业的不良债务。清理技术债务的实践和工具乏善可陈。技术债务不仅阻碍了企业通过新技术带来便利,还使企业偿还技术债务的成本越来越高,如技术人才流失、技术利息等综合风险。虽然企业因技术债而走下坡路的案例极少,但新企业颠覆传统行业、利用新技术和商业模式抢占市场份额的报道屡见不鲜。另一方面,这表明技术债务全面增加了采用新技术的机会成本,使企业失去了巨大的创新潜力和领先优势。DevOps技术栈的多样化为分散遗留系统的技术债务风险提供了一套灵活且低风险的工具和方法。不断帮助企业摆脱遗留系统的负担。微服务首先通过域拆分技术债,并使用相应的工具重组技术债。将优质技术资产与不良资产分离,通过分散风险降低废弃成本。将API视为产品(APIsasaproduct)可以从进化的新视角看待技术债,通过可用性测试和用户体验研究,帮助企业剥离技术债中的优质资产和不良资产。另一方面,本期技术雷达出现了打包遗留系统的做法,通常与Vagrant、Packer和Docker等工具结合使用。一方面隔离了技术债的风险,另一方面防止了遗留系统上产生的技术债利息的增长。趋势六:安全成为推动DevOps全面发展的重要力量安全是DevOps永远绕不开的话题,往往是传统行业(如金融、电信)应用新技术的最大障碍。一方面,组织架构的转型迫使企业打破原有的部门壁垒,这意味着很多原有的控制流程不再适用。另一方面,由于大量的DevOps技术来自于开源社区,缺乏强大技术实力的企业在应用相关技术时难免会有顾虑。将机密信息的管理与代码解耦,可以让我们避免一些在开发过程中可能出现的安全风险。使用git-crypt这样的工具可以帮助我们在开发过程中保证源代码内部信息的安全。HashiCorpVault的使用提供了一种与应用程序代码分离的秘密信息存储机制,使应用程序在运行过程中的秘密得到有效保护。Linux安全模块一直处于技术雷达的“采用”领域,帮助团队评估谁可以通过SELinux和AppArmor等LSM兼容性访问共享主机上的哪些资源(包括其中的服务)。这种保守的访问管理方法将帮助团队在其SDLC流程中构建更好的安全性。在过去,这是Ops团队需要考虑的问题,但对于DevOps团队来说,这是每个人的事。“ComplianceasCode”是继“InfrastructureasCode”和“PipelineasCode”之后的又一次自动化尝试。作为合规即代码的提出者和实施者,InSpec使用自动化手段确保服务器在部署后运维生命周期中保持安全和合规。它带来的意义在于将规范体系编纂成法典,获得确定性的结果和解释。在不远的将来,不难想象,人们面对的法律法规不再是一堆造成歧义的语言文字条目,而是一套由自动化测试组成的测试环境。安全性和易用性通常被认为是不能兼得的两个方面。在DevOps之前,团队吞吐量和系统稳定性指标都曾面临这样的情况,但DevOps允许两者兼而有之。同样,我也有信心在未来的DevOps领域,会不断涌现出更多易用和安全的工具。在降低DevOps带来的安全风险的同时,也提高了团队开发过程的流畅性和用户的便利性。趋势七:WindowsServer和.NET平台下的DevOps技术潜力巨大长期以来,Windows和.NET平台下的DevOps一直是一个被低估的领域。一方面,社区对WindowsServer平台缺乏兴趣。另一方面,WindowsServer的市场占有率接近90%,在Web服务器领域的市场占有率达到33.5%。有充分的理由证明这是一个潜力巨大的市场。我们看到CAKE和FAKE等条目作为.NET平台的构建解决方案来替代MSBuild,它增强了.NET平台的自动化方面。HANGFIRE提供了一个更易于使用和灵活的自动化流程调度框架。期待未来在WindowsServer和.NET平台领域的更多创新。不久前,Docker已经可以在Windows下运行。可以预见,WindowsServer和.NET平台将是下一阶段DevOps技术实践值得深入探索的领域。(图片来自:http://t.cn/RX3hWed)趋势八:非功能性自动化测试工具的逐步完善自动化测试水平往往是衡量DevOps技术能力的重要指标,尤其是对于生产中的非功能性应用环境自动化测试工具。长期以来,TechnologyRadar一直试图从不同的角度宣传自动化测试的重要性,从软件开发阶段延伸到整个应用程序生命周期,甚至是整体IT资产的管理。这个技术雷达仍然关注非功能性自动化测试,而TestInfra是ServerSpec的Python实现,它使得使用Pytest测试基础设施成为可能。而MOLECULE旨在帮助开发和测试Ansible的Role。通过搭建在虚拟机或容器上运行AnsibleRole测试的脚手架,无需手动创建这些测试环境。正如TechnologyRadar所说:“虽然这是一个相当年轻的项目,但我们看到了它的巨大潜力。”趋势九:Python已经成为DevOps工作不可或缺的语言早在DevOps刚刚开始盛行时,Python就是一门被寄予厚望的语言,因为大多数DevOps工具和实践都需要使用Python。虽然有人尝试用Ruby或NodeJS构建DevOps工具,但它们都不如用Python构建的工具受欢迎。与此同时,还有人将其他语言编写的工具转换成Python版本。TestInfra就是这样一个例子。随着Python在大数据、人工智能、区块链、微服务、Docker等领域的发展,可以预见,Python在未来仍将发挥重要作用。【本文为专栏作者“ThoughtWorks”原创稿件,微信公众号:Thinkworker,转载请联系原作者】点此查看该作者更多好文