Blockchain has been receiving a lot of interest in our industry. The blockchain technology, originally developed for Bitcoin, has been touted as the next answer for all our distributed information exchange needs – essentially, it is often considered as a universal answer for all integration requirements.
But Blockchain is not the Ultimate Answer. Actually, it will not work at all – or work very poorly – in a large portion of the possible integration cases.
Quest for the Ultimate Answer
I have noticed I have become a very lazy reader. I am not able to finish the books I have started to read, and therefore, I do not start new ones too often. Furthermore, there is only a very small handful of books that I have read more than once. One of those books is the classic The Hitchhiker’s Guide to the Galaxy by Douglas Adams.
In its full absurdity, the novel contains a great deal of parallels with the current IT industry. Including elements such as the Babel Fish – the universal translator that has a slightly disturbing installation procedure – it contains plenty of ideas that could be useful in the integration scene.
However, one thing in the novel that I like the most is Deep Thought. Those of you who have read the novel know that Deep Thought was a supercomputer built by a hyper-intelligent species (that we humans wrongly interpreted as mice). Its only task was to come up with the Answer to The Ultimate Question of Life, the Universe, and Everything. After the computer had been calculating the answer for seven and a half million years, it eventually came up with its famous answer, “42”.
Download our iPaaS product sheet and learn more about how integrations can enhance your digitalization strategy >>
Having worked in the IT industry for twenty years, and most of this time within the systems integration space, I realized that Adams understood very well what he was writing about. We developers are always looking for “The Answer”, we want to find the one, universal, always-right principle that kills all the other principles. We are willing to believe that there’s a single truth that would make our own mortal ideas look stupid or irrelevant. We want something that we can believe in and leverage in everything we do. During the twenty years that I have worked in the industry, I’ve seen a lot of Answers, and now we have yet another Answer at our disposal: Blockchain.
The hype around Blockchain has gone so far that it is often considered as a universal answer for all integration requirements. The capabilities of Blockchain are surely intriguing – information can be exchanged in a non-repudiable manner (e.g., no-one can claim that a particular transaction has not happened) and the network of Blockchain servers ensure that operations are extremely fault-tolerant and free from limited network or server failures. These properties surely make it an interesting choice for global, distributed integration.
Challenges
Unfortunately, Blockchain will not work in most integration cases. I will provide three counterexamples to illustrate my point, focusing on the challenges in integration logic development, hosting, and confidentiality.
The first example is about integration logic creation. When people talk about Blockchain, they often seem to forget that Blockchain is nothing but a distributed database. Any database is a data storage utility; it is useless if there is no application running on the top of the database providing the actual application logic. If a database on its own would solve some integration needs, all the internal integration challenges within any company would have been solved. We already have well-known tools to create a non-repudiable, secure database in a limited scope (i.e., within one organization) using any commercial database and some basic DevOps magic. However, the database would be useless without somehow creating the actual integration logic.
In Blockchain, the actual application logic is created using something called “smart contracts”. However, development of these multi-party distributed applications is still rather a new development area. Also, it surely isn’t easier than creating integration solutions with more well-known development paradigms. It is possible, of course, but if internal integration needs have not been solved using more traditional programming tools to date, I cannot see how Blockchain programming model would solve these in an easier way.
The second case has something to do with an area of integration that is at the forefront of the Blockchain discussion – IoT. Blockchain has been considered to be able to provide a global information exchange backbone that makes possible for all the integrated “things” to communicate with each other as well as with all the back-end systems that utilize and process the information provided by IoT devices.
Now, let’s calculate some hypothetical numbers to consider whether this would work effectively (taking an example from the logistics industry). Currently there are numerous ongoing projects in which organizations are attempting to create solutions that will track containers traveling throughout the world. This tracking will provide information about the location of the container, and typically also information about the traveling circumstances – things like temperature and air pressure (in- and outside of the container), acceleration, etc.
According to some guesstimates, there are over 23 million shipping containers in the world. Let’s say all these containers are fixed with a device that would communicate the container’s status in real time – in our example, let’s assume they will do this once a minute so that anomalies can be quickly detected and acted upon. Furthermore, let’s just assume that one such status message would hold 100 bytes of information (Note: I just made up this number).
This would mean that the 23 million containers would generate 2.3 gigabytes of data every minute. That means 138 gigabytes an hour, 3.3 terabytes a day, 99 terabytes a month, and more than one petabyte (1 x 1015 bytes) a year.
Now, if we want to stick to using Blockchain for saving all this information, we can be sure that all these events are securely preserved throughout the network, and no data would escape our attention. The reason for this is the technical distribution architecture of the Blockchain, where all the individual nodes are saving all the data – and doing it eternally so that it cannot tampered once it’s been generated. Unfortunately, this also means that all the servers in the corresponding Blockchain network would need to prepare to save a petabyte of data – for every year. One could ask whether this information is so valuable that it needs this kind of treatment? Do you need to store it indefinitely? Would you be ready to save such amount of data on your Blockchain server? The truth is that the value of Blockchain is tied to the number of servers – the more servers, the more reliable the network is.
I am sure that storage capacity vendors must like Blockchain.
Furthermore, a traditional distributed network becomes more powerful as the number of its constituent computing nodes increases, because the load is typically distributed among these nodes. With Blockchain, this is not so clearly the case. Because the network must agree on the validity of each transaction, the computing doesn’t get any faster as more nodes are added – instead we have seen very different behavior with Bitcoin, where transactions are getting slower and slower as the network size and the volume increases. And with Bitcoin, the number of transactions is minimal if you compare it with the possibility of transactions originated from IoT devices around the world.
The third thing that should be carefully considered is information security. Blockchain architecture is built to ensure non-repudiation of the data, but in a basic scenario it does not – and cannot – provide confidentiality of the transferred data, because when a Blockchain node processes transactions using smart contracts, the data that is processed needs to be unencrypted plaintext. Current cryptography does not allow nodes to process encrypted data. This means that all your business-critical data can potentially be shared by all the parties who are installing Blockchain servers in the network – and there is little you can do about that. Of course, you can encrypt the business-critical data in end-to-end manner – the very basic way Internet confidentiality typically works – but that has a side-effect that you cannot create smart contracts that would be able to make sure this data is correctly formatted; you cannot create smart contracts that would create transformations; etc.
Just another 42
I must underline that I am not criticizing Blockchain as a technology. It’s a very good choice in cases where multiple parties that do not necessarily trust each other are communicating with each other. With Blockchain, these non-trusting parties can create a common understanding of valid transactions without a need for a central trusted broker. Blockchain is a great choice in scenarios like financial transactions, online voting, insurance, and similar scenarios.
But it is not a tool that can – or should – be used everywhere, just because it is good somewhere.
In The Hitchhiker’s Guide to the Galaxy, the hyper-intelligent species were somewhat happy with the answer “42”, but they realized they didn’t actually know what the question was. Therefore, they created even greater supercomputer to calculate the original question. According to the original story, that computer, unfortunately, crashed just minutes before it could have produced the answer.
I think we are still more than five minutes away from that crash, so there is no need to worry about it. We are still in our seven-and-half-million-year cycle of looking for answers before thinking what the actual question was. And if we are in that cycle, we will find our new forty-twos every couple of years.
