To Code or Low Code, that is A Question.
Once I understand a client's business integration requirements, one of the first questions I ask is whether to use a Low Code solution or a programming language.
I should define what I mean by a Low Code solution. Over the last decade, there has been a proliferation of applications that help you build integrations between SaaS applications. These are known as integration-platform-as-a-service or iPaaS providers (no pun intended, Illinois Tollway). A few I'm familiar with and have used are:
There are many others. What most have in common are:
- They support a list of applications that you can connect with.
- Within each application, you can perform different actions. For example: trigger something to happen when a lead is created; lookup a customer; create a contact; update an order.
- They provide a user-interface for assembling these actions into a workflow. There are different names for these workflows in each app: in Zapier, it's called a Zap, in Make, it's called a Scenario, in Workato, a Recipe, etc.
- When you activate the workflow, your data begins flowing across. Usually, you can track its activity (including any errors that occur).
You can do all of this without having to write a single line of code in a programming language.
It sounds great, but of course, you do have to pay for all this. Most iPaaS providers have an entry-level plan that costs very little. However, these plans typically are intentionally throttled down in three ways. They either:
- limit the number of transactions (workflow runs) you're allowed to perform per month, or
- limit the number of actions (steps in a workflow) you're allowed to perform, or
- limit the kinds of applications you can choose from to build workflows (e.g. "you can only use Salesforce actions if you're on our Premium Plan")
Depending on your scenario, it's likely the low-code approach is going to cost you in the neighborhood of at least $20/month.
Some of you might wonder I'm not calling these iPaaS solutions "no code" (another buzzword) if you don't have to write any code? I still call it Low Code because whoever is doing the building is still programming. You're still responsible for assembling a set of instructions to push data between applications; and that still requires knowledge of low level data and a degree of technical experience. In other words, if you need to maintain and support this yourself, you'll need at least someone on staff with technical skills.
Let's leave that point for moment, and ask, why would I write an integration solution with code?
Code (i.e. writing instructions in a programming language) is far more expressive and succinct than a UI based solution. You have the full power of a language at your disposal instead of a few vendor-specific out-of the box "actions".
Once deployed, code is almost always more efficient. That may not matter if you're running a few dozen transactions a week, but it's a different story as your transaction volume increases.
Of course, code does need to "run somewhere", which means you're faced with the other choices... On a server in your data center? AWS? Azure? GCP? Alibaba? The good thing is that if you use a mainstream language like NodeJS, Python, Java or C#, the answer is that it probably doesn't matter that much. All these cloud platforms can run code. Sure there are some vendor-specific considerations with "how to deploy", but if you're clever, you can minimize the cloud-vendor-dependent lines of code, and your integration business logic should be quite portable.
Once code is deployed and running, I have found that the cost to keep code running is definitely cheaper than the Low Code approach. Why? Most Cloud providers (where you host code) now have Serverless computing options. What this means to the business owner considering an integration is that they no longer have to pay to keep a server running 24/7/365 to host code; they only pay for a few seconds or minutes a month that integration code actually runs. For example, a NodeJS Lambda function that syncs contact information from Salesforce to Autotask at a data volume of 500 contacts a week falls well within the AWS Lambda free tier (the first million Lambda function i.e. code invocations are free).
The downside with the code approach is that if the business owners plans on maintaining and supporting the application, they'll need to have staff expertise with code skills.
But which approach is easier to understand? I've gotten this question a lot, but most people already know the answer. It depends on who has to do the maintenance. A lot of people have it in their head that they "can't understand" programming if they were presented with it. However, is the person in question the one that actually has to maintain a workflow solution? Are they any more likely to understand a comparable Zap or Make Scenario? Maybe. If it's a very simple workflow such as a one-way contact sync, Low Code probably wins. However, the more complex the workflow becomes, the more likely a code-based solution is actually easier to understand. I've seen some pretty incomprehensible, kludgy Low Code workflows and they're just as obscure as poorly-written code.
So, let's compare Low Code vs Code
| factor | Code | Low Code |
|---|---|---|
| skills needed to build, maintain | Developer with knowledge of programming language. | Technical resource with knowledge of iPaaS tool. |
| simplicity | Eye of the beholder | Eye of the beholder |
| portability | Some cloud platform vendor-specific code may need to be rewritten, however your core scenario will still run if written in a mainstream programming language. | Not portable. If iPaaS goes out of business, you'll need to reimplement your scenario. |
| cost to build | Slightly higher. When done right, it does involve some amount of bootstrapping (repository set up, initial cloud platform provisioning, etc./). | Slightly lower. Generally low-code solutions require a little less time to build. However, this advantage dwindles with increasing workflow complexity. |
| cost to run | Very Low. Doesn't very much among Cloud platforms. They are all very inexpensive. | Varies based on iPaaS vendor. |
| maintainenance considerations | Code libraries should be updated monthly with security updates. Deprecated libraries should be replaced or removed. Workflow updates are required when APIs change (infrequent, but possible). | Your iPaaS fee should be taking care of code/security patches on the iPaaS platform. However, API changes (infrequent, but possible) still will likely require workflow changes. |
| vendor lock-in? | Code is portable, but effort is needed to adopt another Cloud provider. | Locked in to iPaaS vendor. |
In conclusion, there isn't a clear winner; but here are some rules of thumb:
- If you have limited staff, but don't want to outsource your integration to a 3rd party, try a Low Code approach first.
- If you think your integration will have high data volume (thousands of transactions per week), consider a Code solution first.
- Otherwise, reach out to an integrator or developer that you trust in your network (including us!) for a suggestion.