雷达技术

我们在这个版本的Radar中讨论了几个主题(其中一些最终未能进入最终版本)，其中团队正在使用工具来适应/来自Kafka。其中一些工具允许Kafka使用更传统的接口(例如ksqlDB，融合Kafka REST代理，以及Nakadi)，而其他一些则旨在提供额外的服务，如GUI前端和编配附加组件。我们怀疑这些工具的大量存在的部分潜在原因是Kafka的一些部分的潜在尖锐的复杂性，以及组织中日益增加的存在，这些组织需要将其转向现有的架构和过程。一些团队最终进行了治疗Kafka作为下一代企业服务总线-一个例子便利的滑坡效应但是其他团队使用Kafka来提供对发生的业务事件的通用访问。这些组织认识到，拥有一个集中的基础设施，在边缘进行调整，并通过仔细的设计和治理避免蔓延，有时会更容易一些。无论如何，它表明Kafka继续作为异步发布/订阅消息量的事实上的标准。

与Radar一样古老的反模式是团队倾向于将行为置于他们的生态系统中方便但不恰当的连接点，从而导致长期的技术债务和更糟的情况。例子有很多，包括使用数据库作为集成点，使用卡夫卡作为一个全局协调器，将业务逻辑与基础架构代码混合在一起，等等。现代软件开发为开发人员提供了许多隐藏行为的地方，而缺乏经验或不考虑周到的团队经常因为不仔细考虑不适当耦合的长期后果而使问题复杂化。不适当的团队结构和其他偏离康威定律也不帮助。随着软件系统变得越来越复杂，开发团队必须努力创建和维护周到的架构和设计，而不是为了权宜之计而草率地做出决定。通常，考虑特定方法的可测试性会导致团队远离这些潜在的问题决策。如果让软件自己处理，它就会变得很复杂。仔细的设计以及(也许更重要的是)正在进行的治理能够确保进度压力或其他众多破坏性力量之一不会导致团队做出方便但不恰当的决定。

许多建筑师引用康威定律在本版本中，我们通过几个被提名的亮点发现，一个组织的团队结构在处理好的时候仍然是一个关键的促成因素，在处理不好的时候仍然是一个严重的障碍。我们讨论的例子包括需要围绕平台团队进行产品思考，而不是将他们视为订单承接者;团队拓扑以及人们对团队的认知负荷关于效力;围绕程序员生产力开发的新框架叫做空间．组织在工具上花费了大量的资金，但是许多组织通过关注构建软件的人员以及在特定组织中是什么使它们有效，发现了更好的生产力收益。

在软件领域，许多人推崇复杂问题的聪明解决方案，但这些聪明的解决方案往往是由自己造成的偶然的复杂性造成的。目前存在许多这种现象的例子，包括将编制或协调代码隐藏在不适当的位置这一不幸但常见的实践。例如，我们看到了聪明的工作流管理工具，比如气流或完善它们被过度地用于通过业务流程管理复杂的数据管道。我们找到了许多工具，可以解决由单股股引起的问题，比如Nx和许多更多。团队往往没有意识到，他们在不必要的复杂性上增加了两倍或三倍，而没有退后一步看看大局，并质疑当前的解决方案是否比问题本身更糟糕。与其用更多的技术来解决问题，团队应该做根本原因分析，解决潜在的基本复杂性和正确的过程。数据网格是一个解决导致过度复杂的数据管道和工具的底层组织和技术假设的方法示例。

我们发现，在这一期的Radar中，与平台相关的光点数量出现了严重下降，我们将其归因于一些行业标准的整合:大多数公司已经选择了自己的云供应商，而且他们大多已经对其进行了标准化Kubernetes用于容器编排和卡夫卡高性能消息传递。这是否意味着平台不再重要?或者，我们是否正在经历一个交替扩张和收缩的商业周期——例如，在数据库技术中，我们已经看到了类似的快速创新随后停滞的时期(史蒂芬·杰伊·古尔德称之为“间断均衡”)。随着各大公司逐渐适应云计算带来的结构性转变，并等待下一波颠覆性创新的到来，或许整个行业已经进入了一个相对平静的时期。