Five questions you need to ask yourself before you ask for blockchain
About a decade ago, a new type of database started becoming wildly popular — way more popular, in fact, than it had any right to be.
All of the giant internet companies were using it.
Startups were getting funded based primarily (if not exclusively) on their commitment to use it.
And many folks who really ought to have known better were declaring that this was the end for the conventional database systems that had come before.
This new database was called NoSQL.
What many people failed to recognise at the time is that NoSQL is good at solving a specific set of problems… but pretty terrible at virtually everything else.
NoSQL is an excellent choice if you have massive amounts of traffic and data, and you need to process the data in real time.
However, it’s really bad at storing and accessing relational data… which just so happens to be what 99% of web applications actually need.
This is why NoSQL was such a good fit for huge companies like Facebook, Google and Amazon… and terrible for just about everyone else.
Fortunately, things have mellowed out, and businesses now have a much healthier relationship with NoSQL. We’ve learned what it’s good at — and what it’s not good at — and it frequently sits alongside traditional relational databases in many application stacks.
Those who do not learn from history…
A couple of years ago, a new type of database started becoming wildly popular — way more popular, in fact, than it had any right to be.
Many large financial institutions, retailers, shipping companies, even governments were starting to use it.
Startups were raising hundreds of millions of dollars based solely on their commitment to use it.
And many folks who really ought to have known better were declaring that this was the end for the conventional database systems that had come before.
This new database was called blockchain.
What many people failed to recognise at the time is that blockchain is good at solving a specific set of problems… well, I think you can see where I’m going with this (:
Blockchain is an excellent choice if you have multiple parties who need to agree on the contents of a database or the execution of a software programme, and they don’t tacitly trust each other.
However, it’s not the optimal solution if your objective is simply storing and accessing data in a fast and efficient manner.
This is why blockchain is such a good fit for facilitating cooperation between different people, organisations and platforms… but not so much for just about everything else.
Fortunately, things are starting to mellow out, and businesses are learning how to have a healthy relationship with blockchain. We’re discovering what it’s good at — and what it’s not good at — and it frequently sits alongside traditional centralised databases in many application stacks.
When should you use blockchain?
Just like any new technology, you need to think carefully about its capabilities and drawbacks, and how it fits into your stack:
1. Will a blockchain solution solve your problem?
Blockchain’s “killer app” is trust — it allows multiple parties to co-operate without having to rely on a central authority. Do you have a group of organisations and/or individuals who need to collaboratively maintain a data set? Is there a significant risk that a sovereign actor will attempt to censor or otherwise interfere with your application?
2. Who will run the nodes for your blockchain?
In order to realise the benefits of blockchain, there must be multiple (ideally unaffiliated) parties running nodes. How will they be incentivised to maintain their nodes? Are you comfortable with them having access to the data stored in the blockchain? Are you confident in their ability to properly secure their nodes against hackers?
3. What data do you actually need to store in the blockchain?
Relative to centralised databases, it is expensive to store data in a blockchain (in terms of latency, CPU, and — in the case of public ledgers — monetary cost). What data absolutely needs to go into the blockchain, and what data could be stored in a centralised database? For example, can you keep all of the data in a centralised database and just store hashes in the blockchain?
4. How will you make your data queryable?
Just like any other database, accessing the data stored in a blockchain efficiently requires careful planning and execution. For example, if you want to perform full text searches, you’ll need to copy the data to a database such as ElasticSearch. Also, some features that you may take for granted in other databases, such as foreign keys and indexes, might not be available, depending on which blockchain software you use.
5. Which blockchain implementation will integrate best with your current systems and processes?
Just like there are many different types of relational databases, there are also many different types of blockchain software — each with its own unique advantages… and constraints. Do you need smart contract capabilities, or just data storage? Will you use Ethereum? EOS? BigChainDB? PLUG? IPFS? Hyperledger Iroha?
Found your killer app? Set your sights on PLUG.
Now, I may be biased, but I firmly believe that what makes PLUG really stand out is its modular architecture. This allows core aspects to be configured or customised — or even swapped out entirely — in order to fit the specific needs of each blockchain network.
The upshot of this is that, once you’ve determined that your application needs blockchain, there’s a good chance that PLUG will slot right into your legacy systems without the need to rewrite existing systems from scratch.
Ready to get started? Find out how PLUG is building the Internet of Blockchains at plugblockchain.com!
