Using Node-Red for Enterprise Software

Hi,

Interested to know of any real world examples of people / firms using NR as the backbone to their No/Low Code Platform?

This space is very thematic at the moment and a number of firms (e.g. n8n, Tray) have gone down a path of building from scratch whereas an alternative approach (I think) would be to use NR.

Keen on examples of just general thoughts on this.

MD

Did you tak a look thru the Industrial section of the forum?

Hi, yes I did have a browse, that is focusing on use of NR with industrial hardware from what I could see.

What I am more interested in is the application of NR into existing Enterprise Software e.g. CRM, HR, Compliance ... (if such examples even exist)

Ouch - tray.io is seriously broken. Won't even open on my laptop. Won't be going back there - ever.

I've not seen any such examples myself. I'd also be interested though. However, Node-RED is not currently a good fit for enterprise integration for a number of reasons.

Note, this is not a criticism of a tool that I love, merely an observation based on many years of experience.

  • It is hard to include open source in enterprise applications - too many commercial interests at work and commercial/finance processes that are too inflexible (sometimes for good reasons, other times not). I've been working on this for years and even in the NHS which has had open policies in place for many years, open source is only really just beginning to get a decent foothold.
  • It is hard to persuade enterprise vendors to use a platform like node.js, particularly on complex tools such as CRM's and HR systems
  • For whatever reason, there aren't many enterprise data-focused tools for Node-RED. Nor for Node.js/JavaScript in general. Lots of reasons for this. Python is better served there, at least in part because of its early focus on integration with older, high-performance libraries via Fortran, C, etc. While Node.js probably could compete in that area now, it took a different path and attracted developers with a different background.
  • Big tools are build using big frameworks like .NET, this isn't always an easy fit along side the microservice architecture that node.js is so good at. Not a blocker, just some extra friction that causes vendors to look elsewhere quite often.

I'm sure there are many other reasons, that is just a couple that came to mind quickly.

None of this prevents Node-RED from competing in this area at all. But it would require vendors and developers prepared to invest. That hasn't really happened so far, hopefully it will happen in the future. But the barrier is quite high.

Take a simple example. Let's say you want to do a statistical analysis of tabular data. An extremely common requirement in enterprise processing. What node.js library or framework would you choose to help you? Python has some industry leading libraries and frameworks to support this, node.js does not. And yes, I've looked at this specific example extensively recently. So much so, that it was quicker for me to grab Python via Anaconda and learn the processing tools than it was to try and get one of the node.js libraries to actually work. Even though I know node.js well and my Python is very rusty indeed. In fact, it was easier to fall back to using Excel with PowerQuery again than bother with either language for what I needed to do in the end. On a related set of data, we hired a data architect with R skills to build a Machine Learning model to get the job done (after all, I am not a data analyst).

I'd love to see more done in this area in Node-RED so that it was more suited to doing larger-scale data processing.

1 Like

Hi,

We use (and contribute to) Node-RED extensively as a Low-Code platform. This includes test automation (UI & API testing) as well as RPA tasks. We run 1.2 million transactions a year via Node-RED events / tasks. It has served us extremely well. This is a team of 12 people full-time plus as many others as I can get to follow us.

We find it very stable, quite performant, and easy enough for people to learn without significant programming backgrounds. As far as integration: that is one of Node-RED's strong suites: we connect to MANY data sources (Oracle, MySQL, Mongo DB, SnowFlake and others) and use it as 'IT glue' to connect disparate systems together. It is like an ESB but way more powerful and simpler to use.

I have replaced a toolset that cost $80K / year with one that costs $0. Yes, we give back to this community and will continue to do so.

Through the use of multiple Subflows we've been able to customize the UI into a Test Engineers workbench that meets our needs.

I will tell you that flow-based programming takes a little work to learn (thinking differently) but the rewards are great.

The output from Node-RED test runs directly affects compliance verification for us - reading statements from our website and confirming the correct verbiage is present. Also running ~ 100,000 compliance transactions for our legal team: reporting and updating transactions.

Generally, I've been thrilled at what we can do with it.

As far as 'hard to persuade enterprise vendors to use a platform like node.js' I think you're missing something: it is often development teams that lead the way followed by business partners recognizing velocity and jumping on board. Perhaps writing an entire CRM from scratch might be different due to node.js and have a different 'feel' (especially areas like security profiles etc.) but generally code is code. I have a feeling that many closed-source applications (even complex ones like you describe) are primarily written with supporting open-source or nominal-cost tools.

Microservices as a pattern is good. Similar patterns exist with many other languages.

Choosing the correct tool for the job (as you allude to) is part of being a craftsman. People learn and interact with code in many different ways - and that includes from a development viewpoint as well as the end users. Many people appreciate the visual aspects of Node-RED but still I see some people that use Node-RED for orchestration and have hundreds of lines of JavaScript or other languages inside Function nodes.

Anyway, feel free to PM me if you want more information about our use cases.

Cheers,

Paul

Cheers,

Paul

4 Likes

Nice to be proven wrong in my assessment. Of course, I can only go by my own experiences. I am an architect rather than a developer as a professional so my views may be somewhat different.

Unfortunately, nearly all of our business development is done using .net and the developers aren't yet ready to include microservice architectures into the mix. One day hopefully. I'm working on it. It tends to be either/or rather than both.

As for enterprise integration, we are generally forced to use big vendors to support us and they again don't tend to be amenable to microservice architecture integration annoyingly. Low-code solutions end up using something like PowerApps from Microsoft.

Actually what would really help move forward enterprise use of Node-RED would be more public articles explaining the use and architectures of Node-RED integration in an enterprise environment. That is something that is seriously missing.

I'm aware that more enterprises and vendors are using Node-RED but there seems to be little public exposure of that. Much of my time as an architect is spend convincing people to use the right tools and standards and that is limited if I cannot point at credible examples from other organisations.

How do you ensure that your flows are robust and meet your SLA's and non-functional requirements for example? How do you manage scalability? DevOps and CI integration? Backup and recovery?

These things are well documented for other enterprise tools and give us the confidence to invest in them. Node-RED is surely capable but without the evidence to point to, I will not be able to persuade our development teams to invest time and energy in it let alone convince my directors.

Bear in mind that I am certainly an enthusiastic supporter of Node-RED but in our public sector enterprise environments, that doesn't translate well. Frustrating I can tell you.

1 Like

Hi,
"How do you ensure that your flows are robust and meet your SLA's and non-functional requirements for example? How do you manage scalability? DevOps and CI integration? Backup and recovery?"

Because we're using Node-RED to test (APIs & UI) of commercially-written software some of those elements are less-defined than on 'mega projects' like 'write an entire SalesForce clone'. But all of it is doable.

We use GitHub for source code management, versioning, backup & control. NFRs are covered exactly the same as any other app: discuss, document, and show how you meet them. Catch failures and then harden your code.

Robust flows comes from pull request reviews and frequent examination of your results / work products.

Scalability is solved by us by using a Node-RED daemon running on each machine in a cluster of virtual machines / AWS EBS instances that pulls a Node-RED project onto a machine and starts it executing. Each VM / EBS machine supports 4 separate instances of Node-RED concurrently. Those execute tests or tasks and return results back to MySQL or Aurora DBs. CI integration for us is a WebHook. You can also use simple CURL commands to get basic changes from Circle CI - both work very well with Node-RED.

Again, everything is specific to our use cases but the methods are pretty much standard across the industry. Currently we don't do autoscaling but it is on our radar - and will be implemented in Node-RED. Most of our dashboards / control panels are in Node-RED, but we're probably going to move to Grafana as it handles time-series very well which is 80% of our needs.

Selecting a tool for each purpose is not much more than a checklist. Getting them to work with Node-RED is pretty easy.

Convincing a development team to switch to a new tool without having the authority and expertise to make it happen is hard. Partial buy-in and a phased approach is best; it's what we used.

TotallyInformation, I work for a big enterprise software vendor, and I can't agree with any of your bullet points.

Thanks for all the comments - really interesting that there is real world usage here targeted towards enterprise software as @TotallyInformation eluded to it would be great if there was more advocacy in this space (articles, thought leadership etc) or perhaps there is and were not seeing it.

To add back my interest in this is coming from a business leader working in electronic trading. I have engineers developing complex software to allow traders to automate execution across numerous asset classes. A leading proportion of my client base wants to get much more sophisticated but they are not developers - we could expose some pseudo code like framework but that got me thinking about Node Red as a way to visually construct complex automations.

Cool, I will have a look at that.

Not an enterprise platform we would use. Azure and AWS rule in our world.

Not wanting to put down what you are doing, it looks great. But sadly I wouldn't get a business case through with that kind of support.

Not to take away the potential and usefulness of what you are doing. I'm just pointing out that large enterprises, especially public sector, unfortunately have to operate to annoyingly restrictive policies.

As I indicated. My point was that, while what you are doing is perfectly correct and sensible, I would need to be able to point to existing evidence and that takes public exposure of process. It is that public exposure that we need more of for the enterprise use of Node-RED. At least in the types of enterprises I've spent my far too many years of experience dealing with (national and global enterprises often in regulated fields like government, health, and finance).

And vastly harder when you have to convince regulators, commercial and finance auditors and more.

It takes a long time and requires a lot of effort. That's why it rarely happens. There are too many other competing calls on time and resources. So we forever end up going back to approaches from big vendors who have the resources to support us. Not saying it is right, certainly not best, but that is what it is.

Agreed, and I'm always looking for entry points.

As an example, I recently got told off by my director for working with our dev teams and the CTO of another organisation that controls our sector but for whom we provide IT for pushing GitHub. He didn't see why we "needed another tool". And yet I've been working with Microsoft and GitHub to better support the whole NHS in this area, opening development, creating opportunities, standardising and much more. Hasn't taken much of my time but we are already seeing some great initiatives, a great investment. But still I get pushback.

By the way, I will win him round if I haven't already. And if I don't, there's that CTO I can use for leverage :grinning_face_with_smiling_eyes:

And that is for a tool used by over 40 million people globally and widely used in UK government already. Imagine how more difficult it is to try and introduce something like Node-RED :grimacing:

Perhaps you could expand on that? But don't forget, I work for what would be a customer, so if there is a gap between your understanding and mine, there is a problem for your organisation.

I'm always open to ideas and improvements and I'm always pushing for them. But this isn't about my desires or even about common sense or what is best. It is about being able to implement things.

Believe me when I say that Node-RED could easily compete against a number of tools that our organisations use and that cost a LOT of money. But that is no good to me if I can't persuade people to adopt it.

An interesting scenario indeed. Though one fraught with a few issues - such as whether this will touch on real-time trading where microseconds can be the difference between profit and loss. Or at least profit and more profit :slight_smile:

But maybe some pre-configured sub-flows that could be wired together with parameters for traders to use with a small development team creating the controlled structures?

I am an independent consultant, but 80% of my revenue is generated by work that I do at 3 manufacturing sites for a single multi-national conglomerate. One of the larger tasks is to gather information from a variety of Devices, SCADA, PLC, DCS and interface with other MES, ERP, Quality systems by any means possible (OPC, MQTT, direct data access, file imports, etc...)

Recently, this multi-national conglomerate began a pilot program to send key production personnel (plant managers, production managers, purchasing agents, quality managers, etc...) to week long courses in the use of Grafana and Jupyter. The idea is to equip these managers with the skills for visualizing data, designing work flows, etc.... So, yeah, NodeRed like tools.

We will see where this goes.

2 Likes

Haha. Worth reading all the comments here!
Thanks for sharing all your thoughts!

I have started a "start-up" business here in my country using node-red (as my Backend services). What I like of nodered is pretty simple, libraries are everywhere depends on your needs. I think node-red is more on "INTEGRATION" radther than a system (CRM, ERPs) etc. those enterprise softwares are very complex but I believe node-red can be part of those enterprise systems, specially on Industrial Automation industries. As I said, I believe node-red is highly recommended on the side of Integration.

With kind regards,
Henjoe

Yes something like this - essentially 'templates' that can be stitched together with parameter level control.

This is all possible through our UI if we extend it - but - the UI will get very complicated fast. We have a UX team that can help to manage that but still I feel there is another way.

The other approach I thought about was to use the technology behind the MIT Scratch project (coding for kids!). Have a look at this - Blockly | Google Developers

You can actually create some powerful workflows using this framework.

Yes indeed Blockly is an interesting technology. Have played with it quite some time ago: node-red-contrib-blockly. But won't go futher off-topic ...

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.