2021年一定要关注的技术趋势和选型意见

技术雷达是 ThoughtWorks 每半年发布一次的技术趋势报告,它持续追踪有趣的技术是如何发展的,我们将其称之为条目。技术雷达使用象限和环对其进行分类,不同象限代表不同种类的技术,而环则代表我们对其作出的成熟度评估。
 
经过半年的追踪与沉淀,ThoughtWorks TAB(ThoughtWorks 技术咨询委员会)根据我们在多个行业中的实践案例,为技术者产出了第 24 期技术雷达。对百余个技术条目进行分析,阐述它们目前的成熟度,并提供了相应的技术选型建议。
 
1
 
本期四大主题
 
加速产品上市的平台团队
 
越来越多的组织正在采用平台团队的理念来开发产品,即成立一个专门团队,来创建和支持内部平台功能,并使用这些功能来加速应用程序开发,降低运维复杂性,并缩短产品上市时间。这种日趋成熟的做法值得欢迎,所以我们早在 2017 年,就将该技术引入技术雷达。但是随着成熟度的提高,我们发现组织在应用这项技术时,应避免使用一些反模式。
 
例如,“用一个平台来统治一切”,可能并不是最佳选择。“构建一步到位的大平台”,可能要过数年后才能交付价值。本着“一旦建好,就有人用”的初衷,到头来可能却是巨大的浪费。相反,使用产品思维,有助于根据产品客户的需求,来弄清每个内部平台所应提供的服务。但如果让平台团队只解决技术支持工单系统中所提交的问题,那么这种做法就又产生了老式的运维孤岛团队,出现相应的需求优先级失调的弊端,如反馈和响应缓慢,以及争夺稀缺资源等的问题。此外,我们还看到一些新工具和集成模式涌现出来,以有效划分团队和技术。
 
整合的便利性盖过单项最佳方案
 
我们在许多平台(特别是在云领域)上看到了相应的面向开发者的工具集成。例如,工件库、源码控制、CI/CD 流水线、wiki 以及类似的工具,开发团队通常会手工挑选这些工具并按需拼接在一起。拥有合并的工具栈可以为开发人员带来更多的便利和更少的工作,但这套工具集却很少能代表最佳的解决方案。
 
太复杂以至于无法进入雷达
 
在技术雷达的命名法则里,对许多复杂主题的讨论,最终状态都会是“TCTB太复杂以至于无法进入雷达(too complex to blip)”。这意味着那些条目无法被分类,因为它们呈现出太多正反两面的特性,以及大量关于建议、工具的适用性和其他原因上的细微差别,这让我们无法用短短几句话总结它们。这些主题通常每年都会出现,包括 monorepos,分布式架构的编排指南以及分支模型等等。就像软件开发中的许多主题一样,那里存在太多权衡,难以提供清晰明确的建议。
 
识别架构耦合上下文
 
在软件架构中,如何在微服务、组件、API 网关、集成中心、前端等等之间确定一个适当的耦合级别,是几乎每次会议都会讨论的话题。随处可见的情况是,当两个软件需要连接在一起时,架构师和开发人员都在努力地寻找正确的耦合级别。我们需要花时间和精力去理解这些因素,然后因地制宜地做出这些决定,而不是寄希望于找到一个通用却并不恰当的解决方案。
 
2
 
部分象限亮点抢先看
 
2021年一定要关注的技术趋势和选型建议
 
平台工程产品团队(采纳)
 
正如本期雷达主题之一所指出的那样,业界在创建和支持内部平台的“平台工程产品团队”中积累了越来越多的经验。组织中的团队使用这些平台,可以加速应用程序开发,降低运营复杂性并缩短产品上市时间。随着采用率的提高,我们对于这种方法的好和坏的模式也越来越清楚。创建平台时,至关重要的是要明确定义可以从中受益的客户和产品,而不是凭空建立。
 
我们不仅要谨防分层平台团队,它保留了现有技术孤岛,只是贴上了“平台团队”的标签而已,还要小心工单驱动的平台运营模型。当考虑如何最好地组织平台团队时,我们仍然是团队拓扑概念的忠实拥护者。我们认为平台工程产品团队是一种标准方法,并且是高性能 IT 的重要推动者。
 
云沙箱(试验)
 
由于云服务变得越来越常见,并且创建云沙箱变得更加容易且可大规模应用,我们的团队因此更倾向于使用完全基于云(相对本地而言)的开发环境,并以此来减少维护复杂度。我们发现用于本地模拟云原生服务的工具限制了开发者对构建和测试周期的信心,所以我们将重点放在标准化云沙箱上,而不是在开发机器上运行云原生组件。这样的方式可以使基础设施即代码实践得到更好的强制应用,并为开发人员提供沙箱环境良好的适应过程。当然这种转变也存在风险,因为它假定开发人员将完全依赖于云环境的可用性,并且可能会减慢开发者获得反馈的速度。我们强烈建议您采用一些精益治理的实践来管理这些沙箱环境的标准化,尤其是在安全、访问控制和区域部署方面。
 
同态加密(评估)
 
完全的同态加密 (Homomorphic encryption) 是指一类允许在加密数据上直接进行计算操作(如搜索和算数运算)的加密方法。同时计算的结果仍然以加密的形式存在,并且稍后可以对其进行解密和显示。虽然同态加密问题早在 1978 年就被提出来了,但直到 2009 年才出现解决方案。随着计算机算力的提升,和诸如 SEAL, Lattigo, HElib 和 Python 中的部分同态加密之类易于使用的开源库的出现,同态加密在现实世界的应用程序中的应用才真正地变得可行。那些令人振奋的应用场景包括在将计算外包给一个不受信的第三方时的隐私保护,例如在云端对加密数据进行计算,或使第三方能够聚合同态加密后的联邦机器学习的中间结果。此外,大多数的同态加密方案被认为是对量子计算机安全的,并且标准化同态加密的努力也正在进行之中。尽管同态加密目前在性能和可支持的计算类型上还存在诸多局限,但是它仍然是一个值得引起我们注意的技术。

dawei

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注