Hyperledger Cello to Govern Multi-Tenant Blockchain as a Service

Explore how the Cello's architecture complements other Hyperledger Project incubations by automating blockchain deployments.

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.

hyperledger-cello-dashboard-platform-statusCello’s dashboard (Image credit)

 

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

Hyperledger Cello Simple GraphicImage credit

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

Cello was proposed and is sponsored by Baohua Yang (IBM Research), Haitao Yue (IBM Research), Makoto Takemiya (Soramitsu), Zhipeng Huang (Huawei), and Ryan Beck-Buysse (Intel).

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.”

 

Deep Dive with Hyperlenger Fabric

Cello’s architecture

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

hyperledger-cello-incubation-componentsCello’s components (Image credit)

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.

Cello Docker DeployImage credit

The orchestration engine and RESTful server are implemented with Python. The dashboard is implemented with JavaScript. The drivers are created through the Docker API lib to support native hosts and Swarm clusters. Monitoring, logging, and other tools are implemented with Golang. The framework is pluggable, so can be integrated with existing open-source tools.

 

What’s next?

Yet, as one would expect, a serious amount of work remains. Its roadmap includes, according to Cello’s documentation, goals to:

  1. Support more efficient scheduling algorithms
  2. Refine the web portal with ReactJS for better performance
  3. Support more cluster platforms like Kubernetes and Mesos
  4. Support other blockchain platform solutions (e.g., Sawtooth and Iroha)
  5. Support for Hyperledger Fabric v1.0 GA release

hyperledger-cello-dashboard-clustersCello’s dashboard (Image credit)

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.

Track Cello’s progress in its JIRA, documentation, or mailing lists.

 

Other Hyperledger incubations


This post was written by Roger Strukhoff and Sophie Turol.
Blockchain for Insurance. Interested in technical helps to improve security, mitigate fraud
  • 5
  •  
  •