In this episode of Blockchain Innovators, Conor Svensson - founder and CEO of Web3 Labs, talks to Peter Broadhurst - co-founder and Head of Engineering at Kaleido. Prior to Kaleido, Peter worked at IBM for 18 years on cloud computing and middleware technologies.
Conor and Peter discuss the problems that blockchain solves that middleware couldn't and what Peter considers to be the next big opportunities for blockchain in enterprise.
Peter also talks about the newly launched FireFly project which provides a multi party system for enterprise data flows which lets developers build decentralized enterprise grade applications on blockchain based business networks.
Join Conor and Peter as they 'geek out' on how blockchain fits in to the broader technology landscape!
You can also watch this video on our YouTube channel here.
➡️ Remember to leave us a 5* review and we'd love to hear your comments too!
➡️ Discover Web3 Labs
➡️ Follow Web3 Labs on Twitter
➡️ Follow Web3 Labs on LinkedIn
➡️ Follow Conor on Twitter
➡️ Get Conor’s latest thoughts on Web3 at https://writing.conorsvensson.com/
Hi, it's Conor Svensson here, founder and CEO of Web3 Labs. This is a conversation I had with Peter Broadhurst. Peter is the co-founder and head of engineering at Kaleido. Kaleido is a full stack enterprise Blockchain as a Service platform. Previously, Peter worked for IBM for 18 years where he worked on cloud computing and middleware technologies. In our conversation, we discussed the problems that blockchain solves that middleware couldn't and where he sees the big opportunities for blockchain in enterprise. We also cover the newly launched FireFly project which Peter is very involved in. FireFly provides a multi-party system for enterprise data flows which lets developers build decentralized enterprise grade applications on blockchain based business networks. Like myself, Peter is a technologist at heart and it was fun to geek out on how blockchain fits into the broader technology landscape. Peter, great to have you here. Hi Conor, great to be here. So, you've been involved in blockchain as one of the co-founders at Kaleido for a number of years but prior to that you were at IBM for 18 years, if I have that right? And from what I understand, you were working on cloud computing and middleware, so I'd love to hear about really what you did at IBM and how that ultimately transitioned into blockchain technology. Yes, I guess it's interesting for me because when you look at the technologies that I was working on throughout my career, there's a huge overlap with what blockchain is trying to achieve particularly in the enterprise space. I started at the beginning of my career working on a technology called MQ/ MQSeries it was, in IBM. It was one of the original sort of game-changing technologies for how different companies could do cross-organization transaction processing and it was just a messaging system fundamentally but it was reliable so you could send something and know it was going to get there. It sparked a huge, huge wave of these technologies that were about a different way to communicate. We've all heard of AMQP and RabbitMQ and these other technologies as well. So that's why I started and it's amazing how similar that is to sort of where I'm back to now in the blockchain space trying to solve a similar problem. As I went through my career, I got very involved in the application service stack and the transaction processing there, the websphere stack and also on the integration side. How the core systems of enterprise could integrate together and I did a lot of my my time actually in the support side, working on other people's code rather than actually new development. So I got to see the whole stack inside and out, which was a really nice journey to be on. And a lot of work with customers in the last few years at IBM actually traveling, working with customers sticky projects, complicated things that need to be designed, actually being out there seeing the kinds of business problems that people are trying to solve with these integration technologies between organizations. So you say about the similarities with blockchain and there's been that argument historically with middleware technologies - how they can be used in an enterprise and they could potentially span multiple business units but there's a point where it makes sense for a large organization to be working with middleware technologies. Then there's a point where potentially they could actually want to look at blockchain even for actually connecting multiple subsidiaries of a single organization without thinking about the external connectivity. Is there a point there where you feel the natural jump becomes the blockchain? Yeah, absolutely. Blockchain does something that was impossible, throughout my career, was absolutely impossible. Every previous generation of how organizations work together before the, we tend to refer to it now as a multi-party system, there's this new thing enabled by by blockchain tech. Every previous generation was 'I have my source of truth. You have your source of truth. And we're doing some kind of ping pong exchange. Whether it's SOAP web services or REST or messaging, we aren't agreed on a source of truth. We're exchanging information from two different sources of truth.' And suddenly with blockchain, if you build a multi-party system that's got a blockchain in the middle there, it's game changing because you can have a shared source of truth with other organizations and you don't have to trust them to trust the source of truth. That means that a network of businesses which are cooperating and competing, this sort of competition can work together and have certain agreed truths such as sequences of events or in tokens, total conservation of value or uniqueness of one particular reference ID in the world that we're all using for the same thing. Those base constructs completely change the kinds of problems that you can solve and get away from, we used to call it compensation logic, it's so complicated. Like, 'I said this to you, you said that to me, it all happened at the same time, we end up with different results, how do we sort out the mess?' And sorting out that mess with people involved in business processes could have taken weeks in the past in real world scenarios. And with the multiparty system, if you can get it right and you can get the balance, the right things to be the shared data and you still get the privacy side of it right, then you can take those sort of weeks and just have agreements immediately. Agreements that no one would bother to challenge because there's an audit record that's just so clear. But, you don't have the sort of 'Where's my message problem' of 'Did I say that first?' 'Did you say that first?' 'I think I said it, but you didn't confirm that.' 'Does that mean you didn't?' All of that goes away with blockchain which is fantastic. Is this something that you recognized when you were still working at IBM or is it more something that you've developed a real narrative around as you've spoken more and more with customers working with blockchain technology? That's a great question. Blockchain was the exciting new thing that was happening in enterprise for a few years while I was still at IBM. So it would be the water cooler conversation, right? It would be with the person who's just gone to the blockchain team to build blockchain stuff because it's fun and new and interesting. So I think that excitement was certainly there for me, that the possibility it just seemed to me like this was the first technology that could change the core of businesses rather than the outside. It could actually change the way business core transactions happen. It wasn't just about surrounding and connecting stuff. It was actually about changing the core way an end-to-end business transaction happens and that means for enterprise IT, it's huge! The potential, still nascent honestly, potential for cross-industry revolution on how business gets done. I think it's a unique technology from that perspective. So yeah, that was why it was so exciting to launch into Kaleido, out of that because it just felt like this could really change things in a meaningful way. And really make things better as well because, another side of blockchain is that it increases the transparency. It can increase the trust that users of systems can have in the systems themselves but organizations start to work together in new and interesting ways which are more open, more collaborative. They're building business ecosystems rather than completely centering in one business and that's really exciting for lots of different reasons. Not just what it can do for the big enterprises themselves but actually what it can do for us all in terms of systems working better for people. That's something I think about it in terms of businesses almost turn themselves inside out when they're engaging, making use of the DLT because although there is of course privacy considerations, you're not making available sensitive information, but it's like how the processes can actually run in that sort of collaborative environment there. Do you think about there being parallels though with projects like the Baseline Protocol for instance? They talk about this notion of blockchain can almost be used like a middleware technology between these different organizations. The fact that you've got this kind of layer of programmability that can happen at the protocol layer is one of the distinguishing features with blockchain, but do you think there are parallels in that regard as well? Well, yes. I guess we've been on the journey throughout Kaleido the last few years, seeing how real projects get to production on blockchain. The cold hard reality is, it is a lot like middleware because these organizations aren't immediately going to be throwing away all of the core systems that exist inside of those businesses. So the only way that a blockchain ecosystem can be valued to a business is if it integrates with the core systems that they use on a day-to-day basis. It's got to make their business better in a meaningful way and if it doesn't integrate then it's a real problem. What we've actually seen is that there's two things that matter, matter hugely when you're going about one of these projects. The first is getting the use case right so that you can demonstrate real value that is valuable to the players in the system. The second is being able to take the skills that exist across those organizations, rather than just the skill that exists in some central specialist team that understands blockchain protocols and zero knowledge proofs and baseline and all of these low-level technologies, you need to be able to engage the actual integration teams, the data engineers, the application builders, and you need to be able to... and this is the really key point... get to a proof of value quickly because I think the fact that it is a lot like middleware, it doesn't do anything on its own. The thing about middleware that's been true throughout my career, you're working on the plumbing, the bit that doesn't deliver any value in its own right. It's hugely valuable, but on its own it doesn't generate the value. It's a tool that allows use cases to be built on top of it. So, what's the most important thing about a piece of middleware? How quickly it enables developers, and for blockchain ecosystems and developers, to build solutions. That's the most important value that it has. How sophisticated and clever it is inside, is really useful and the subtle differences between the blockchain technologies, the different ways that you can use them, that's great. But really what do business ecosystems need? They need proven patterns that have worked elsewhere just made available to them sort of as middleware, so they can build applications on top. We've been astonished looking over the last few years and coming to projects that have been going a while and that we've been helping with and building projects from scratch, just how much rebuild of the plumbing is kind of the norm in projects. We try desperately to avoid it, right? That's just not where the value is coming out of. So, you need to build on top of it. But we've seen incredible amounts of resource being used on just building the plumbing necessary to have a blockchain network with everyone having the nodes, have the transaction streaming on, have the events coming off, have the private data integrated with the blockchain data, all of that stuff that isn't about how do I actually build an application on top of it. Just taking ridiculous amounts - years - project years of time. I think that more than anything, that's the thing that will allow the next wave of innovation, of production innovation, on blockchain is going to be projects just being able to iterate the use case level rather than the plumbing level. Yeah. Certainly with what you say, it makes you think of a couple of things. Firstly, with the number of hackathons that have happened where the output of the hackathon is getting a blockchain up and running back in the earlier days and also with enterprise architecture specifically, it's not had it's sort of enterprise integration patterns moment where you've got really well-defined approaches for integrating these different types of solutions for this. One of the things though that you spoke about there as well, was the actual use cases and the importance of having the right use case too. What are the things that come to mind about one of the really good use cases here? It could be that you give specific examples or it could be just more than calling out the properties that you feel very relevant. So I probably will give just more general answers. But, one of the things and one of the journeys that led us to FireFly, that it'd be great to talk about a little bit, where we're trying to take those patterns and make them in an open source way rather than it just being - you come to a company like Kaleido where every developer should be able to develop these use cases. What we've seen, maybe uniquely in our journey in Kaleido or maybe not, is that we've seen lots of patterns that across industry beyond the core financial token ones. Just a few examples, one is around improving business processes, multi-party business processes. Cases where it takes UPS trucks and planes flying around the world and physical documents exchanging to allow ships to leave ports or money to actually close out the end of some business transaction. Those kinds of use cases, the efficiency gains can be huge. So improving the way an end-to-end business transaction works is one really critical one. Another one we've seen which is really interesting and we've seen across industry over and over again is enterprises at their core are about the data that they have in terms of the IT landscape. When you're trying to do something in a business ecosystem of any kind, everybody's got that own source of truth and their own internal amount of data. Data on customers, data on transactions, data on products, data on things and one of the biggest sticking points is that everybody is constantly spending time and effort trying to make their data consistent and correct and make their data consistent and correct for everyone else in the business ecosystem. They do that because there's no way for them to share data and this is as true as it is for health care data, as it is for insurance data, as it is for core sensitive cross-government department data. They have strong regulations that mean they have been really careful about how they share data with each other but they actually want to share the data with each other in certain scenarios because they also have requirements that mean they must be able to agree on certain core things. I'll give a specific example that might sort of bring it home which is one you can read about from a really fantastic organization, called Wish Stream, which is part of the institute's, one of the biggest groups of insurance organizations in the US. They have a use case around what they call mortality monitor and this problem that all of the insurance companies need to pay out to people in the case of a bereavement. And the poor people who are dealing with that, which is incredibly hard for the the actual people who are dealing with bereavement, are asked to provide data, the same data, tens of times during the process because those individual insurance companies actually being able to share that information is really tough. That delays payout of the actual insurance to the bereaved and it just causes a huge amount of human suffering, right? In terms of having to go through that to actually prove that somebody has passed away. That problem amazingly can be solved using blockchain at the core in a way that it couldn't have been solved before. So there were use cases that are just like a world away from here's an SDO issuance or I've got an NFT of a fantastic football player that I want to put out there on the web. There's use cases that are just hugely detached from them. But the core constructs of uniqueness, things like tokenization to help the ecosystem work, can just transform the way it happens. Yeah, absolutely. So I know that you obviously want to talk about FireFly as well. This is a recently publicly announced project within Hyperledger. It's come out of the work that you've been doing over the number of years now at Kaleido and so for those of people who are listening who aren't familiar with Kaleido, it's probably worth just introducing a bit more about who Kaleido are and what they do. Then, I think talking about about FireFly and why it's so exciting, why it's so relevant right now. Yeah, that's great Connor, thanks. Kaleido's a startup that's focused exclusively on this problem of money party system. So we're a specialist in the blockchain space and we focus on making this technology consumable for enterprise. So back at the beginning, we started with some of the problems, which as you pointed out back then, people were spending huge amounts of time on 'how do we get a network up and running?', 'how do we get the right balance of decentralization and sovereignty and consistency to actually have everyone's got a blockchain node?' Right? 'What does that look like?' 'What's the right balance of hosted and hybrid etc. approaches to having a blockchain network up?' That's where we started. We launched on stage. Our Public as a Service offering with AWS there were up on stage as we were the first managed service that they had and continued to go on to partner with Microsoft as well and Provide's as a service infrastructure. But immediately, as soon as we'd done that, we actually started then building on top of that and building some of the services that were new, that didn't exist. One of the earlier services was how do you get transactions streaming onto a blockchain. How do you get events coming off, and then things like organization to organization private encrypted data exchange output messaging large documents, building that sort of stack on top and providing as a service a sort of solution stack for building enterprise applications. We work directly with with network operators and enterprise business networks and we help all the way from the developments of the application use cases, the decentralized app, and the end user experience and APIs, all the way through to providing that enterprise grade as a service infrastructure in the back end that allows this network to have their software infrastructure connected back to their organization. It also allows everyone to go fast enough that they can connect together and that's why we we also do focus a lot on providing as a service infrastructure still. So, with these building blocks that you created, you started to see some common patterns emerging there, right? And some problems that you really felt that you were solving that were probably bigger than Kaleido itself? Yeah, for sure. You know, it's a big decision for an organization like ours, that has a lot of unique insight in the space, to go and say 'well the thing we were gonna do is we're gonna take the crown jewels and we're going to make them available', right? That's a really big decision and the reason why we felt it was just what blockchain needs is we were solving the same problems over and over again. We had the tools on the truck to do it but when you look at the blockchain sort of revolution and where it is and you know as it's encompassing more technologies, it's still not achieving the scale that it should be. It's not there yet. It's too hard to build a blockchain solution. It's that the patterns just aren't readily available and we drew a number of parallels to a technology I love and saw evolve during my career of Docker. Back at the beginning of Docker, there were people in the space that were like 'this is gonna change the world', like 'this is amazing, the way you can put any software in a box and make it consistent, this is just gonna change the way everything runs', 'it's going to change HA models'. But Docker on its own was brilliant on your laptop, but it didn't actually solve the problem and people like me, building cloud solutions, were like 'well we need a whole layer on top'. I built three generations of cloud services before I came to start Kaleido. The first one we built the whole orchestration layer ourselves. We built it, we used the Hashicorp console at the time and Zookeeper directly and we built it all, right? We've got the whole orchestration layer. And then the second generation it was like there were lots of orchestration layers you could pick between, Marathon and the like. Then Kubernetes came along and the game changed. No projects had to think about any of this stuff, there was just this brilliant API programming model and set of objects and you just used it and the patterns were there. That piece of the project of 'how do I build the cloud infrastructure?' went away. And we know that's what the blockchain industry needs. What innovators of decentralized multi-party systems need is the technology to become consumable for them, not just consumable for this specialist inside of the blockchain space, consumable for them and FireFly is our attempt to see that. To try and start a community that's focused squarely on making the orchestration layer that makes all of these technologies fit together and it embraces the fact that the block changed just one component. We see like 20 to 50 components in this, inside of these projects. Lots of them are application components, lots of them were off chain. You've got to fit the stuff together and that's what we're trying to do with FireFly, is make it easy for the people who have to worry about everything, not just the people who are worried about the blockchain piece itself. So, let's break it down for people in terms of what it comes in and exactly how it works. So, I'm a business. I've realized 'hey I could put this blockchain in to simplify this process that we currently have that's spanning multiple intermediaries within our organization' and 'so great we've got this blockchain, we've got some smart contracts or decentralized apps, whatever flavor running on top of it, but that's obviously not enough'. So how does FireFly come into that and what additional value-add does it have if you start with this blockchain application focusing on a business problem that it's solving? So, first thing is this concept of a multi-party system. That's what you're trying to build. Think about what you're trying to build is different to if you're building it on a database, centralized. What makes it different? The thing that makes it different is everybody's going to be running their own copy of the application. That's what makes it different. So, if everybody's going to be running their own copy of the application, the application is going to be integrated with a security system. It's going to be nice and have a beautiful user experience, mobile web etc., and it's going to be responsive. You're going to have a whole stack, a whole stack of tech that each individual organization needs to run, customize and integrate to their stuff. So what's that stack going to be? That's where FireFly fits. FireFly comes and says 'here's a starting point for that stack that you can build on top of', 'here's a starting point that integrates with a whole range of back-end technologies'. So behind the FireFly API, which is REST designed for developers who work in modern languages, full stack developers who live in React and typescript back ends, right? Or, enterprise developers who are used to Rest APIs and building Spring boot microservices, right? Here's a stack that you can build on top of and you can plug in behind so choose your blockchain ecosystem, find the one that's got the best enterprise tech for you, it can be Ethereum, Fabric, it can be Corda, those are the top three at the moment. So, that's where the focus is for FireFly. Choose how you're going to connect together the pipes between the organizations, right? They're going to need private exchange as well, choose the right tech for that. Maybe, we hope, come to an organization like Kaleido that's got all of those pipes pre-built or FireFly's got those pipes built in as well and the plug points to add additional pipes. So whether that's direct HDP to HDP, mutual TLS or messaging technologies with the reliability and the end-to-end encryption and just take those off the shelf and have a set of lego grips that let you do the blockchain pieces, the money party communication pieces, and then build your app on on top. The HA model should fit into the way that you build your application, the database model should fit into the way that you build your application. This component should just fit with the way you would have built the application before. You don't have to build your application differently apart from you just have to need to think about the fact your application is going to be running multiple copies and everyone's going to have their own copy of it. So, sometimes you need to figure out what state is shared, which usually most of it's going to be privately shared, that's just the reality, right? What data is completely shared? Open to everybody. And then how is the communication going to happen? And how is that communication going to be different? Because, you can share these pieces of information, the sequence of events, what's going to make it different? That's kind of the recipe but FireFly's there to try and make it 10 to 100 times easier than we've seen it be in the past. That's the goal of FireFly. Then I guess, to complement that as well you've got the usual widgets, like a nice UI for monitoring it and these sorts of pieces too? Yeah, so the intention here is this isn't a dump of the piece of bits that we've had. We've done a huge amount of engineering since the design of FireFly. It's actually a new generation of the core technology. We rebuilt it in Go, we built the explorer, the FireFly explorer, from scratch on top of it to give that live modern experience that people expect from a great technology. Because that's what we know all the open source projects that we love, do. So we want this community to be the place where that kind of innovation can happen. We've seated it with lots of components, not just the sort of core plumbing pieces but with the command line so you can have it running in 30 seconds on your laptop. You can have a full stack with three members simulated and be working with the Rest APIs. You've got full open API, free Swagger, for all of the stuff just there. But, that's as important for this project as how fast and clever the internals are, which of course, is also a big focus. When you're dealing with privacy, you have to think about what are you linking and there is a lot of plumbing inside of there that's about coordination of events, on chain and off chain, because that's a really hard problem that the individual components can't solve. And a lot that focuses on what's the right model for privacy in these organizations. So there's heavy lifting code in there as well as the orchestration pieces. And so the project's just been donated to Hyperledger from the governance perspective. At the moment it's in this sort of incubation stage because it's a new project there and then as traction grows around it, it'll move out of that. There should be people listening to this as well who are technically inclined and interested to find out about getting involved in the project. What are kind of the things you want people to do with it, apart from try it out to see if there's the potential to use it in their current projects. What would be your ideal ask for people who come across the project beyond that? So, that ask is really strong, trying to use it, seeing if it does make the problem you're trying to solve easier. If it helps you understand the problem that you're trying to solve as well I think, that's really important. We want that engagement. Come along to the community course. They're weekly at the moment, they'll fall back to bi-weekly once we've got through lots of architecture, playbacks on what's there at the moment. But, at the moment, those are weekly so you can come along. We try and make sure only the first half is a deep dive presentation and the second half is just completely open to discuss, to bring your ideas. So, come with your ideas, come with your skepticism as well and let's talk it through. And then, because it's about pluggable components, there's lots of opportunity beyond just working on the core FireFly to work on plugging in technologies. So the fact that it's multi-protocol means the Ethereum leg is very mature, the Fabric leg is actually really in the innovation stage at the moment and Jim Zhang another one of my co-founders here, he's worked on Fabric since the beginning, is helping coordinate the efforts in that space. So that's nascent and there's lots of opportunity to get stuck in. There's lots of enterprise innovation there, so you can get really stuck in on the engineering side there and the Corda one as well. We've actually had some previous proofs with real projects. There's some more innovation needed to make it fit the whole model because Corda is slightly different as a technology to the other blockchains. So that's a whole area of plugging in technologies. But there's also other technologies that can plug in the arm blockchain, like we've got IPFS and we've got private data exchange over mutual TLS but you know plug in your own messaging, plug in the messaging technology and adding building blocks. Then, one other thread which is going on at the moment which is really active and we think there's lots of innovation for is tokens. In terms of building blocks, the sort of air and water we're building an application. Tokens and how those sort of core operations of tokens, which I feel are like CRUD for databases, tokens are for blockchain. Those corporations, how those fit with the orchestration needs to happen off-chain. That's something that's really happening actively on the project. So there's loads of places that you almost certainly have skills that would fit in to the model that we're trying to enable with FireFly. It's not just about blockchain skills is a really, really important thing so the community is one where probably everyone who's an engineer has something they can bring to the community, the community would benefit from. I guess the other thing just to highlight as well is that there's no fee or anything to take part in it, it's completely open to all of the actual community there. You don't need to be a Hyperledger member or anything like that to engage with it and contribute to the project. Absolutely, it's all Apache 2, open source so it's genuinely open community. Everything that we do is in there, is in the public and the best place to get started is you can come to Kaleido, click open source and go to the FireFly section to learn a little bit about the background and our seeding of it. Then just go directly to the hyperledger/firefly git repo and you'll get to all of the open documentation, the actual source code. Repositories there's actually a bunch of them because it's a sort of an umbrella project with components underneath it and the plug-in interface. They all start from hyperledger/firefly on github and that's where all of the open collaboration happens. So apart from FireFly and just governing and growing and just making making it better and better, are you focusing on anything else right now? Are there some other things that Kaleido as an organization are working on that you wanted to highlight or future directions? Yeah, it really is just one of the things that we're doing over here, I guess a lot of our focus as an organization is on helping these unsung heroes of the blockchain space, the network operators, the organizations that form either by donations of lots of large enterprises into a group of people or actually as a separate organization. We are working with, a lot of our time is actually spent just working with those network operators, with the business networks themselves, to accelerate them to build use cases. And for that reason, we've done a lot of innovation around the model, the technical model, for how a network manages infrastructure. It's really interesting because it's not just the blockchain components, we talked about there's the application components as well, so one of the biggest things that we've actually been working on over the last year, is that evolved model for how a network manages building an application together, all the way from building and then hosting all the components. So that's from the technical side, that's a big focus for us, which is around hosting management network operations beyond just the blockchain itself. And obviously helping organizations, groups of organizations, usually with a network operator but not always, to actually deliver value. That's the other piece. So a lot of our time is actually spent building applications and helping accelerate projects. Awesome! So just just before we wrap up, I know you've spoken about how people can follow what's happening with FireFly, if anyone wants to reach out to you or what are the best places to find you? Is it Twitter, LinkedIn, by the community calls? What would you encourage? So, a couple of ways... if it's about FireFly, then Rocket.Chat is the way to go, chat.hyperledger.org, you can get us individually, you can get me directly on there. There's a FireFly channel that you can go and engage with the community there. So Rocket.Chat is great. For me personally, LinkedIn is probably a great way to get hold of me and I love to have DMs on there. Or reach out to me at firstname.lastname@example.org directly if you want to email me. Well, thank you Peter, it's been really great to catch up and also learn about FireFly as well. It sounds like it's something that's been missing from the ecosystem and so it's a big step forward in terms of enterprise and blockchain. Thanks so much Conor for inviting me. It's always always great to catch up. I know we've been working together for a number of years now and what you and Web3 Labs do for the community as a whole is is fantastic. So thanks for having initiatives like this and ways for people to share and engage together on these interesting topics. Thanks Peter, I appreciate it, cheers. you