技术雷达|固执己见的技术前沿指南|思想工作188bet宝金博app下载

下载技术雷达第24卷

本版主题

越来越多的组织开始采用“平台团队”的概念:建立一个专门的小组来创建和支持内部平台功能，然后使用这些功能来加速应用程序开发，降低操作复杂性，并缩短上市时间。

我们已经看到面向开发人员的工具集成的兴起——特别是在云领域——伴随着工件存储库、源代码控制、CI/CD管道、wiki和其他工具的聚集。这些整合的工具栈承诺为开发人员提供更大的便利，同时减少用户的流失。但这些工具很少代表最好的可能选择。

我们讨论的许多关于雷达的复杂话题最终都被归类为“TCTB -太复杂以至于不能闪烁”。而且，这些话题经常反复出现;这些包括单业务、分布式体系结构和分支模型的编配指导方针。就像软件开发中的许多主题一样，存在太多的权衡，无法给出清晰、明确的建议。

识别架构耦合的上下文

我们在几乎每次会议上都要讨论的一个话题是，软件体系结构中微服务、组件、API网关、集成中心、前端等等之间适当的耦合级别……几乎在任何地方，两个软件都可能连接在一起。但没有唯一的正确答案:这些决定必须在个案的基础上作出，而不是寻求一个通用但不充分的解决方案。

平台团队推动市场速度

越来越多的组织开始采用平台团队的概念:建立一个专门的小组来创建和支持内部平台功能——云本地、持续交付、现代可观察性、AuthZ/N模式、服务网格等等——然后使用这些功能来加速应用程序开发，降低操作复杂性并缩短上市时间。这种不断增长的成熟是受欢迎的，我们首先介绍了这一点技术在2017年的雷达。但是随着成熟度的提高，我们也发现了组织应该避免的反模式。例如，“一个平台统治所有平台”可能不是最理想的，“大平台”可能需要数年时间来交付价值，“构建它，它们就会到来”可能最终是一种浪费。相反，使用产品思考的方法可以帮助你明确每个内部平台应该提供什么，这取决于它的客户。公司把他们的平台团队在售票系统后面就像老式的操作竖井一样，它也会发现优先级不一致的缺点:反馈和响应缓慢，资源分配争用，以及竖井引起的其他众所周知的问题。我们也看到了一些新的工具集成模式对于团队和技术的出现，允许对两者进行更有效的划分。

综合便利胜过班级最佳

随着以自动化、规模化和其他现代目标为特征的工程实践在开发团队中变得越来越普遍，我们在许多平台上看到了相应的面向开发人员的工具集成，特别是在云空间中。例如，工件存储库、源代码控制、CI/CD管道、wiki和类似的工具通常是由开发团队手工挑选的，然后拼接在一起à la carte。现在，配送平台如Azure DevOps生态系统，比如GitHub包含了许多这些工具类别。虽然不同平台提供的成熟程度不同，但对交付工具的“一站式商店”的吸引力是不可否认的。总的来说，似乎需要权衡的是使用统一的工具堆栈为开发人员提供更大的便利和更少的混乱，但是工具集很少代表最好的可能。

永远的“太复杂而不能闪烁”

在雷达命名法,讨论后的最终状态对许多复杂的主题是“TCTB——太复杂信号”:项挑战分类,因为他们提供了一个数量的利弊,大量的细微差别的适用性的建议或工具或其他原因阻止我们在几句话总结自己的观点。通常，这些话题会继续文章，播客，以及其他非雷达目的地。我们最丰富的一些对话就是围绕这些话题展开的:它们很重要，但也很复杂，避免了单一简洁的观点。无数的主题在一个接一个的会议中反复出现——关键的是，我们的几个客户约定——最终归于TCTB，包括单业务、分布式架构和分支模型的编配指导方针等等。对于那些想知道为什么这些重要的话题没有进入雷达领域的人来说，这并不是因为我们缺乏意识或欲望。就像软件开发中的许多主题一样，存在太多的权衡，无法给出清晰、明确的建议。我们有时确实能找到更大的话题的小片段，我们可以提供建议，并在雷达上，但更大的话题永远太微妙和不稳定的雷达。

识别架构耦合的上下文

几乎在每一次会议上都会出现的一个主题(参见“永远的‘太复杂了’”)是软件体系结构中微服务、组件、API网关、集成中心、前端等之间的适当耦合级别。几乎在两个软件可能连接的任何地方，架构师和开发人员都很难找到正确的耦合级别——许多常见的建议鼓励极端的分离，但这使构建工作流变得困难。架构中的耦合涉及许多重要的考虑因素:事物如何连接、理解每个问题域内固有的语义耦合、事物如何相互调用，或者事务如何工作(有时与其他棘手的特性如可伸缩性相结合)。在单一的单片系统之外，如果没有某种程度的耦合，软件就无法存在;对现代体系结构来说，确定正确的权衡集以确定耦合的类型和级别是一项关键技能。我们确实看到了一些不好的实践，比如为客户端库生成代码，以及一些好的实践，比如明智地使用BFF模式。然而，一般的建议在这个领域是无用的，银弹不存在。在具体情况下做决定时，要花时间和精力去理解起作用的因素，而不是寻找一个通用的但不充分的解决方案。