Problem solve Get help with specific problems with your technologies, process and projects.

Fight microservices complexity with low-code development

Software developers are in a constant battle with complexity. Microservices hold promise as ready-to-assemble app components, but low-code development might be a better approach.

Microservices converts large monolithic applications into modular components that serve specific tasks and make it easier to test and deploy changes. This architecture decentralizes, and ideally simplifies, software development.

Nevertheless, microservices complexity persists. In theory, we can stitch microservices together with a top layer, assembling applications out of components. The promise isn't new, but it is worth examining.

Ivar Jacobson proposed the idea of software components, like circuit-board components, in 1967. He wanted to build software from prefabricated blocks of code rather than create everything from scratch. Yet, something happens every time we get close to Jacobson's component dream: The components require new layers of complexity. In microservices, this means additional programming to ensure uptime, reliability and observability. We aim for easy-to-assemble building blocks, but end up with a great deal of code.

One emerging alternative that knocks out the microservices complexity problem is low-code development, with minimal conventional programming. In some ways, microservices and low-code development solve similar problems. Like microservices, low-code development platforms emerged as a way to build apps with out-of-the-box, standardized components. Low-code does not provide the development sophistication of microservices. It can, however, work in situations where managing microservices leads to more effort than the benefit promised by that architecture.

Once software developers and architects understand microservices complexity issues from code builds to application uptime, they can determine how and when to use low-code development.

Microservices' code, resiliency and uptime problems

Microservices independently communicate with one another over internet standards, which is what makes the architecture powerful. Because they speak TCP/IP and deliver data payloads in JSON, the components work together without dependencies. These small services each perform one task well. A company can have a set of services for customer information, another for product lookup, a third for orders and a fourth for delivery.

But breaking things down along business functions means there's a lot of code to manage. When something goes wrong, application teams require specialized observability tools that trace the entire chain of events to debug. Microservices requires logging and monitoring work that exists outside the idea of simple components. That creates an explosion of code just to make the app code work.

When something goes wrong, figuring out which component contributed to the issue can be tricky without the right tools -- which, again, means more code. While each service has high uptime in this supported deployment, resilience and reliability at the code level start to crumble.

Monolithic versus microservices architectures
The difference between monolithic and microservices design

The low-code alternative

A low-code development platform builds and delivers the components of an application.

The developers, or even business unit representatives, provide the variables, database connection, formatting and styling, and the tool generates the application, sometimes via a drag-and-drop UI. Provide the data, and a low-code development platform can even build a database. This is, in effect, the opposite approach to microservices, where you provide the database, abstract it into a service, and code the service logic.

Low-code development platforms generally reuse a great deal of common code. There is a massive reduction in lines of code, perhaps even hundreds to one, compared to conventional programming. There are also fewer independent components, which are tightly coupled to each other. Each line of code becomes more powerful and traceable.

A simple example of a low-code development platform is a database with a Create, Read, Update and Delete (CRUD) front end. A programmer sketches out the table visually and fills in data through a simple spreadsheet. Users access the data through the CRUD front end, which lives in an application that the platform generates, and can be downloaded from an app store.

Benefits and limitations of low-code for microservices

A low-code platform takes care of nearly everything that conventionally is coded for an application. Most of the low-level programming and integration work is taken care of via tool configurations, which saves developers a lot of time and headaches. However, think carefully about where you apply low-code in a microservices architecture.

As long as the app is simple, clean and doesn't require many integration points, low-code development might be the right alternative to more manual and complex microservices projects. Low-code builds are an easy choice for applications that don't need to integrate with other databases or only rely on a series of small tables. Short-lived conference apps or marketing promotions that run with user ID information are good examples of this.

However, a low-code approach does not replace large-scale microservices development. Once you need to share information between applications in real time, the tools and programming techniques involved become much more sophisticated. While the low-code approach helps developers steer clear of over-engineering apps that don't need it, low-code likely won't provide the database integration, messaging or customization capabilities needed for an enterprise-level microservices architecture.

Next Steps

Dig into two enterprise-grade low-code case studies

Dig Deeper on Application development planning