px;color: rgb(74, 74, 74);">
有一个话题总能激发有益的讨论，那就是 Serverless。InfoQ 的编辑们认为 Serverless 还没有跨越鸿沟，而且这个想法也遇到了一些反对的声音。这与对微服务的反对有关，因为越来越多的团队意识到，Serverless 和微服务架构并不是所有问题的正确解决方案。这引发了对正确构建分布式系统和模块化单体的讨论。
Jan Stenberg 观察到在最近的 DDD 欧洲会议上讨论了 Serverless 和分布式系统：
Stenberg：对我来说，很有趣的一点在于 Gojko Adzic 非常热情地 谈到了 Serverless，但是他指出，即便是一个非常简单的“Hello World”应用也是高度分布式的。这需要非常专业开发人员，这会影响到 Serverless 的成本效益吗？
Vladik Khononov 推荐阅读 组合 / 结构化设计，这是 Glenford J. Myers 在上世纪 70 年代所写的，适用于每个对微服务感兴趣的人。他说，尽管这本书没有提到微服务这个术语，但是书中讨论的基本设计理念是与微服务相同的。
Stenberg 还认为模块化单体应该添加到早期采用者中：
Stenberg：请参考 Kamil Grzybek、Randy Shoup 以及其他人的观点，另外还有 Stefan Tilkov 早在 2015 年就声称构建模块化单体非常困难，如果需要的话，推荐直接采用微服务。
但是，这有点奇怪。构建设计良好的模块化应用程序怎么会成为早期采用者呢？有没有“新一代”的早期采用者?
Humble：我并不认为 Serverless 已经跨越了鸿沟，实际上我听到了一些反对它的声音。从大处着眼，我认为这是对微服务的反对（或者，更精确的说，人们意识到微服务并不是所有问题的答案），我们在 QCon 伦敦上针对这个话题有个讨论。我认为这还是一种有利的方式。我们应该跟踪或者讨论重回单体的方式吗？有待进一步探讨。
Bryant：我最初确实想知道 Serverless 是否已经跨越了鸿沟，但是我现在认为它并没有。有大量的报告（样例）指出这个领域有巨大的增长机会，这也让我认为它依然处于早期采用者状态。
Betts：一年前，人们还在谈论构建完全 Serverless 的系统，现在这种炒作已经减弱了。单独的 Serverless 特性，如 AWS Lambda 或 Azure Functions，可能已经跨过了鸿沟，但是完全的 Serverless 架构还没有，甚至可能永远不会被大面积采用。
Low-code 和 no-code 方案承诺将更多的功能交付给最终用户，并且不需要开发人员参与。虽然业界资深人士可能会对厂商的背后推动力表示怀疑，但使用这些平台进行试验的开发人员已经明显增多。
Humble：我对 low-code 平台持怀疑态度，我认为和以往我看到的东西一样，这是厂商的另一波推广。我希望看到更多的开发人员尝试 low-code 平台，这很大程度上是微软对其 PowerApps、Flow、Power BI 和 Power Platform 产品的新一轮推广。我还发现 谷歌收购 AppSheet 是一件很有意思的事情。这些平台正在成为很大的一项事业，我认为这是应该关注的一个趋势。
Betts：（轻量级）工作流和决策自动化平台应该依然处于早期采用者阶段。这与 low-code/no-code 有很强的相关性，对于概览图来说，这可能是更全面的一个术语。这些平台的目标是非开发者，因此它们属于购买而不是构建的范畴。它的挑战在于集成，而不是在某个平台上构建主要的系统。
Stenberg：Low code 让我想起了年轻的同事，他们在 90 年代的大学里只学习第四代编程语言，因为面向对象已经过时了。
我并不认为现代工作流引擎（如 Zebee）属于 low code，（但是它们可能属于“工作流和决策自动化平台”）。它们处理核心业务工作流，我需要知道在这些地方核心业务正在平稳运行，而不用通过监控发现问题。
很明显，GraphQL 已经跨越了鸿沟，但是 InfoQ 编辑们的问题是它属于早期大众还是晚期大众。虽然 GraphQL 作为一项技术可能已经达到了晚期大众阶段，但是我们仍然可以看到在可扩展性和跨系统创建内聚的语言方面，GraphQL 的创新依然在影响着架构决策。
Humble：我认为 GraphQL 肯定已经跨过了鸿沟。Dylan 在最新的 Web 趋势报告 中将其列到了晚期大众阶段。
Betts：我认为 GraphQL 已经跨越了鸿沟。它的采用程度已经使其从单纯地实现 API 层，变成了系统设计的核心。这与 TypeScript 的采用情况非常类似，大众已经认识到在整个系统中采用强类型构造的好处。
Bryant 提出了一个问题，我们是否应该在这条话题中跟踪道德准则。“我越来越多地看到在 SACON 和 QCon 上关于伦理的演讲和话题。”我们最终决定不在生命周期概览图中包含道德规范，而将其包含到文化与方法的概览中。
Humble 提到了 QCon 和 InfoQ 几年来一直是如何讨论道德规范的：
Humble：我认为我们倾向于将道德作为一个文化话题，但这是一件临时插入的话题。我们绝对应该继续跟踪这一话题并就此进行报道。我很自豪我们在 QCon 伦敦 和相关的 eMag 上涵盖了这一点，我认为考虑到软件在每个人生活中的普及程度，继续讨论它是非常重要的。
Betts 将道德视为架构师作为技术领导者的一个重要方面：
Betts：虽然我很赞赏人们对道德的关注和讨论，但我不确定道德是否应该出现在本概览图上。但是，我认为技术领导者必须考虑道德规范的许多方面，我希望能够在 InfoQ 的架构与设计栏目中看到道德规范方面的文章。我始终认为，在这一领域提供指导的人是真正理解这一领域的实践者。如果没有积极主动的领导，设计最终将是被动的，并且会被迫遵守不可避免的政府规定，如 GDPR 和 CCPA。
概览图的其余部分基本没有变化。反应式编程、HTTP/2 和 gRPC 已经跨越了鸿沟，其他项目都没有变化。这恰好也是架构与设计领域所期望的，因为与编程语言趋势相比，好的思想需要时间成长和更长的生命周期。
上一篇：区块链丨构建网上远程考试信任机制
下一篇：普华永道：“宅经济”将加速线上食杂零售的增长和上游现代化
