本文转自:ThoughtWorks洞见

技术雷达是ThoughtWorks每半年发布一次的技术趋势报告,它持续追踪有趣的技术是如何发展的,我们将其称之为条目。技术雷达使用象限和环对其进行分类,不同象限代表不同种类的技术,而环则代表我们对其作出的成熟度评估。

经过半年的追踪与沉淀,ThoughtWorks TAB(ThoughtWorks技术咨询委员会)根据我们在多个行业中的实践案例,为技术者产出了第24期技术雷达。对百余个技术条目进行分析,阐述它们目前的成熟度,并提供了相应的技术选型建议。


一、本期四大主题

加速产品上市的平台团队

越来越多的组织正在采用平台团队的理念来开发产品,即成立一个专门团队,来创建和支持内部平台功能,并使用这些功能来加速应用程序开发,降低运维复杂性,并缩短产品上市时间。这种日趋成熟的做法值得欢迎,所以我们早在2017年,就将该技术引入技术雷达。但是随着成熟度的提高,我们发现组织在应用这项技术时,应避免使用一些反模式。例如,“用一个平台来统治一切”,可能并不是最佳选择。“构建一步到位的大平台”,可能要过数年后才能交付价值。本着“一旦建好,就有人用”的初衷,到头来可能却是巨大的浪费。相反,使用产品思维,有助于根据产品客户的需求,来弄清每个内部平台所应提供的服务。但如果让平台团队只解决技术支持工单系统中所提交的问题,那么这种做法就又产生了老式的运维孤岛团队,出现相应的需求优先级失调的弊端,如反馈和响应缓慢,以及争夺稀缺资源等的问题。此外,我们还看到一些新工具和集成模式涌现出来,以有效划分团队和技术。

整合的便利性盖过单项最佳方案

我们在许多平台(特别是在云领域)上看到了相应的面向开发者的工具集成。例如,工件库、源码控制、CI/CD流水线、wiki以及类似的工具,开发团队通常会手工挑选这些工具并按需拼接在一起。拥有合并的工具栈可以为开发人员带来更多的便利和更少的工作,但这套工具集却很少能代表最佳的解决方案。

太复杂以至于无法进入雷达

在技术雷达的命名法则里,对许多复杂主题的讨论,最终状态都会是“TCTB——太复杂以至于无法进入雷达(too complex to blip)”。这意味着那些条目无法被分类,因为它们呈现出太多正反两面的特性,以及大量关于建议、工具的适用性和其他原因上的细微差别,这让我们无法用短短几句话总结它们。这些主题通常每年都会出现,包括monorepos,分布式架构的编排指南以及分支模型等等。就像软件开发中的许多主题一样,那里存在太多权衡,难以提供清晰明确的建议。

识别架构耦合上下文

在软件架构中,如何在微服务、组件、API网关、集成中心、前端等等之间确定一个适当的耦合级别,是几乎每次会议都会讨论的话题。随处可见的情况是,当两个软件需要连接在一起时,架构师和开发人员都在努力地寻找正确的耦合级别。我们需要花时间和精力去理解这些因素,然后因地制宜地做出这些决定,而不是寄希望于找到一个通用却并不恰当的解决方案。


二、部分象限亮点抢先看

平台工程产品团队

采纳

正如本期雷达主题之一所指出的那样,业界在创建和支持内部平台的“平台工程产品团队”中积累了越来越多的经验。组织中的团队使用这些平台,可以加速应用程序开发,降低运营复杂性并缩短产品上市时间。随着采用率的提高,我们对于这种方法的好和坏的模式也越来越清楚。创建平台时,至关重要的是要明确定义可以从中受益的客户和产品,而不是凭空建立。我们不仅要谨防分层平台团队,它保留了现有技术孤岛,只是贴上了“平台团队”的标签而已,还要小心工单驱动的平台运营模型。当考虑如何最好地组织平台团队时,我们仍然是团队拓扑概念的忠实拥护者。我们认为平台工程产品团队是一种标准方法,并且是高性能IT的重要推动者。

云沙箱

试验

由于云服务变得越来越常见,并且创建云沙箱变得更加容易且可大规模应用,我们的团队因此更倾向于使用完全基于云(相对本地而言)的开发环境,并以此来减少维护复杂度。我们发现用于本地模拟云原生服务的工具限制了开发者对构建和测试周期的信心,所以我们将重点放在标准化云沙箱上,而不是在开发机器上运行云原生组件。这样的方式可以使基础设施即代码实践得到更好的强制应用,并为开发人员提供沙箱环境良好的适应过程。当然这种转变也存在风险,因为它假定开发人员将完全依赖于云环境的可用性,并且可能会减慢开发者获得反馈的速度。我们强烈建议您采用一些精益治理的实践来管理这些沙箱环境的标准化,尤其是在安全、访问控制和区域部署方面。

同态加密

评估

完全的同态加密(Homomorphic encryption)是指一类允许在加密数据上直接进行计算操作(如搜索和算数运算)的加密方法。同时计算的结果仍然以加密的形式存在,并且稍后可以对其进行解密和显示。虽然同态加密问题早在1978年就被提出来了,但直到2009年才出现解决方案。随着计算机算力的提升,和诸如SEAL,Lattigo,HElib和Python中的部分同态加密之类易于使用的开源库的出现,同态加密在现实世界的应用程序中的应用才真正地变得可行。那些令人振奋的应用场景包括在将计算外包给一个不受信的第三方时的隐私保护,例如在云端对加密数据进行计算,或使第三方能够聚合同态加密后的联邦机器学习的中间结果。此外,大多数的同态加密方案被认为是对量子计算机安全的,并且标准化同态加密的努力也正在进行之中。尽管同态加密目前在性能和可支持的计算类型上还存在诸多局限,但是它仍然是一个值得引起我们注意的技术。

Sentry

采纳

Sentry已经成了许多团队的默认选项。Sentry提供了一些便利的功能,比如错误分组,以及使用适当的参数定义错误过滤规则,可以极大地帮助处理来自终端用户设备的大量错误。通过将Sentry集成到持续交付流水线中,你可以上传源码映射文件,从而更高效地调试错误,并能很容易追踪到是在哪个版本的软件中产生了这些错误。我们很欣赏尽管Sentry是一个SaaS产品,但它的源代码是公开的,这样就可以免费用于一些较小的用例和自托管中。

imgcook

评估

imgcook是阿里巴巴旗下的软件即服务产品。它可以通过智能化技术把不同种类的视觉稿(Sketch/PSD/静态图片)一键生成前端代码。imgcook可以生成静态代码,如果你定义了领域专用语言,它也可以生成数据绑定模块代码,该技术还没达到完美的程度,设计人员需要参考某些规范,以提高代码生成的准确性(此后仍需开发人员的调整)。我们对于魔术代码生成一直十分谨慎,因为从长远看,生成的代码通常很难维护,imgcook也不例外。但是如果你限定它用于特定的上下文,例如一次性活动广告页,这项技术值得一试。

AWS CodePipeline

暂缓

根据ThoughtWorks多个团队的使用经验,我们建议你谨慎使用AWS CodePipeline。具体来说,我们发现一旦团队的需求超出简单的流水线范畴,此工具就会变得难以使用。尽管初次使用AWS时,像是赢得了“快速的胜利”,但我们建议你后退一步,评估AWS CodePipeline是否可以满足你的长期需求,例如流水线的fan-out和fan-in,或者是更复杂的部署,以及具有特殊依赖关系及触发条件的测试场景。

Snowflake

试验

自从上次在雷达上提到Snowflake以来,对于它的使用,以及作为数据仓库和数据湖的替代方案的data mesh,我们都获得了更多经验。Snowflake在时间旅行、零拷贝克隆、数据共享及其应用市场等功能方面,继续给人留下深刻印象。Snowflake至今还没出现任何令我们不喜欢的地方,所以相较于其他选择来说,我们的顾问会更偏爱使用它。亚马逊的数据仓库产品Redshift正在朝着将存储和计算进行分离的方向发展,而这一直都是Snowflake的强项。如果使用Redshift产品中的Spectrum特性进行数据分析,就会感觉它并非那么方便和灵活,部分原因是它受到了Postgres的约束(虽然我们也喜欢用Postgres)。而进行联合查询(federated queries)可能是使用 Redshift 的原因。在操作方面,Snowflake的操作会更简单。虽然BigQuery是另一种选择,且非常易于操作,但在多云的场景下,Snowflake是更好的选择。我们已经在GCP、AWS和Azure上成功地使用了Snowflake。

Feature Store

评估

Feature Store是一个服务于机器学习的数据平台,可以解决当前我们在特征工程中所遇到的一些关键问题。它提供了三个基本功能:(1)使用托管的数据管道,以消除新数据与数据管道之间的冲突;(2)对特征数据进行编目和存储,从而促进跨模型的特征的可发现性和协同性;(3)在模型的训练和干扰过程中,持续提供特征数据。自从Uber公开了Michelangelo平台以来,许多组织和初创企业都建立了自己的特征库;例如Hopsworks、Feast和Tecton。我们看到了Feature Store的潜力,并建议仔细对其进行评估。

自研基础设施即代码(IaC)产品

暂缓

那些由公司或社区所支持的(至少在业界引起关注的)产品,正在不断发展。但有时组织会倾向于在现有的外部产品之上,构建框架或抽象,来满足组织内非常特定的需求,并认为这种适配会比其现有的外部产品具备更多好处。我们发现一些组织试图基于现有外部产品,创建自研基础设施即代码(IaC)产品。他们低估了根据其需求不断演进这些自研解决方案而所需投入的工作量。很快他们就会意识到,所基于的外部产品的原始版本要比他们自己的产品好得多。在有些情况下,构建在外部产品之上的抽象,甚至削弱了外部产品的原始功能。虽然目睹过组织自研产品的一些成功案例,但是我们仍然建议要审慎地考虑这种方式。因为这会带来不可忽视的工作量,并且需要确立长期的产品愿景,才能达到预期的结果。

Combine

采纳

我们几年前把ReactiveX(反应式编程开源框架中的一个系列)移到了技术雷达的“采纳”环中。2017年,我们提到了 RxSwift,它可以将反应式编程应用到基于Swift的 iOS 开发中。此后,Apple以Combine的形式推出了自己的反应式编程框架。对于仅支持iOS 13及更高版本的App而言,Combine已经成为默认的选择。它比RxSwift更容易学习,并且与 SwiftUI集成得很好。如果您想要将现有项目框架从RxSwift转换为Combine,或者在一个项目中同时使用两者,可以了解一下RxCombine。

Kotlin Flow

试验

Kotlin协程的引入为Kotlin的创新打开了一扇大门——直接集成到协程库中的Kotlin Flow就是其中之一。Kotlin Flow是一种基于协程的响应式流的实现。与RxJava不同的是,流是Kotlin原生的API,与熟悉的序列API类似,包括map和filter方法。跟序列一样,流是“冷”的,这就意味着只有当需要使用的时候才构造序列的值。所有这些特性使多线程代码的编写比其他方法更加简单和易于理解。可以预见,通过toList方法将流转换成列表将会成为测试中的一种常见模式。

River

评估

众多机器学习方法的核心皆在于从一组训练数据创建一个模型。一旦创建了模型,就可以反复使用它。然而世界并不是静止的,通常模型需要随着新数据的出现而改变。单纯地重新训练模型可能会非常缓慢和昂贵。增量学习解决了这个问题,它使从数据流中增量地学习成为可能,从而更快地对变化做出反应。作为额外的好处,计算和内存需求更低,而且是可预测的。我们在基于River框架的实现中积累了良好的经验,但到目前为止,我们需要在模型更新后增加校验,有时要手动进行。

ThoughtWorks-2021上半年,请24期技术雷达正式发布!相关推荐

  1. 有态度的前沿技术解析,第22期技术雷达

    ​技术雷达是ThoughtWorks每半年发布一期的技术趋势报告,它不仅是一份持续的技术成熟度评估,其产生还源于ThoughtWorks另一个更大宏大的使命-IT革命.我们一直深信,IT行业从定位.价 ...

  2. 如何面对黑天鹅与灰犀牛?ThoughtWorks技术雷达峰会给出答案

    技术始终在变化,观点永远不会短缺,因而,对于趋势的判断至关重要.ThoughtWorks技术雷达正是这样一份关注前沿技术性变化的报告:对当前软件开发中发人深省的改变进行解读,并指出可应用于项目中的新兴 ...

  3. 【技术雷达】Thoughtworks 技术雷达 第28期:实用人工智能的飞速崛起

    思特沃克发布第28期<技术雷达>,指出要谨慎乐观地应对备受瞩目的人工智能趋势 April 26, 2023 - Beijing 今年是全球软件及技术咨询公司思特沃克(Thoughtwork ...

  4. 什么是ThoughtWorks技术雷达?

    今年3月,小灰有幸在深圳见到了一位IT行业的世界级大神,这位大神就是 Martin Fowler,<重构>的作者,敏捷开发的创始人之一. 那一次,正赶上ThoughtWorks技术雷达10 ...

  5. 从ThoughtWorks 2017技术雷达看微软技术

    ThoughtWorks在每年都会出品两期技术雷达,这是一份关于技术趋势的报告,它比起一些我们能在市面上见到的其他各种技术行情和预测报告,更加具体,更具可操作性,因为它不仅涉及到新技术大趋势,比如云平 ...

  6. 在深圳,让我们一起洞见技术的未来——2018 技术雷达峰会

    只需稍加留意,我们就会发现自己正被各种技术.工具包围.ThoughtWorks 的技术雷达差不多每半年就会更新一次,在项目中更会遇到很多已经从技术雷达上消失的技术,项目上的旧技术/旧框架还在服役,新的 ...

  7. 从技术雷达看DevOps的十年 – 基础设施即代码和云计算

    在上一篇文章中,我们讲到了 DevOps 和持续交付的关系.本篇将回顾最先改变运维工作的相关技术 -- 基础设施即代码和云计算,通过技术雷达上相关条目的变动来跟踪其趋势变化. 和持续交付一样,基础设施 ...

  8. 《强化学习周刊》第24期:CORL 2021强化学习的最新研究与应用

    No.24 智源社区 强化学习组 强 化 学  习 研究 观点 资源 活动 关于周刊 强化学习作为人工智能领域研究热点之一,其研究进展与成果也引发了众多关注.并且诸多研究成果发表于CORL 2021学 ...

  9. ThoughtWorks技术雷达专区

    作为一家服务于全球不同类型的IT专业服务公司,ThoughtWorks从未停止过对卓越技术的追求,为此,ThoughtWorks的全球技术委员会(TAB)会定期讨论技术战略,并将其绘制成一份能够体现技 ...

最新文章

  1. HDOJ 1213 HDU 1213 How Many Tables ACM 1213 IN HDU
  2. 那些人工智能未来式,没看过你就 OUT 了
  3. 海量大数据大屏分析展示一步到位:DataWorks数据服务+MaxCompute Lightning对接DataV最佳实践...
  4. FatMouse's Speed hdu 1160(动态规划,最长上升子序列+记录路径)
  5. Java B2B2C多用户电子商务平台SpringCloud/Boot
  6. TensorFlow基本原理,入门教程网址
  7. 95-30-018-Channel-AbstractNioByteChannel
  8. (原创)日志处理(修改)
  9. GCN在交通流预测方面的相关文章
  10. OK6410移植UBOOT
  11. STC8A8K64D4(51系列单片机)printf打印数据异常的问题
  12. 哈工大CSAPP大作业:程序人生-Hello’s P2P
  13. 传奇单职业1.76御天战神强势来袭
  14. 乐得瑞推出多款USB Type-C接口方案,显示器和电视机专用
  15. 从all-merged-Graph-Based Genes.csv 提取出 average expression avglogfc 或者pval doheatmap
  16. python习题计算a+aa+aaa+aaaa的结果 lintcode题目
  17. Java_JDK19.0.2_Ubuntu18.04中配合海康工业相机SDK环境搭建
  18. h5怎么获取微信用户openId,h5如何获取微信用户openId
  19. 伪时序分析文献阅读——PAGA
  20. 激流勇进,数据库替代比预想要快得多

热门文章

  1. 压控电流源等效成一个电阻
  2. 推荐10个值得一听的国外技术播客
  3. HDU 4884 —— TIANKENG’s rice shop(模拟)
  4. 永中软件承接“核高基”专项
  5. 菜鸟小超超开发小记(一)
  6. 仿作苏宁易购主页顶端
  7. 联想造超级计算机,联想将造超级计算机 性能10倍于IBM蓝色基因
  8. [递归+访问者模式]实现树状结构的节点遍历处理
  9. 万万没想到!我拒绝了一位知名VC大佬的创业合伙人邀请
  10. 洛谷:玩具谜题,C语言