Low-code platforms: a panacea or a risky bet?

Low-code platforms (Low code application platforms, LCAP) arose as a reaction to the complexity and variety of modern software development tools.

According to Gartner, one of the most famous players in this area is Mendix. The sale of Siemens for space $ 700 million confirms this. So I will use this platform as an example, although similar conclusions will be true for Outsystems, Appian, Kony, Betty Blocks and others.

image

So, targeting sales to top managers, vendors of low code platforms promise that even ordinary users will be able to independently create business applications.

That is, developers are no longer needed ?!

Well … after a few years, Mendix is ​​forced to admit:

text
“Now developers need more than ever.”

What a twist!

It seems that Mendix recognized that for something more difficult than basic work with data, a professional developer is still required, just like a professional mechanic is needed to service a car.

Unfortunately, modern low code platforms are simply not designed for developers, and relying on them in the long run is risky for business. If your company is seriously considering the use of low code platforms in industrial operation, it is worth weighing this solution again. Below I will try to argue this.

Great prototyping tool

Mendix is ​​a really great option for automating simple processes or prototyping, available to analysts or advanced users.

The visual editor allows you to describe the data model, quickly create screens using a set of widgets and templates, and even describe the logic using the so-called microflows:

text

Upon completion, you can deploy your application in the Mendix cloud with one click and start working with it. So simple that looks like magic! And it looks like it sells well.

However, after passing through the prototype stage, the interaction of the system with the user and business logic are almost inevitably complicated. To develop the project further, a professional is required. So, let’s look at Mendix through the eyes of a developer.

Slow development

Any logic – be it computing or user interaction – should be described in a microflow flowchart, as shown above.

There are several issues here.

The first is long. Obviously, it’s faster to write 10 lines of code in a good IDE than drag and drop, tweak and join dozens of blocks.

Secondly, readability. Blocks look beautiful, but what does it mean Sub_RegistrationValidation? It is impossible to understand this without falling into the block. As soon as the number of blocks grows to several tens, it will become extremely difficult to understand the logic.

As an alternative for complex cases, Mendix supports Java code calls from microflows. The code can be written in Eclipse, which is generally good, although many would prefer a more popular IDE. The downside is the lack of transparency: all entry points are in microflows, so the logic is scattered between two loosely coupled environments. As a result, debugging and tracking dependencies is difficult.

The last thing I wanted to mention was version control.

The good news is that he is. The bad thing is that it is a stripped-down version of Subversion. Forget about git flow.

Lack of control

Anyone familiar with the Java ecosystem cannot underestimate the power of open source. When an error appears somewhere on the stack, you see in which part of the code this happened. The code can be debugged to understand exactly what is going on. You can google the solution. You can send a pull request. In extreme cases, you can fork the library. You are in full control of the project.

With Mendix, you can forget about it. This is a closed commercial framework, and what is happening inside it is a real black box. All that remains for you is to buy paid support or wait for someone to help on forum with ~ 200 questions per month (compare with the #spring tag on stackoverflow!).

Vendor dependency

Mendix probably quite often reproach this. They even posted article that in fact there is no dependence. If you read between the term, it reads:

You can get your data, DDL, UI resources and code (microflow magically converted to Java code).

Will it be executed or compiled without runtime and API Mendix? Can this be maintained and developed? Questions are rhetorical. In fact, you will need to completely rewrite everything. You depend on a proprietary platform. You do not own the system you created.

Limited scalability

Mendix marketing is focused on the largest companies, so the term “scalability” constantly flashes in marketing materials.
In 2017, Mendix introduced stateless runtime – that is, all session information is either stored on the client side or in a persistent storage.

Theoretically, this means unlimited horizontal scalability. It sounds great, but as usual there is a nuance – the database.

A database almost always turns out to be a bottleneck in a corporate application. So, what does the data store behind many Mendix stateless servers? No surprises – this is a good old relational database. In the cloud Mendix – PostgreSQL. Moreover, the generated Mendix DDL, to put it mildly, is not entirely optimal. For example, I saw an intermediate table that is commonly used to model N: M relationships, created for a 1: N relationship.

The scalability issue could be solved by standard methods: optimizing the database structure, caching, or even using solutions such as Citus. But of course there is no such possibility.

The only way to scale the database is to scale using read replicas (for example, Amazon RDS). But for the record, this will not work.

Summarizing the above, Mendix has a fundamental limitation on scalability and no means to optimize performance.

HR issue

The search for qualified personnel is always a difficult task. It would seem that in this Mendix is ​​the dream of any manager, because the qualification requirements are sharply reduced.

In fact, we have already found out that most projects require a professional team, regardless of the tool. But it’s unlikely that any self-respecting developer will agree to work with Mendix, since this is an obvious dead end in his career.

Prices

Last but not least. Cost licenses for one application starts from $ 1875 per month, subject to a subscription for three years, the license is limited to 50 internal users.

The price of a corporate license with the possibility of local deployment starts at $ 7,825, which is almost $ 100,000 a year.

A medium-sized enterprise with several hundred users will annually pay bills of tens of millions of rubles.

Do not forget that we are talking about relatively simple applications, as you could understand from the above. To me, this is crazy. This pricing model also actually makes it impossible to replicate the applications you created.

Then why are LCAPs still popular?

In my opinion, the reason lies in the disappointment in existing processes. Managing a development team in a large organization — whether it’s an internal team or an outsourcing — is too complicated.

Budget planning, endless coordination, lack of people willing to take responsibility – I think this is familiar to many.
The funny thing is that the first thing that comes to mind when IT projects are moving too slowly is to hire even more developers and, of course, managers. Needless to say, this only worsens the situation. I know a couple of banks with more than 10,000 (!!!) developers, and at least half of them are doing useless work.

In desperation, business leaders are looking for a solution in such “magic wands” as LCAP, supposedly able to solve all problems.

How to get out of this vicious circle is a topic for a separate article. But this is a matter of management, not technology.

Without going into details, if you manage to create a small qualified team of 3-10 people fully involved in the project, with direct contact with the decision maker, you will get excellent results faster and cheaper than you expect.

What are the alternatives?

Now there is a huge selection of tools and frameworks for developers.

For example, the Spring Framework is the most popular open-source technology for creating enterprise software that works well with web frameworks like React or Angular. And tools like Spring initialializr and Jipster, greatly simplified the creation of projects over the past few years.

If you want to get the result faster, you should consider RAD tools such as CUBA Platform.

It is based on the same Spring Framework, complements it with visual development tools and a huge number of off-the-shelf components. Perhaps this is the closest alternative to LCAP, providing flexibility and a comfortable development process.

The final choice should depend on the task, as well as the skills of the team and your preferences.

Conclusion

Low-code platforms are great for prototyping. They narrow the gap between business users and IT, which allows you to quickly get a working prototype and form a vision of the future system.

Since there are very few prototype users, the costs at this stage are also small. And it is at this moment worth stopping!

When using LCAP to develop a complete system, the speed of work will inevitably fall, and you will depend on the expensive proprietary platform that limits you.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *