Integration

Integrating your CorDapp into an existing, complicated IT estate will be somewhat of a journey. Before we dive in, let’s consider what DLT can do, what it can’t (or at least shouldn’t) do and why integration is so important…

Corda Can Supercharge a Business!

Over Simplified DLT Explanation

DLT allows the same, synchronised data to exist in multiple places. To write to those databases (the ledger), one or more parties must agree on the data that is going to be written. Who needs to agree is controlled by business logic and hard constraints in the form of Flows and Contracts.

The data on the ledger is versioned and immutable — you can’t just overwrite the data like a regular database, you have to create a new “version” of the data and write that. You can always see previous versions and everything is secured using cryptographic techniques — you can’t claim that “I didn’t agree to that” or “I put 1,000 not 10,000”.

Corda is R3’s DLT implementation and, with its private and permissioned architecture, is best suited to large Enterprise business problems IMHO. The rest of this blog will refer to Corda as the DLT tech of choice.

Problem

Two or more distrusted parties need to keep a record of the same data. They don’t trust each other to do that so they keep their own copies. Mistakes are made and there is a large operational overhead in the form of reconciliation.

A classic example is two people who loan each other money. Alice isn’t going to trust Bob to write down the right amount and tell her how much she owes, and vice versa. If they make a mistake and Bob puts that Alice borrowed “$100” but Alice puts that she borrowed “$10”, when the money arrives it is not what Alice is expecting. She then has to resolve this with Bob, they both update their ledgers and she has to send the money back to Bob — scale this up to large Enterprises and this is a costly operational overhead.

Solution — Use a Third Party?

To solve this you could use a mutually trusted third party to keep one record of the data for both parties. Issues will be detected before the money moves. This greatly reduces the operational overhead of reconciling — no need to move any money back.

However, there are costs associated with the third party and you have the potential political nightmare of identifying a third party which both parties trust. Also, scale this up and it doesn’t really work as each party will have hundreds, thousands or tens of thousands of counterparties.

Solution — Use Corda!

As discussed above, Corda allows you to have multiple copies of the same data. Using Contracts each party can be sure that they are in control of the data and that all relevant parties see exactly the same data.

Much lower cost and no need to trust another party.

Don’t Write Everything in Your CorDapp

Running a production-grade Corda node is no small feat. Making the node highly available (HA) using techniques such as a hot/cold deployment is significantly more difficult than regular non-DLT technologies.

In addition, the node itself is part of a wider network with other nodes that are outside of your control. Corda has excellent resiliency with this regard in the form of a back-off message retry mechanism built into its excellent Flow Framework. But still, it’s part of a complex messaging system and you want to minimise downtime.

Unfortunately, there’s no way (that I’m aware of) to perform zero-downtime upgrades on Corda. You have to initiate flow draining mode to allow the node to complete any in-flight flows and then stop the Corda process, perform the upgrade tasks (like deploying the new CorDapp) and then restart the node.

If you have non-ledger related logic in your application, move it into a non-DLT technology. Using well-known techniques you can upgrade these applications with zero downtime. There is a trade-off that more infrastructure and procedures need to be put in place but if you are using a well-known tech such as Java, .NET, Node JS etc., your customers will likely already have the capability to deploy and maintain these types of applications.

Now you can iterate on this logic with ease and no downtime!

Why Is Integration So Important?

Your CorDapp should mostly contain ledger related logic so it is likely to be a cog in the machine — rather than driving an entire business process. External systems such as Treasury Management Systems, Margin Management Systems and the like are going to need to instruct the node to do things and they are going to need feedback from your CorDapp.

This facilitates using existing GUIs or APIs reducing the barriers to adoption.

You will also need to allow data to be pulled from the node for reporting and auditing purposes.

Make Integrating as Easy as Possible

Integration will be something you come up against and it will be a journey from business analysis through to design, build, deploy and maintain.

The default interface to integrate into a Corda node is RPC, which, in my experience, the majority of development teams are not familiar with. In addition, spinning up your CorDapp will require some Corda knowledge and, very probably, some internal knowledge of your application — perhaps there are some initial states that need creating or maybe there’s a Business Network Operator node that requires some config. These cause barriers to adoption and essentially increase the effort and cost required by the customer to integrate with your CorDapp. It also increases your cost to support these PoCs per customer as you are having to hand-hold the customer through the setup process — which is not interesting to either party.

You want to reduce this cost as much as possible so you can move along the sales process and demonstrate how your application can help their business.

There are two things you can do that will help significantly:

• implement an Http API
• have the ability to spin up private networks for your customers to build against

Let’s explore both of these things in more detail…

Http API

Use well-known technologies to deliver your API — which these days basically means an Http API. You could use Graph QL or REST to structure the endpoints — so long as you use something that’s popular amongst developers and is common in the enterprise world.

Architecture

You can either create a separate web server application to deliver your API or you can run the server inside the Corda process.

To run the server inside the Corda process you can use BRAID. I haven’t actually implemented this so I’ll leave you to do your own research. My “Solution Architect” spidey sense says that a separate web server which can be scaled and maintained independently is probably a better solution, so I’ll focus on that.

Technology Choice

You have to use a Java bytecode generating language such as Java or Kotlin (I recommend Kotlin) because you will need to consume your CorDapps as dependencies in order to integrate via the RPC interface in an efficient way.

I’ll do a very light-touch analysis of the web server technologies Ivno looked at:

Ktor

This did well in performance tests and was easy to build against but, as a new technology, we were concerned customers may have additional due diligence to perform before adopting it — another barrier to engagement.

Vertx

This performed the best in performance tests although there were some concerns regarding the internal training required to build against this in a confident way.

Spring Boot

Ultimately Spring Boot was fast enough and extremely well known. We had the internal knowledge to build against this immediately and with confidence. So Spring Boot was our technology of choice!

Authentication, Identification and Auditing

In the enterprise world and particularly in the Fin Serv and DLT world, security is absolutely paramount. It should be considered in every design decision of your software. Enterprises will expect your web server to support mutual TLS so make sure you know how to set this up and that your web tech supports it.

Customers will also expect some method of identification. Each request that comes through the API must authenticate and identify itself. This way you can add roles and permissions to each “user” within the system and you can restrict which operations each user can perform within the system.

This is also imperative for auditing purposes. Every action should be recorded in a regular database, including the user that performed that action, to ensure a full audit trail. Again something enterprise customers will expect.

Sandbox Networks

OK, so you have an easy-to-use API that innovation teams can integrate with. But they need a running instance of your app in order to build against.

As discussed earlier, spinning up a Corda network or even running one through deployNodes requires some Corda knowledge and expertise. On top of that your application will likely require some setup and orchestration. Just handing your CorDapps or even a docker image to a customer will cause both you and them a headache. And just getting a running instance is unlikely to be part of the scope of a PoC — it’s boring, costly and yet another barrier to revenue.

At Ivno we utilise Infrastructure as Code (IaC) technologies (namely Terraform) with a cloud provider (AWS) and a custom orchestration application to allow us to spin up private networks with one command, and in a matter of minutes.

We then give customers access to these instances to build their PoCs and integrate their test instances of their existing systems. We do the heavy lifting for them!

By using IaC and scripting the creation and destruction of these networks, we can get our software into the hands of customers at minimal cost to us. Not every PoC will result in a signed contract so this reduces our customer acquisition cost significantly.

Create a Plugin System

This is something for further down the line as it can be bolted on to your offering at later date.

I’ve recently covered this topic in a blog post, however the high-level concept is to create libraries for languages your customer’s use to integrate with your API.

This means you can keep your Http API low level and flexible but also offer a way to very quickly integrate into your Http API from their language of choice.

At Ivno we currently write all of our plugins in Node JS, and our plugin library makes it extremely quick for us, and our customers, to build new functionality around the node.

Read my blog post for a deep-dive into the subject: Creating a CorDapp Plugin System

TL;DR

• Put an Http API over your CorDapp to make it easier for existing non-DLT savvy teams to integrate with your system
• Make it easy for you to spin up mini private networks for customers to create PoCs against

These 2 things mean development teams with zero Corda, Blockchain or DLT experience can integrate with your system in a matter of hours.

P.S. Listen to me discuss some of these topics in my From The Basement podcast interview with Martin Jee.