我们想出了各种方法来显示从一个雷达体积到另一个的光点。光点可以是新的体积或在环之间移动。
我们在这个版本的Radar中讨论了几个主题(其中一些最终未能进入最终版本),其中团队正在使用工具来适应/来自Kafka。其中一些工具允许Kafka使用更传统的接口(例如ksqlDB,融合Kafka REST代理,以及Nakadi),而其他一些则旨在提供额外的服务,如GUI前端和编配附加组件。我们怀疑这些工具的大量存在的部分潜在原因是Kafka的一些部分的潜在尖锐的复杂性,以及组织中日益增加的存在,这些组织需要将其转向现有的架构和过程。一些团队最终进行了治疗Kafka作为下一代企业服务总线-一个例子便利的滑坡效应主题 - 但其他团队使用Kafka在发生时提供普遍的商业活动。这些组织认识到,有时更容易拥有一个具有适应性的集中基础设施,并尝试避免谨慎的设计和治理。无论如何,它表明,Kafka继续朝着卷上异步发布/订阅消息传递的事实标准。
与Radar一样古老的反模式是团队倾向于将行为置于他们的生态系统中方便但不恰当的连接点,从而导致长期的技术债务和更糟的情况。例子有很多,包括使用数据库作为集成点,使用卡夫卡作为一个全局协调器,将业务逻辑与基础架构代码混合在一起,等等。现代软件开发为开发人员提供了许多隐藏行为的地方,而缺乏经验或不考虑周到的团队经常因为不仔细考虑不适当耦合的长期后果而使问题复杂化。不适当的团队结构和其他偏离康威定律也不帮助。随着软件系统变得越来越复杂,开发团队必须努力创建和维护周到的架构和设计,而不是为了权宜之计而草率地做出决定。通常,考虑特定方法的可测试性会导致团队远离这些潜在的问题决策。如果让软件自己处理,它就会变得很复杂。仔细的设计以及(也许更重要的是)正在进行的治理能够确保进度压力或其他众多破坏性力量之一不会导致团队做出方便但不恰当的决定。
在软件领域,许多人推崇复杂问题的聪明解决方案,但这些聪明的解决方案往往是由自己造成的偶然的复杂性造成的。目前存在许多这种现象的例子,包括将编制或协调代码隐藏在不适当的位置这一不幸但常见的实践。例如,我们看到了聪明的工作流管理工具,比如气流或者完善它们被过度地用于通过业务流程管理复杂的数据管道。我们找到了许多工具,可以解决由单股股引起的问题,比如NX.和许多更多。团队往往没有意识到,他们在不必要的复杂性上增加了两倍或三倍,而没有退后一步看看大局,并质疑当前的解决方案是否比问题本身更糟糕。与其用更多的技术来解决问题,团队应该做根本原因分析,解决潜在的基本复杂性和正确的过程。数据网格是一个解决导致过度复杂的数据管道和工具的底层组织和技术假设的方法示例。
我们发现,在这一期的Radar中,与平台相关的光点数量出现了严重下降,我们将其归因于一些行业标准的整合:大多数公司已经选择了自己的云供应商,而且他们大多已经对其进行了标准化Kubernetes.用于容器编排和卡夫卡高性能消息传递。这是否意味着平台不再重要?或者,我们是否正在经历一个交替扩张和收缩的商业周期——例如,在数据库技术中,我们已经看到了类似的快速创新随后停滞的时期(史蒂芬·杰伊·古尔德称之为“间断均衡”)。随着各大公司逐渐适应云计算带来的结构性转变,并等待下一波颠覆性创新的到来,或许整个行业已经进入了一个相对平静的时期。
技术雷达是由Thoughtworks技术咨询委员会准备的,包括:188bet宝金博app下载
丽贝卡·帕森斯(首席技术官)•马丁·福勒(首席科学家)•Bharani苏•BirgittaBöckeler.•布兰登·拜亚斯•卡米拉尔孔尼Crispim•卡西Shum•Erik Doernenburg•Fausto de la Torre•郝徐•伊恩·卡特赖特•詹姆斯•刘易斯•Lakshminarasimhan苏达山•迈克梅森•尼尔福特•珍珠比利亚雷亚尔•斯科特·肖•Shangqi刘•Zhamak Dehghani
我们全年发布与技术雷达相关的文章