The lowdown on low code and no code in the cloud

If I get one question lately, it’s about using low-code and no-code platforms as part of a cloud solution, typically for fast application development. Here’s my attempt to put this into perspective for everyone out there building cloud solutions or considering low-code and no-code platforms, inside and outside of public clouds.

First, what the heck is it?

Martin Heller has one of the more logical explanations of the concepts and platforms that support the concepts. I can’t improve on his article, so in his words:

“In general, a low-code development platform offers a drag-and-drop designer, modules, forms, processes, workflows, data models, integrations, and one or more programming languages that you can use within the product. The development platform may emit a specification that an engine can use to create an app or emit a runnable app. The app may or may not interact with the platform’s back end.”

The idea is to remove as much programming as you can, but not altogether. This means that developers can build solutions fast but still can code around any limitations that the low-code platform has. For example, building an inventory process monitor using a low-code or no-code platform means leveraging their interface (drag and drop) instead of traditional coding. 

However, as you may have guessed, graphical interfaces that allow you to program by drawing diagrams will eventually run into something that they can’t do. You may have to drop down to some native coding to access a complex API to get at status data within the low-code application.

In other words, we can get most of the way there without programming code. However, some programming will be likely needed in most cases since this is the real world and all.

No-code development is low-code development without a programming language built in. Seems like it would be more freeing since we no longer must deal with syntax and compilers errors. Right? Not really.

No-code platforms, as Heller outlines, are easy to use for simple applications but tend to hit limits that bring no-code “developers” to a standstill. Much like the low-code example above, when we must do something at the operating system or cloud-native levels, there is no easy way without some sort of programming engine.

No-code platforms attempt to solve this by offering more modules to access the needed functionality without coding, for example, a custom module for obtaining the correct time and temperature for a specific city when a zip code is submitted to it. Most even provide SDKs to create your own modules for the no-code platform. However, that’s requires coding, does it not?

I’m not sure I see anything game-changing here, but I understand why some enterprises will find both low-code and no-code development useful. As somebody who does not code that often but still wants the ability to build small and useful applications, I see the utility of a tool that requires no or very little coding for the few times that I need to program.

No-code and low-code platforms do have good points, especially for use cases where those who have no coding skills want to build simple solutions themselves without having to rely on developers. I think this is something we need today. There is a growing movement to democratize solution development, inside and outside of cloud platforms.

What scares me about the use of low-code platforms is that enterprises won’t place the proper governance, resource-access restrictions, and security limitations to protect the resources that these low-code/no-code platforms will need to access, such as databases, storage, compute, and application interfaces.

I suspect that we’ll see access configurations botched in such a way that data will be inadvertently deleted, overwritten, or compromised. Not because those leveraging these low- and no-code solutions had ill intent—they just did not know any better.

In the past, we could rely somewhat on the knowledge of developers to keep us out of trouble if security and governance layers were somehow misconfigured. In the case of allowing anyone to access these resources with misconfigured privileges, all bets are off. They are going to find a way to screw things up, yet it’s not their fault since we gave them the ability to do it by using no code. 

The point is not to push back on low-code and no-code platforms; they have their place. I’m just asserting that they need a bulletproof infrastructure, data, process governance, and security system in place that understands that the masses will now have access. 

Assuring that this is the case, you’re all set. However, I see many still lacking the proper forethought in terms of dealing with access rights. You’re going to have to fix that first before going to low or no code. Just saying.