Why No code and low code support are critical solution options (Part 3 of 4)

Blog #1 in this series focuses on our journey

Blog #2 focuses on how the OpenLegacy Hub is the result of the journey

This blog is about why we choose no code and low code as critical components to the OpenLegacy Hub

During this two-year period, we had two niche initiatives started by internal company innovation.

1. ApiWorks, developed by the Customer Success (CS) team, was a web-based solution enabling the generation of APIs from predefined SAP backend programs (aka BAPIs - business APIs).
2. OpenLegacy Serverless, a serverless function design environment, solved a major prospect issue by using a native node.js (JavaScript) solution to enable deployment to AWS Lambda. Note: Our Java/Spring generated code just wasn’t sufficient in terms of required startup time (less than 1s)

Both initiatives went live, in less than a year with very small teams, and gave the company a taste of the SaaS world.

Another tier-1 client initiative started onsite a design-time Web app, enabling the generation of mainframe APIs and deploying them to OpenShift, without seeing any code (again, based on the IDE generation engine)

OpenLegacy R&D built a web product for a "reverse API" use case. It is a web solution using COBOL code generation to call OpenAPI/WSDL services with a microservice proxy between the COBOL and the API/WebService it invokes. Clients loved the simplicity.

We learned a lot from these initiatives.

On the positive side, feedback on UI simplicity was good. Users weren’t required to navigate through Eclipse menus, see code, or handle compilation. The UI simplified the process. On the downside, the serverless node.js solution didn’t use the platform’s codebase, all the design time and runtime connectors needed to be written from scratch, and it was going to be a long journey.

The ApiWorks solution used the IDE generation engine behind the scenes, but was limited to SAP only and needed to generate, compile, package, and deploy. This was a major slow down compared to typical web interface deployments. It was the first usage of OL cloud runtime.

We thought about how to solve this and said what if we didn’t have to generate, build and package every API generation but just deploy? How would that work?

The concept of no-code integration emerged. OL Hub saves everything in JSON metadata. So if we provide this metadata to a pre-packed container, it could load a project’s APIs and backend assets, create a Swagger page dynamically, and load the backend programs definitions. The Hub needed to invoke backend connectors without generating code, but we already did that in the RPC refactoring. We created a prototype, and suddenly - deployment was super fast. From 2+ minutes, it dropped to less than 10 seconds. Wow!

But we also needed to think about how to handle our database connectors (Stored Procedures mostly). We focused on an old IDE problem: Stored Procedures (SP) and Queries had two different solutions, Stored Procedures are RPC (remote procedure calls) based while queries in the IDE use generated Spring Data JPAs (Java Persistent APIs)

Now, in a no/low code environment, we could extend the SP connectors to support queries as well, using a prepared statement. But since no code is generated, JPA and Spring Data simply didn’t work anymore so we simplified our design to focus on one solution paradigm.

Serverless Function Support

Another booster to the no-code agenda was strategic ISV partners. We worked closely with iPaaS & Fintech ISVs, and the common need for all was getting access to backend operations without the need to generate code or build & package. They also want everything available in SaaS environments. With the Hub, partners can run the CLI and it generates JSON assets. They can use these directly or work with them through the Hub.

To solve the serverless startup time in our Java codebase, we had two major issues to handle. The first was to reduce dependency on Spring. Although Spring is a great framework, its startup time is not ideal. Tom ran the OpenLegacy connectors and flow engine without Spring, so now the startup time went down to less than 2 seconds.

The second issue was Java warmup time.

We researched GraalVM, which converts Java classes to native libraries. This sped up the startup time but only for the no-code solution.

For low code, we added support for node.JS since it is a popular scripting language for serverless. When we tested a simple Node.js function calling the native library converted by GraalVM, it worked amazingly. Now it took less than 500ms! We now reuse our entire connector code base for serverless deployment!

The next blog in this series shows OpenLegacy productized the SaaS.

To hear more from myself and the whole product team please attend this Product Update session.