在微服务中使用低代码方法的优势

本文讨论了低代码应用程序开发平台如何适应日益流行的微服务架构风格。本文不讨论微服务架构本身的优缺点,而是重点讨论低代码如何适应这种架构并对其进行补充以实现两全其美。

低代码开发速度快

低代码,特别是低代码应用程序开发平台,旨在弥合业务和 IT 之间的差距,同时提高敏捷性、生产力和整个软件开发生命周期的整体开发体验。应用程序和服务不是编码的,而是在统一的可视化建模环境中建模的,该环境抽象了传统软件开发中经常遇到的许多复杂性。

Low-code 还旨在通过其可视化建模方法让更多人参与到设计和开发过程中,使其在我们进入数字时代时对精通技术的“平民开发者”也非常有吸引力。低代码的意图通常倾向于较小的以部门和产品为中心的解决方案以及核心系统之上的差异化和创新解决方案,以提供适合用途的UI/UX。

微服务很简单

微服务是简单、轻量且松散耦合的服务,使各个团队可以更轻松地处理其域内的可管理部分。这种领域驱动和自主的软件开发方法也非常符合流程和组织趋势,例如 DevOps 和规模化敏捷转型,这些趋势使组织转向更加自主和以产品为中心的团队。

这些微服务团队与自治团队表现出相似之处,自治团队可以为自己的以部门和产品为中心的低代码解决方案建模,并且这两者可能会融合。

微服务架构很复杂

尽管单个微服务设计得非常简单,但围绕所有这些较小的移动部件所需的整体架构和治理中的复杂性却在增加。例如,微服务应该能够单独部署、监控、编排和扩展,而不会相互影响。

许多方面必须经过精心设计,才能使该架构满足其真正的承诺,即提高生产力、灵活性、可扩展性和弹性。与从组织角度与微服务融合的低代码解决方案相反,复杂的微服务架构本身及其引入的设计问题通常无法由低代码团队单独解决,并且需要额外的专业知识和工具。

把事情简单化

当主要与平民开发人员合作时,最好只关注微服务架构的外部边缘,以及为最终用户提供 UI/UX 的模型应用程序。这更适合这些受众,并避免接触更复杂的底层微服务架构问题。通过记录良好的 API 公开与微服务的集成点,使平民开发人员也可以更轻松地识别它们并将其集成到他们的应用程序中。

对具有低代码的微服务进行建模的一种低障碍方法是从整体设计开始,只有在以后需要时才逐渐将其分解为微服务。当目的是尝试创新或首先在现场快速验证最小可行产品而无需从一开始就需要微服务架构时,这通常很有效。

虽然用低代码建模微服务本身可能很简单,但这还不能使它成为一种架构。当微服务只是单个且定义明确的解决方案的一部分时,这很好,但是当它们也意味着在真正的微服务架构中被许多已知和未知的消费者重用时,请注意复杂性会增加。

专注于用户交互

微服务架构通常专注于后端,而前端仍然作为面向架构外部的单体实现。低代码应用开发平台;但是,非常强调直接与业务和最终用户合作,以​​创建适合目的的 UI/UX。除了对微服务进行建模之外,低代码还可以让团队更轻松地对其前端进行建模,同时减少对专业前端技能和独立团队的依赖。

了解域

设计思维方法,例如通过客户旅程映射,是一种识别与最终用户接触点的方法,这些接触点可以从需要 UI/UX 的微服务中受益,这使得它们非常适合使用低代码平台进行建模。

领域驱动设计原则还可以帮助定义微服务的范围,以及它们应该如何作为独立服务以及在真正的微服务架构中高效交互。

微服务不仅要从技术角度履行单一职责,还要从业务角度考虑,避免业务领域耦合在一起。当组织已经在与规模化的敏捷和独立的产品团队合作时,它也有帮助,因为这也有助于为微服务定义某些逻辑边界。

传达有意义的信息

当微服务共享不完整的信息时,它们之间的交互会增加,这会降低性能并减少松散耦合。以移动到新地址的互联网提供商的客户为例;其他微服务是否应该知道地址更新或客户正在移动?

当微服务需要知道地址更改的原因以及是否需要启用或禁用任何产品时,第一种方法可能会导致多次交互。相反,如果您直接传达客户正在搬家,那么所有相关信息都可以共享。

这是关于整个软件开发生命周期

低代码建模和微服务架构都旨在提高软件开发的敏捷性。一个真正的微服务有其独立的生命周期,并且其中许多都需要依赖自动化,例如 CI/CD 管道和容器编排平台来保持敏捷。

因此,查看敏捷团队的成熟度以及他们成功应用 DevOps 实践的能力也很重要。低代码应用程序开发平台通常提供监控和开箱即用的 CI/CD 管道来解决部分技术方面的问题,但组织和人员方面的问题仅靠任何平台都无法解决。

阅读推荐:低代码开发平台早已变成ICT行业最大的风口