One of the most important lessons I'd learned from working with Azure, over the last year or so, is that careful thought should be given to whether it's better to implement a service as a 'low code' solution, or as conventionally-developed software. The former isn't always the fastest, cheapest or more efficient way to get something deployed.
I'm currently of the opinion that Azure's Logic App system is quite good for integrations and basic scheduled tasks - and it has indeed made those kind of things easier to manage - and there aren't any convoluted deployment pipelines to bother with. Azure mostly does what we need it to do. However, I do think ‘low code’ solutions are sometimes the wrong tools for the job, and getting something to work that way can prove far more costly and time consuming than conventional approaches.
Azure resource limits
On one mild October evening, I was initially feeling somewhat pleased with myself for having put together a couple of Logic Apps, with a ton of C# and LINQ code for the heavy lifting, that essentially reads a load of data from multiple APIs and merges that data with a few template HTML files to generate the site. Storage Account containers can function as Web servers, it turned out. The whole thing worked perfectly fine in the staging environment with test data.
I ran into a couple of serious problems, though, after replicating it to a production environment and running it with production data. The Logic App was unable to buffer the data (about 90MB of JSON), and, when it could buffer the data (which needed to be paged into multiple buffers), it would take more than a day to generate the site.
As a quick workaround, I created another site generator as a .NET console application, and the strange thing is it processed the same amount of data and generated the site within minutes, on a mid-spec laptop. Why couldn’t we run that as a scheduled task that would output the files to an IIS directory on one of our ancient on-premise servers? Actually, why not scrap the Logic Apps and just develop the site as a conventional MVC application, which would be much quicker, cheaper and more efficient?
Learning curve
Something we encounter with 'low code' platforms in general - not just Azure - is that developers struggle with the abstraction and its limitations, while non-developers seem to get on better with them. I think it's largely because Logic Apps are procedural, and because experienced developers are in the habit of being precise about how a given problem should be solved, and of expressing the solution elegantly as code. Also, we’re in the habit of thinking about edge cases - the things not explicitly covered by software requirements.
Aside from that, there are a large number of services and components available in Azure, and it can host 'microservices', SSIS-like integrations, databases, .NET APIs, key vaults, file storage, Web servers, and even MVC applications. But typically we can’t just use a Logic App, or whatever. It needs other components as dependencies, such as Function Apps and Key Vaults, and it turns out that there’s so much that needs to be in place, and provisioned by whoever manages the Azure subscription, before any development can begin. A developer needs to become a sort of expert in Azure.
The term 'low code' can be deceiving
We initially think of Logic Apps as 'low code' primarily because of the Logic App Designer, which is a graphical representation of all the Azure 'microservice' components that are behind our services. The Logic App Designer, though, is an abstraction of a large JSON configuration file, and there have been many occasions where I've needed to work with that instead. For example, copying the JSON from a staging Resource Group to a production one will entail changing all the dependency references within it.
Most Logic Apps I've encountered are dependent on at least one Function App, which enables the developer to add custom operations that ‘low code’ can’t do. For example, evaluate the contents of a Storage Account, or perform a String.Replace() on a template file passed to a Logic App step as a string.
What commonly happens, though, if the Logic App method is being pushed onto developers as the less-than-ideal way of developing an application, is Function Apps contain huge amounts of C# that isn’t well engineered and isn’t easy to test.
Replication and backup
Some types of Azure services can host .NET MVC and console apps, and have deployment slots for staging and production versions of whatever's being deployed, and applications can be pushed to whichever slot directly from a local installation of Visual Studio. Source control obviously isn't a problem in that case. I do like this way of deploying software.
Logic Apps are a different matter. I haven't found an easy way of replicating them, and all their dependencies, in a situation where two Resource Groups are being used as staging and production environments.
Same with source control: I do encourage colleagues to back up everything in the Resource Groups we’re working on, and any subsequent changes to them. I’ve decided on my own method of doing that, which still involves a lot of copying and pasting into a file structure that forms our repos.
Security
This is an entire subject area in itself. Whether the security configuration is a problem will depend on whether the provisioning, security and other DevOps-related aspects are handled outside the development team. If that is the case, the developer will need a clear understanding of everything needed for the service to work, such as dependencies, App Registrations, Managed Identities, permissions for Key Vault and storage account access, firewall configurations, etc. That would require a very specific design document and probably a documented and repeatable procedure for provisioning the resources.
Dependence on legacy software is a fact of life
I'm not too sure about the future of 'low code' - the IT industry tends towards maintaining things in-house and on-premise, but every decade or so, the industry goes through a phase of outsourcing things as third-party managed services. A few companies cashing in on that trend do well, some get bought up, and others go bust.
Because legacy systems are a fact of life, and often for very good reasons, the third-party-solutions-as-a-service trend does worry me, especially when it involves vendors I hadn’t heard of before. It’s a tendency that seems to permeate everything today, with third-party services for everything from Software Defined Networking to systems integration. How many of those vendors are going to be around in ~15 years? What happens when several of the lesser-known ‘low code’ vendors - which clients might have outsourced their critical assets to - go out of business, or are bought out by corporations and eventually morph into something different?