{{announcement.body}}
{{announcement.title}}

Low-Code and Microservices

DZone 's Guide to

Low-Code and Microservices

Find out the advantages to using a low-code method with Microservices. Some advantages include the speed and simplicity.

· Microservices Zone ·
Free Resource

cat under blankets

Keep the code low and productivity high.
You may also like: Low-Code vs. No-Code: Form Following Function

This article discusses how low-code application development platforms can fit into the increasingly popular microservices architecture style. Rather than discussing the pros/cons of a microservices architecture itself, this article focuses on how low-code could fit into this architecture and complement it to get the best of both worlds.

Putting It in Perspective

Low-Code Development Is Fast

Low-code, in particular, a low-code application development platform, aims to bridge the gap between business and IT while improving agility, productivity, and the overall development experience across the software development lifecycle. Apps and services are not coded but modeled in a uniform visual modeling environment which abstracts away many complexities often encountered with traditional software development.

Low-code also aims to get more people involved in the design and development process through its visual modeling approach, making it also very appealing to tech-savvy ‘citizen developers’ as we enter the digital era. The intent of low-code often gravitates towards smaller departmental- and product-focused solutions and differentiating and innovative solutions on top of core systems providing fit for purpose UI/UX.

Microservices Are Simple

Microservices are services that are simple, lightweight, and loosely coupled to make it easier for individual teams to work on manageable parts within their domain. This domain-driven and autonomous approach to software development also aligns well with process and organizational trends such as DevOps and scaled agile transformations that move organizations towards more autonomous and product-focused teams.

These microservices teams show similarities with the autonomous teams that could model their own departmental- and product-focused low-code solutions and where these two can potentially converge.

Microservice Architectures Are Complex

Although individual microservices are designed to be simple, the complexity increases within the overall architecture and governance required around all these smaller moving parts. For example, microservices should be able to be deployed, monitored, orchestrated, and scaled individually without impacting each other.

Many aspects must be carefully designed to make this architecture meet its true promise of being more productive, flexible, scalable, and resilient. In contrary to low-code solutions converging with microservices from an organizational perspective, the complex microservices architecture itself and the design concerns that it introduces can often not be addressed by low-code teams alone and requires both additional expertise and tooling.

Prepare Yourself for Success

Keep It Simple

When working mostly with citizen developers it is likely better to focus only on the outside edge of a microservices architecture and model apps that provide the UI/UX to end-users. This is a more natural fit for this audience and avoids exposure to the more complex underlying microservices architectural concerns. Expose the integration points with microservices through well-documented APIs to make it easier also for citizen developers to identify and integrate them into their apps.

A low barrier approach towards modeling also the microservices with low-code in is to start with a monolithic design and only gradually decompose it into microservices should the need for it arise later. This often works well when the intent is to try out innovations or to first validate minimum viable products in the field quickly without a need for microservices architecture from the very beginning.

Although modeling microservices with low-code by itself can be simple, this does not make it an architecture yet. It is fine when a microservice is only a part of a single and well-defined solution, however when they are also meant to be re-used by many known and also yet unknown consumers in a true microservices architecture be aware that complexity will increase.

Focus on the User Interaction

Microservice architectures often focus on the backend while the frontends are still being implemented as monoliths towards the outside of the architecture. Low code application development platforms; however, have a strong emphasis on working directly with the business and end-users to also create fit for purpose UI/UX. In addition to modeling the microservices, low-code can also make it easier for teams to model their frontends while depending much less on specialized frontend skills and separate teams.

Understand the Domain

A design thinking approach, for example by customer journey mapping, is one way to identify contact points with end-users that could benefit from microservices in need of UI/UX which makes them very suitable to be modeled using a low-code platform.

Domain-Driven-Design principles can also help to define the scope of microservices and how they should interact to be efficient as standalone services as well as within a true microservices architecture.

Microservices should not only fulfill a single responsibility from a technical perspective but also from a business perspective to avoid business domains are coupled together. It also helps when the organization is already working with scaled agile and separate product teams as this could also help to define certain logical boundaries for microservices already.

Communicate Meaningful Information

Interaction between microservices increases when they share incomplete information which will degrade the performance and reduces loose coupling. Take a customer for example at an internet provider that moves to a new address; should other microservices know about address updates or that the customer is moving?

The first approach might lead to multiple interactions when a microservice needs to know why the address was changed and if any products need to be enabled or disabled. Instead, if you directly communicate that the customer is moving then all the relevant information can already be shared.

It’s About the Entire Software Development Lifecycle

Low-code modeling and microservice architectures both aim to improve agility in software development. A true microservice has its independent lifecycle and with many of them, they will need to depend on automation such as CI/CD pipelines and container orchestration platforms to remain agile.

Therefore, it is also important to look at the maturity level of agile teams and their ability to apply DevOps practices successfully. Low-code application development platforms often provide monitoring and out of the box CI/CD pipelines to address part of the technical aspects, but the organizational and human aspects can’t be solved by any platform alone.


Further Reading

5 Myths About Low-Code

Low-Code — Implications for Developers

Understand No-Code and Low-Code Application Development Tools

Topics:
microservice ,low-code ,best practices ,architechture

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}