Some Recent History
Over the past two months I’ve had the privilege of becoming part of the ever-growing Hyperledger community as I’ve developed ablueprint to deploy Hyperledger Fabric to virtually any environment (whether it be a public or private cloud, bare metal, or bring-your-own-nodes) using Cloudsoft AMP.
Along the way I got the chance to speak next to our CEO, Duncan Johnston-Watt at the GlueCon keynote where I performed a live demo (that actually worked!) deploying a single Hyperledger Fabric cluster onto BlueBox Singapore. For more background on how this works, along with a step-by-step guide + video demo, check out my initial blog post.
After the keynote that I totally wasn’t super nervous about, I made some more improvements to the blueprint and showed them off a month later at the DockerCon community theater alongside Andrew Kennedy. This time around I demonstrated an even cooler setup: multiple clusters of Hyperledger validating peers across three different BlueBox data centers (San Jose, London, and Singapore), all networked together using a VPN to create a large, distributed, private fabric. All of this, of course, was achieved with just a few clicks in AMP. For more info about this, check out my second (brief) follow-up blog post which contains an updated video demo as well as the slides from my DockerCon talk.
The latest version of the AMP blueprint for Hyperledger Fabric boasts a number of useful features.
The biggest feature is the seamless support for multiple clusters of validating peers which can be deployed to multiple different physical locations, all networked together to form one fabric. This is made possible thanks to the AMP feature “dynamic regions fabric” (not to be confused with Hyperledger Fabric… don’t we all love a good overloaded term?). Using a dynamic regions fabric with AMP, we can easily deploy many instances of the same entity to many different locations. In this case, the repeatedly-deployed entity is a cluster of validating peers.
The “dynamic regions fabric” works under the hood; from the user’s perspective, all he or she needs to do is add a list of locations at deploy time via the AMP GUI and a cluster of validating peers will be created in each location. Pretty cool!
What this means for you as...
A Blockchain application Developer
In order to develop, run, and test application chaincodes, you first need a Hyperledger Fabric cluster up and running. This requirement certainly represents a barrier to entry for many would-be developers. Rather than focus on what matters to you, building something useful using blockchain + Hyperledger, you need to start off dealing with the plumbing, so to speak.
With Cloudsoft AMP and the Hyperledger Fabric blueprint, jumping over this initial hurdle is just a matter of a few clicks. Simply configure your desired deployment location(s) and deploy! The cluster can be as large or as small as you’d like, running on one or many locations of virtually any kind.
An Organization looking to stand up your own Hyperledger Fabric cluster
Just like the developer, you do not want to spend time and money solving the problem of getting your enterprise Hyperledger cluster up and running; let AMP do it for you.
In addition, you will likely want clusters running across many public or private cloud data centers, as well on your numerous private servers. Using AMP’s “dynamic regions fabric” feature, it is extremely easy to deploy a Hyperledger Fabric amongst any / all of these locations together.
Finally, when it comes to public clouds, you want to avoid lock-in with a single provider. AMP is very well suited to solve this problem. Blueprints are location agnostic; authors do not need to care onto which locations their blueprints will deploy since AMP can handle a wide array of locations. You can rest assured that the Hyperledger Fabric blueprint is portable, so when a more appealing public cloud offering presents itself, you know you can easily move your Hyperledger Fabric there.
Download the Cloudsoft Blockchain service here.