Hyperledger Fabric is an enterprise-grade permissioned distributed ledger platform developed by the Hyperledger Foundation. What makes Fabric unique is that it offers versatility and modularity for an expansive range of industry use cases. 

Fabric’s modular architecture allows enterprises diverse use cases through plug & play components such as membership, consensus, and privacy. 

That said, the beauty of Fabric is that it enables a network or networks, and the members of a network work together. In such a situation, things become tricky when the companies these members work for do not want everyone to obtain access to all the data on said networks. Hence, companies maintain separate relationships within the network rather than an open, permissionless system blockchain technology is famous for. 

The aforementioned reasons set Fabric apart from the straight and simple usages of blockchains like Ethereum, and the very reason causes complexities you should be wary of. 

One such complexity is that executions made on Fabric can be permanent and cannot be altered after the fact, so it pays to learn about the crucial considerations before deploying Fabric in the blockchain network. 

So without further ado, let’s get started. 

Network Configuration

Generally, the structure of a blockchain is decided based on the use case it is created for. Development environment, consensus, concept, resource, management, security, and high availability are the priority aspects you need to consider before operating in production. 

Furthermore, the primary questions to consider are:

1. How many nodes do you need to establish high availability?
2. Which company provides the best globally available nodes? 
3. On what cloud platforms/data centers would you wish to deploy?
4.  Does this data center satisfy your requirements for uptime, disaster recovery, monitoring, and alerts?
5. How to ensure the security of your private keys and roots of trust?

Check out this article on the best blockchain node service provider. 

After these considerations, here are some of the network configuration decisions you need to make before deployment: 

• Certificate Authority (CA) configuration: A CA helps in issuing digital certificates and authenticates the digital identities of systems. It also helps certify the key’s ownership by the certificate’s name subject. That said, it is recommended to use a separate CA for every organization. You may decide to use this CA as the root or to operate as an intermediate associated with the root. It is also recommended that the production environment use Transport Layer Security (TLS), which requires the setting up a TLS CA to generate TLS certificates for the nodes. You can then deploy the TLS CA before the enrolment CA. 

• Database type: Hyperledger Fabric can utilize either LevelDB or CouchDB. Of the two, a few channels in a network may prefer LevelDB when speed is a priority, and the rest may lean towards CouchDB-rich query operations. That said, channels must ensure that peers don’t use both LevelDB and CouchDB, as the latter tends to impose restrictions on data for values & keys. Values & keys that are valid for LevelDB may not be accurate for CouchDB. 

• Peers and Ordering nodes: Peers are among the fundamental elements of a set of peer nodes in the Fabric network. It is a type of node that hosts the chain code and the ledger in a Fabric system. Channels connect peers to each other, and they can be grouped based on the ledger and contract management needs. Orderers, on the other hand, implement the consensus protocol to order transactions, along with sorting said transactions submitted by members using consensus methods in the fabric. It is explained how Peers, Orderers, and CAs fit the Fabric network topology chart further down the article. 

• Channels for Organizations: An identical copy of the ledger is shared with the organizations on a channel. These organizations can not only collaborate with each other to manage said ledger but can also create collections of private data. This enables a subgroup of organizations to commit, enforce, and question private data without the necessity of creating a different channel. Based on your use case, you might choose Channels as the best way forward to ensure the privacy and isolation of some transactions or take a call if having private data collections works better. 

• Container orchestration: There are various containers you can choose from to run your Hyperledger Fabric network. Based on your use case, you may either create separate containers for CouchDB, orderer, peer, gRPC, logging, communication, chaincode, and others or take a call to combine some of these in a single container. 

• Chaincode deployment: Hyperledger Fabric offers the option to either use built-in ‘build & run’ or custom ‘build & run’ to deploy chaincodes. If you require the latter, you can opt to use External Builders and Launchers and you also have the option of Running Chaincode as an External Service as well. 

• Importance of Firewalls: Just like in a traditional system setting, a solid firewall is a necessity in a production deployment environment. As elements that belong to one organization may often need access to elements of other organizations, advanced network configurations and firewalls play a vital role during the access. 

Every organization will need expertise in management systems and its own production environment to operate the network efficiently. That said, based on your requirement and use case, you may own & manage the appropriate blockchain network components. 

The Hyperledger Fabric Network Topology

Organizations participating in the Fabric decentralized network perform their own roles and manage different nodes. The chart depicts how the root organization is responsible for the consistency of the state and the network membership. 

As mentioned earlier, Peers and orderers are the most critical nodes in the Fabric network. While Peers store the ledger that contains the transaction log and the world state, Orderers maintain the consistency of the state and create blocks of transactions. CAs connect the entire network using the certificate’s chain of trust. 

The channel in the chart depicts a key abstraction in Hyperledger Fabric which forms a subnet in the network isolating the state and smart contracts. All the peers on the channel have access to the very data and smart contracts, and there’s no access outside the channel. 

Non-production Environment Setup

To ensure that Hyperledger Fabric smart contracts and client applications are thoroughly tested and ready for a production environment, it is vital to simulate a multi-organization, distributed network setup during the development process. That said, things will get complicated in the production environment when said multiple-organization network components reside in different clusters. 

To mitigate this complication, you may have one cluster network setup. Here, namespaces can separate the components of every organization logically and obtain a dedicated namespace, and all the Fabric components can then be a part of this namespace. By doing this, you are replicating a multi-org distributed network setup, which is more cost-effective and development friendly. 

Other than this, you may also want to consider having an isolated environment for stages, tests, and others where a shared ecosystem can coexist at the same time. You can achieve this by having a different Fabric channel for each deployment stage. As having a different independent channel creates a separate ledger, it helps you to ensure that the data of the test environment is removed from the development environment. 

Hence, taking this approach will enable you to obtain multiple channels having the same Fabric network components, and by doing this, you will also save infrastructure expenses by sharing the components (CA, orderer, peer, etc.) for all the environments. 

Management Tools & Component Deployment

As you can see, it is no easy task to configure and deploy a fabric network to Kubernetes but it is an extremely important process. To add to the complexity, adding chaincode and channels to the Fabric network is as imperative as launching the network itself. To make matters easy, you will find the details about “Helm Charts” below that helps you automate and simplify said tasks. 

You may also find the Kubernetes plugin “hlf-operator” plugin helpful in the process of launching a hyperledger fabric network in the blockchain. 

Helm Charts

Packaged Helm Charts are available on the ArtifactHub community repository, which is easy to use and highly configurable. As of the date this article is published, you may find the versions of each ‘hlf’ mentioned below: 

1. hlf-ca (2.1.0): is the short form of Hyperledger Fabric ‘Certificate Authority.’ Essentially, it is a CA node for the Fabric permissioned blockchain framework, which can either be installed as a Root CA or an intermediate CA (by pointing to a parent CA, which can itself be a Root CA or an intermediate). 

2. hlf-couchdb (2.1.0): is the CouchDB instance for Hyperledger Fabric, and it is the node holding the blockchain ledger of each peer for the Fabric permissioned blockchain framework. 

3. hlf-ord (3.1.0): is the Hyperledger Fabric Orderer node type that is responsible for the consensus for the Fabric permissioned blockchain framework. 

4. hlf-peer (5.1.0): is the Hyperledger Fabric Peer node type responsible for endorsing transactions and maintaining a record on the blockchain for the Fabric permissioned blockchain framework. 

Remember that as of the time this article is written, these helm charts are forked from AID:Tech and presently aren’t directly connected with the Hyperledger Foundation project. 

As mentioned above, the helm charts shared are highly configurable but may not fit every use case scenario, so you may have to modify them to fit your needs. For instance, you may have to use a storage service like ZDFS offered by Zeeve to store your node certificates and pull confidential information while deploying the nodes. To accomplish this, you will need to add the ‘ExternalSecret’ configuration file in the charts and perform the required changes in the value.yaml and deployment.yaml files. 

Wrapping Up

Once you understand these prerequisite considerations to deploy hyperledger fabric in the blockchain network, you move on to the setup process. 

Click this link to read the continuation and learn how to set up components, how to use CA to create MSPs, deploy orderer and peer nodes, and more. 

Speaking of nodes, Zeeve is a blockchain infrastructure as a service platform that provides a robust automation platform to deploy your Hyperledger Fabric nodes and networks. 

Deploy your Fabric smart contracts or applications on one of the many cloud platforms we offer. Our platform is cloud-agnostic, and we offer Google, AWS, Azure, and Bring Your Own Cloud services. 
So what are you waiting for? Reach out to our experts for a free consultation today, and join us on Twitter, LinkedIn, and Telegram.