7 ms·
we did a long evaluation of HyperLedger Fabric (0.6 - 1.x) for a project at my company. We really wanted it to work since the chain code model was cool however
by DIVx0 8y ago
we did a long evaluation of HyperLedger Fabric (0.6 - 1.x) for a project at my company.
We really wanted it to work since the chain code model was cool however we ran into stumbling block after stumbling block and in the end ditched it for something else.
List of pain points (no idea if any have been solved since we gave up on it)
1) Distributing chaincode updates to participants was an exercise in coordination that is unscalable
2) Kafka as consensus. At the time you had to use an infinite kafka queue since pruning it would throw fabric nodes into a panic and they'd drop off the network. We thought for sure we were doing something wrong but the need for an infinite queue was verified by someone at IBM
3) Community. The community around HL F was mostly IBM people or folks off doing their own weird thing and adding features or pull requests that were bizarre (a custom fork of postgres to act as state dB??). With that said there were a handful of _very_ helpful people there just never was a good mass of them
4) Performance. We wanted to run a private blockchain but amongst nodes distributed across the globe in whatever datacenter they chose. Running fabic in a truly distributed way just kills performance. There is a lot of cross talk and waiting for the ordering service to get sorted
5) Not really a blockchain. Fabric relied on the centralized ordering service and each node would contain its own state. If the ordering service pruned logs (which I guess is a feature now) then the distributed nodes could have ledgers that have content the central order does not know about. If that node wanted to rebuild it would need to rebuild from other nodes without a way to truly verify the content of the chain. This may have been solved but it was a gaping wound of a question when we raised it
There are others, in the end it was just way to much work and we moved off to a more popular blockchain and brought our proof of concept to feature parity and beyond in just two weeks.
We reached out to IBM for help several times and the answer was mostly "just buy bluemix" or "pay us and we'll implement it for you"
To use HyperLedger Fabric in any sense of scale and operational readiness you must run it all within one data center. If you have external participants in your network they must also be customers of that service or you can just run it all yourself in y our own DC for your own needs.
IF you go that route, it begs the question of "why bother?" You're putting everything in the hands of one entity and then adding in a ton of complexity and slowness. Just use a database or something right?
*edit format
- at-fates-hands 8y agoWe had a large presentation from IBM about hyperledger (I work for a healthcare company) and it seemed like something our industry could really leverage. I was put on a team to research using it on an upcoming project. Once we started digging in and asking questions, it became apparent very quickly IBM wants to control everything from top to bottom. It's on their network, they build it, they maintain it, and there's not a lot of options outside of what they've already built. We had some very specific functionality we needed and were told by the IBM team it wouldn't be a problem. When we got down to delivery and talking actuals, they started to balk if they could even deliver what we really needed. After trying to nail several things down and not getting anywhere, we pivoted and are currently looking at other blockchain platforms. After reading your response, it sounds like we may have dodged a bullet and made the right choice.
- brianbehlendorf 8y agoIBM is not the only company that can deliver a network built using Hyperledger Fabric, or any of the other frameworks. Did you take a look at Sawtooth, or Iroha? Did your devs engage with the actual Hyperledger community, or only through IBM? There are several healthcare companies (Change Healthcare is one, managing insurance claims) who have engaged directly and are in production.
- internet_user 8y agoCan confirm it is indeed very painful.
- Naomarik 8y agoIF you go that route, it begs the question of "why bother?" You're putting everything in the hands of one entity and then adding in a ton of complexity and slowness. Just use a database or something right? So what's the justification your company used for a private blockchain in lieu of a database?
- DIVx0 8y agoThere are many, but one of the points above mentions that participants are distributed globally and that saying that everyone must use the same platform was a nonstarter. I'll add that trust is not necessarily granted by inclusion. The needs for privacy do not have to include explicit trust and that a blockchain still solves very specific problems in this scenario.