Part 1 of this series explored how the answer to increased developer productivity shouldn’t be the extreme of black boxes, but a low-code solution that’s an “open box”—based on open standards and with a full view of the source. In Part 2, we’ll examine the development architecture in the context of low-code solutions.
Low-code solutions not only suffer from the “black box” perception of difficult or impossible customization, developers also cast a jaundiced eye on their architectures—antiquated, monolithic, and unfriendly to application deployment.
From a development standpoint, the advantages of monolithic architectures, where all the application logic and code reside in large and interdependent components, include being simple to develop and to deploy—at least initially. However, in the long run these advantages are outweighed by the disadvantages. Monolithic app services tend to be “tightly coupled,” making it difficult to isolate services for purposes such as independent scaling or code maintenance. If any program component needs to be updated, this often requires large portions of the application to be rewritten.
That, in turn, raises the specter of refactoring to improve performance, readability, portability or code adherence. A monolithic approach immediately puts you on a refactor course or dealing with bolt-on alternatives often provided by the software developer that try to add modern functionality to a dated architecture—but end up creating a second tier of apps.
Monolithic architectures common to many low-code solutions are much more difficult to understand, because there can be dependencies that aren’t apparent when looking at an individual service or controller since they’re baked into the solution. With many low-code solutions, you’re saddled with trying to manage the development, testing and production work for a monolith, minus the ability to develop, test, deploy and scale components individually. Scaling is challenging because you can’t identify and break out specific poor performing pieces to optimize them, and maintenance is a chore because while a monolith has fewer “moving pieces,” they’re hard to maintain because those pieces are all tightly coupled.
Developers are aware of these limitations and try to avoid them.
The ideal would be to have the cloud capabilities provided by the likes of AWS or Azure at your disposal, combined with the ease of low-code deployment.
The result is developers are freed to focus on app capabilities and user experience, while the platform manages the rest.
Traditional low-code vendors offering monolithic platforms are being disrupted by high productivity platforms designed to be cloud-native and standards-based with support for a serverless backend and microservices.
One of those disruptive high-productivity platforms is Progress Kinvey.
A modern serverless architecture married to the highest levels of developer control—that’s the answer to meeting the never-ending demand for consumer-grade multichannel applications.
Mark Schafron is a Senior Copywriter for Progress and a business journalist, with 20+ years experience crafting messaging across topics including software development, cloud, security, big data and CAD/CAM/CAE, among others. He’s also a voice actor known for his ability to write and narrate complex technical scripts.
Subscribe to get all the news, info and tutorials you need to build better business apps and sites
Copyright © 2019 Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, Ipswitch, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.