InfoQ和QCon都关注我们认为属于“创新者,早期采用者和早期多数阶段”的主题。我们尝试做的是确定适合Geoffrey Moore所谓的早期市场的想法,其中“客户群由技术爱好者和有远见的人提供,他们希望领先于机遇或迫在眉睫的问题”。我们也在寻找可能“跨越鸿沟”的想法,以便更广泛地采用。在这种情况下,或许值得一提的是,技术在采用曲线上的确切位置可能会有所不同。例如,湾区公司在这一点上广泛采用微服务,但在其他地方可能不太广泛采用,也许不太合适。
本文概述了我们目前如何看待“架构和设计”(A&D)领域,该领域侧重于基础架构模式,技术框架中模式的实现,以及软件架构师必须培养的设计流程和技能。
自我们上次审查这一主题以来的显着变化包括“微服务”进入后期多数,但我们的内部讨论还强调,“正确设计分布式系统”的密切相关的主题,以及反应性和容错性的设计并不是沿着采用曲线。对于Gartner炒作周期,我们可能正在接近微服务“幻灭的低谷”的底部。
我们还推测,架构领域永远不会沿着采用曲线走向早期多数或晚期多数,不幸的是,它们包括几种高效模式 - 例如基于事件溯源/ CQRS或Actor 模型 - 基于系统 - 可以为某些组织和业务问题提供高效的解决方案。
虽然我们认为“无服务器”一词略显模糊,但我们很欣赏将重点放在设计模块化,事件驱动系统以及自动化几个底层操作平台问题的可能性上。在一个相关主题上,我们还看到围绕对支持未来需求和约束变化的演化架构的需求的更多讨论。
我们越来越多地看到“架构师”的角色正在变得更加专注于软技能,例如技术领导,除了现代技术技能,如架构模式识别和框架感知,以及处理跨领域问题的设计。
对于上下文,这是2018年下半年主题图的样子.2019版本位于文章的顶部。
以下是三个InfoQ架构和设计主题编辑之间相应内部聊天记录的轻微编辑副本,它为我们在采用图上的推荐定位提供了更多上下文。
Daniel Bryant,独立技术顾问,Datawire产品架构师和InfoQ新闻经理:
作为十人的首发,我认为HTTP2转向早期采用者(EA),HTTP3进入创新者。 GraphQL(以及可能的gRPC)可能是EA(或创新者?)。我也认为Chaos Engineer属于DevOps队列。微服务可能是晚期多数(LM),BDD,DDD和TDD也是如此。 我很想看到“进化架构”出现在某个地方 - 可能是EA?那么“架构师作为技术领导者”(强调角色的非技术演变)呢? 我有兴趣听听您的想法,并询问我们是否需要移动,添加或删除主题?
Jan Stenberg,IT顾问,在.Net / C#和JVM / Java平台上构建系统超过25年:
我认为架构与设计(AD)在某种程度上与我们在InfoQ上讨论的其他主题不同。 在AD中,我们没有新的或更新版本的架构的常规基础。相反,由于新的工具,框架或智能架构使其成为可行,现有的想法再次流行,并且可能打包和品牌化。 我们也有可能适合两个队列的区域。在更高级别,它们可能适用于AD,而更多技术部分适用于另一个队列。我认为无服务器就是一个例子,在更高层次上它是AD的一个重要领域,技术部分可能属于云队列。微前端和类似技术是另一个例子,它是AD还是HTML5和JavaScript? 还有一些我认为永远不会在EM或LM中出现的领域或架构,不幸的是,它们包括我最喜欢的几种架构,如基于事件源/ CQRS或基于Actor模型的系统。我认为他们在可预见的未来将是少数人使用的小众架构。我不确定我们应该如何应对这些问题,也许它们会在架构师和开发人员不再谈论它们时消失? 所以,我对AD未来的看法(或许我的希望):
当我在日常生活中遇到架构师,开发人员,领域专家和其他人,而不是在会议和类似的活动中,我经常意识到我们在这里讨论的许多概念对于他们来说是未知的或非常分散的,这也使得他们看到了InfoQ的好处。我记得大约两年前我在开发者大会(我认为是在加拿大)听过的一个演讲,其中Vaughn Vernon询问了多少人对DDD有所了解,大约一半的观众举起了手。 当我开始为InfoQ编写时,我写了一些关于框架和库的更新,我认为这些功能可能会影响架构,但随着时间的推移,我的写作越来越集中在有趣的博客文章和演示文稿上,只有几个项目关于像Axon,Akka和其他我认为与特定架构密切相关的框架。 在QCon会议期间进行这种讨论会很棒。
InfoQ主编Charles Humble:
我和Vaughn Vernon一起关于Actor 模特 - 并认为它很可能成为主流 - 直接或通过消息传递等方式。在JVM领域,Akka在推广这种方法方面做得很好,基于消息传递的系统长期以来一直是在金融系统中像Actor 一样做事的流行方式。 Actor 似乎很容易被人们掌握和推理,也是处理大规模并行工作的好方法。我希望看到Ponyas周围的势头成为一个现代的,基于Actor 的系统的例子,但我不得不说我认为这不太可能。 关于进化架构,我有兴趣听到马丁福勒去年在播客上谈到这个问题,并且他参加了极端编程。我很期待阅读这本关于Thoughtworks的书。
Thomas Betts,IHS Markit首席软件工程师和InfoQ Architecture Queue负责人:
在很高的层面上,我同意丹尼尔提出的大部分内容。 Jan是正确的,一些架构模式非常适合主题图的自然进展,而其他架构模式可能永远不会超越早期采用者阶段,因为它们不是广泛适用的。 我有时会对A&D与InfoQ上的其他主题之间的重叠感到困惑,尤其是文化与方法。我想是责怪康威定律。关于架构的很多内容都归结为通信 - 进入和离开系统的外部通信点是什么?我的内部服务将如何相互通信?如何保存和访问我的数据? 在许多方面,公司回答这些问题的方式以及他们可以选择的选项将基于他们在A&D和C&M的采用生命周期曲线上的位置。我想说A&D是等式的技术方面,而C&M是非技术性的,但这似乎过于简单化了。此外,技术实现可能会落入开发和/或语言队列中。 A&D处于两者之间的软弱处,处理交叉问题,希望为如何实施该系统提供指导。 我将停止哲学咆哮,并添加一些具体的讨论要点。
我完全支持在QCon上进行这次讨论!
InfoQ编辑团队的建立是通过招聘和培训专家从业者来撰写新闻和文章,并分析当前和未来的趋势。通过编辑页面申请成为编辑,并参与对话。
原文:https://www.infoq.com/articles/architecture-trends-2019
http://pub.intelligentx.net/architecture-and-design-infoq-trends-report-january-2019
讨论:知识星球【数字化和智能转型】