Hyperledger Cello to Govern Multi-Tenant Blockchain as a Service
Orchestrating pools of chains
Until recently, developers had to do a lot of manual work when deploying/managing a blockchain. This job doesn’t get any easier if multiple tenants need to access separate chains simultaneously. For instance, dealing with Hyperledger Fabric involves manual installation of each peer node on different servers, as well as setting up scripts (e.g., Docker-Composer) to kick off a Fabric network.
The new Hyperledger incubation was created to solve this problem through automatically maintaining a pool of chains. The Cello project provides the possibility of provisioning various configurations, while scaling the physical resources through a dashboard.
How Cello can help
Cello can make use of Docker APIs to manage blockchain clusters. Equally, if not more important, it can be integrated with a Hyplerledger Explorer dashboard to bring detailed operational knowledge and ledger detail to the enterprise IT team.
Succinctly put, this incubation aims “to reduce the effort required for creating, managing, and terminating blockchains” on various cloud infrastructures (including bare metal, virtual machine, and containers), according to its mission statement.
According to the incubation notice, Cello allows for:
- Provisioning customizable blockchains instantly (e.g., a 6-node fabric chain using PBFT consensus)
- Maintaining a pool of running blockchains healthy with no manual operations involved
- Checking the system’s status, scaling the chain numbers, changing resources, etc. through a dashboard
Major Cello’s features include:
- Management of multiple blockchains (e.g., create, delete, and keep health automatically)
- Nearly instant response, even with hundreds of chains or nodes
- Support for customized blockchains request (e.g., size, consensus)—currently, there is support for Hyperledger Fabric
- Support for a native Docker host or a Swarm host as the compute nodes
- Support for heterogeneous architecture (e.g., z Systems, Power Systems, and x86) from bare-metal servers to virtual machines
- Extensible with monitoring, logging, and health features through employing additional components
It was approved by the Hyperledger Project Technical Steering Committee on January 5, 2017. “Users will get chains with various configurations instantly,” its developers write, “while operators can dynamically scale the physical resources through a dashboard.”
According to its developers, Cello’s architecture is built upon the principles of the microservices approach, fault resilience, and scalability.
Cello comprises three functional layers:
- The access layer, which also includes web UI dashboards operated by users
- The orchestration layer, which on receiving the request from the access layer, makes a call to the agents to operate the blockchain resources
- The agent layer, which embodies real workers that interact with underlying infrastructures like Docker, Swarm, or Kubernetes
As the documentation goes, each layer should maintain stable APIs for upper layers to achieve pluggability without changing the upper-layer code.
Cello’s components are as follows:
- A dashboard for the pool administrator, which is also the core engine to automatically maintain all the other components.
- A restserver providing the RESTful API for other systems to apply, release, and list chains
- A watchdog to timely check the system’s status
Regarding deployment into clouds, Cello employs Docker APIs to manage the blockchain clusters in remote hosts, including physical servers and virtual machines. It follows the master-worker architecture, creating a web dashboard on port 808, a RESTful API on port 80, and Docker services through port 2375 from the master node, as shown below.
Yet, as one would expect, a serious amount of work remains. Its roadmap includes, according to Cello’s documentation, goals to:
- Support more efficient scheduling algorithms
- Refine the web portal with ReactJS for better performance
- Support more cluster platforms like Kubernetes and Mesos
- Support other blockchain platform solutions (e.g., Sawtooth and Iroha)
- Support for Hyperledger Fabric v1.0 GA release
Combining Cello with Composer, a collaboration tool for building blockchain business networks, to this growing Hyperledger toolbox should facilitate the task facing organizations that wish to build enterprise blockchains into their architecture. They seem to be great complements to Hyperledger Fabric, the framework that’s already in its v1.0 alpha release and hurtling toward a hardened general availability.
One of Fabric’s great promises is to allow a subset of validators to approve transactions, rather than requiring the entire validator network to do so. This new ability addresses the major issue of potential transaction throughput (i.e., it aims to prove that Fabric will be fast enough for the world of controlled, private networks for which it’s designed).
This ability could also be viewed as a simplifying feature, in that it should make it easier to convince enterprise top management of Hyperledger blockchain technology’s potential, and easier to (literally) get such networks up to speed. Adding in tools that make it simpler to deploy chains, to collaborate among them, and to know what’s going on in their operations should add to Hyperledger’s overall appeal.
Other Hyperledger incubations
- General Availability of Hyperledger Fabric v1.0: What to Expect in 2017 and When?
- Hyperledger’s Sawtooth Lake Aims at a Thousand Transactions per Second
- The Iroha Project to Bring Mobility to Blockchain with Simple APIs
- Hyperledger Incubates the Indy Project to Address Identity Management
- Hyperledger Incubation: Burrow Integrates Ethereum Virtual Machine
- Hyperledger’s Fabric Composer: Simplifying Business Networks on Blockchain