Blockchain Platform: Building a managed Blockchain-as-a-Service (BaaS)
The article discusses challenges associated with building a blockchain as a service offering. Sophisticated orchestration/tooling mechanisms are in place for distributed micro-service architecture deployment, management and monitoring. Cloud native development has became a common saga across industries in the recent years. The blockchain technology itself is evolving alongside the blockchain technology adoption, this is a never seen before trend in the enterprise world. While it is true that (distributed) database as a service offerings are available on almost all of the cloud service providers, the same level of matured offering is still a distant future for the blockchain technology. The complexity lies in the details of “decentralized” network architecture. The blog is an answer to how can one sustain the ever-advancing landscape of this technology, face through the skill-gap, yet produce an offering that hides away complexities for rapid adoption demands.
Design Thinking
Let’s start by defining the desired features for a good “as a Service” offering
- Infrastructure independent, cloud native and cloud service provider agnostic deployment options: One must be able to choose between their private cloud and public/dedicated cloud infrastructure, resource types varying all the way from VMs to containers. In cloud terminology one must be able to support both IaaS and PaaS.
- Highly available system including failover and recovery strategies: Guaranteeing a 100% uptime of services on cloud is next to impossible, yet these challenges can be mitigated practically via design choices. There shall be an option to recover from a failing point, if required one must also have an option to switch-over a live deployment to a new infrastructure altogether.
- Identity and access management: Define, segregate interactive and non-interactive personas. Create, manage and assign roles/permissions. Assign roles to these generated identities for the scope of a specific instance of the application. It is important to know what happened, who did it, when did that happen. These would also help in accounting for the cost.
- Monitoring, logging and alerting: While it is important to be prepared for a mayhem, it is important for one to capture (though it is tiniest) indication of approaching a mayday. It is good practice to capture metrics in order to continuously work on possible optimizations.
- Ability for multi-tenancy: While it is hard to build and manage a resource on cloud with SLAs, the benefit can be reaped only when it can be reused, shared across to others, with isolation. However, multi-tenancy shall be an optional configuration for the platform user.
A user interface can be provided for any deployment, administration needs. The roles defined and identity management shall be taken into consideration while designing the user experience.
Personally, I consider security to be an all rounder. It is not just horizontal but it is also vertical domain. The very reason why it is not listed as a requirement here is because, it is not only about securing the network traffic, identifying entities, securing the secrets. One must practice security in every step, starting from requirements gathering, procuring resources, architecting the solution, components design, coding and all the way upto the user experience.
Remember the KISS (Keep it Simple, Stupid) model, follow the principle of least privileges, be accountable for every resource and action.
Indeed, with great power comes great responsibility!
While all of these are true for any application, a good “Blockchain as a Service” offering would also encompass
- An option to choose the blockchain protocol of choice (be it Hyperledger Fabric, Hyperledger Besu, ConsenSys Quorum etc) with an ability to swap the protocol later. Includes support for a blockchain protocol agnostic smart contract engine and language interpreter.
- An option to use & switch between supported state databases by the underlying blockchain protocol, reuse an existing managed database offering where applicable.
- Application data ingestion and eventing: Abstract away any complexities involved in developing a blockchain application. Provide asynchronous means of transacting, record keeping for the incoming requests. It is good to have a synchronous write requests but that is not possible given that commit operation on blockchain is indeterminate. However, read requests can always be synchronized and an optional off-chain caching can be provided. Capture also all the events either emitted through the blockchain or smart contracts, streamline them to the applications.
- An option to interact & exchange data, make smart decisions spanning across multiple networks (could be of same blockchain protocol type or a different one). Blockchain interoperability plays a critical role given the current landscape.
- Tools for blockchain network/block visualization, consortium management, smart contract deployment, blockchain domain role mapping with the platform identities would come in handy. A good product would allow an administrator to debug the running instance of their platform.
- An easy to execute, end to end testing & performance benchmarking capabilities within the platform will complete the loop.
Add self-sustainability/self-management to all of these requirements defined so far, so that the human intervention is minimized. Well, you can be proud of building a software robot.
Design Choices
If you were to build a platform from scratch, it’s a no easy task. You will require skills from infrastructure provisioning all the way upto writing a sophisticated application abstraction layer. Consider breaking them into following broad areas to work on.
Control Plane
The part of system that will manage the underlying blockchain protocol. It may involve a (rather complex) mechanism to do all the heavy lifting.
Management: Consists of components that will procure & provision required resources, deployment automation, assign appropriate roles and secure them, generate necessary configurations, keep the health of the (entirety) system up & valid at any point, attach right monitoring tools, enable automated recovery procedures. These include deprecating and renewing necessary identities, accesses, optimizing the resource utilization when possible & scaling them up when required.
Administration: One would require different access levels for multiple kinds of resources. It is important to consider each persona in sight, especially it is crucial for an application developer to utilize blockchain offering at ease without having to learn underlying complexities. At the same time, an administrator should be able to play around with configurations. To give an example, a typical application developer would not worry about “how” does the distributed database perform synchronization and rather they would only consider how to store/retrieve the data. Whereas an administrator would not worry what data is added into the database, but rather consider the better configuration choices to guarantee SLAs.
Remember to secure provisioned resources! Take appropriate measures to restrict access and allow for data encryption by the right entity (both at rest and in transit).
A good platform would be modular, that is, you should be able to replace a particular component with another and the system should continue working as expected. Look for options to make control plane components highly reliable, these come by choices such as choosing the right inter-process messaging layers, make use of the storage spaces, designing each component for horizontal scalability, avoiding any bottleneck architecture, circuit breaking capability to withstand a particular component failure etc.
Data Plane
Define boundaries for user/service interaction with the platform. Remember that the control plane will manage all identities, however it is data plane components that will enable authentication & authorization to the right entity. Add components that will make application developers, business operators, consortium and network administrators to interact with the blockchain network managed by the control plane. Provide conventional means for interfacing including, for instance one can support RESTful APIs, web sockets, queues and pub-sub topics for data ingestions/event reading.
If you were to construct the platform as a House then control plane will be your cornerstone, blockchain protocol itself will be your structure on top of that. It is the data plane that makes it a Home! Sweet Home!
