PurePerformance - 057 Ensuring Blockchain Performance with David Jones

Episode Date: March 12, 2018

If you still believe Blockchain is just about Bitcoin or that Blockchain is a super safe, high performing platform that simply runs then listen in to this podcast.With David Jones ( https://twitter.com/davidlewisjones ) –AIOps Evangelist – we learn about the different use cases of Blockchain technology, the two top frameworks Ethereum ( https://www.ethereum.org/ ) and Hyperledger ( https://www.hyperledger.org/ ), and also discuss how to monitor both usage and operation of Blockchain to ensure performance for end user applications. As a great read check out his recent blog post on AI-based Monitoring to ensure Blockchain Performance: https://www.dynatrace.com/blog/using-dynatrace-ai-based-monitoring-ensure-blockchain-performance/

It's time for Pure Performance. Get your stopwatches ready. It's time of Pure Performance. My name is Brian Wilson and with me as always is my co-host Andy Kravner. Hello Andy. Hey Brian, what's happening? Not much. There's a lot happening.

There is a lot happening, but a lot happening in current events events but we won't go there but anyway yeah so we just you know so to our listeners who might have heard the previous episode which we recorded yesterday yes i am still sick but you know live this is you know a couple weeks later so i'm not still sick a couple weeks later if you're you're concerned but you can you can tell i have a lot more energy in my voice so well you need a lot of energy because there's a lot of money at stake. The topic today is going to be blockchain and also Bitcoin. As of today, December 12th is the date, 17,729. One Bitcoin equals to a dollar.

One Bitcoin is 17,727. don't even get me going on bitcoin there's so much i can't stand about it um but i won't yeah let's talk let's talk more about blockchain in general though because exactly and actually let's let's let's introduce now our uh our guest of honor right now this is a special guest right because we we talk a lot and i don't want to cut you off with that but this is a tricky one because we talk a lot about repeat guests, right? And this guest, this is technically his third time being on one of our podcasts. So in a way, you might say he's our first three-timer. However, his other two times were on our other podcast, Pure Performance Cafe, which is our shorter form version.

So it's sort of like a kind of different category he's in. So I don't know if we can officially give him the three-timer for pure performance. It doesn't count the same. I will call him an honorary pure performancer, though, for sure. He's awesome. And go on. You do the introduction, so you say his name. Well, David Jones, or as we call him, Jonesy.

Or Louie now. Or Louie now. Are you with us? I am. I am. Sorry, you got me laughing. So Jonesy, I'll call you with the name that I'm used to. Maybe a quick introduction on who you are and what you do. And also, please help us to understand what is this whole blockchain all about. I believe many people still think it's Bitcoin only, but there's a lot of other stuff to

it. So enlighten us. Yeah, absolutely. Well, hey, listen, first of all, thanks, Brian and Andy, for having me back. It's my pleasure. For any new listener, my name is David Jones. I work for a company called Dynatrace. Recently, I wrote a blog article that actually talked specifically about some of the complexity around monitoring a blockchain-based application.

Now, a blockchain-based application, a blockchain itself is really meant to be sort of a decentralized sort of distributed digital ledger. That's probably the easiest way that you can describe it. And the idea is that with these digital ledgers, you can create contracts and exchange them back and forth across different entities or actors. And the idea is that every time that you are making one of these exchanges, that there is a record that is being kept as part of that blockchain. And so there is, you know, in industry in general, in e-commerce in general, there is a significant amount of interest right now by many of the major players out there in blockchain technology. And the idea is that blockchain can be utilized in the sort of topic du jour is around Bitcoin and how it is an application of blockchain. That's clearly a financial sort of IBM commercial recently, you're talking about using these blockchains to ensure,

I think the one that comes to mind that I kind of enjoy is ensuring the safety of making sure that a tomato makes it from the farm to your table. And so that's clearly a really sort of interesting application of what a blockchain could potentially do. So these blockchains themselves are, they are written on a number of different software platforms. And these software platforms have their own inherent complexity. And when you build them into your applications, they are just going to be living in this really sort of complex ecosystem.

And that's ultimately one of the main things I sort of want to talk about today is, you know, blockchains and what they, you know, the applications that they reside in, the complexity that's required to actually manage and make sure that these applications are behaving the way that we're expecting them to. So, Jonesy, two things I want to comment on there. Number one, the funny thing about your tomato story, right? Because exactly what you described, I think they're substituting tomato, IBM possibly even, for another very popular plant over here in Denver because that seed-to-sale model you talk about is very, very much in strict compliance and regulation in states like Colorado.

So it's very, very interesting that IBM made that parallel there, And I wonder what's behind that. The other thing I wanted to just say was, I was reading about blockchain ahead of this. Security is one of the big factors of it, right? Because when you talk about the ledger, and this is why I think it has such an appeal in certain ways, is you cannot change anything previously in the blockchain without changing everything else that comes after it. So it's very secure in that way. There's no way to go back and erase or modify the files that came before the other ones without basically destroying the rest of the blockchain. So I think that's one of the big appeals in these situations in the financial institutions. That's why, besides the decentralization, that it's almost unbreakable in a way, unless someone I'm sure will find a way to do it. So I have a question now.

If I understand this correctly, or maybe I don't understand it, but let me ask you. If I would build an application and I want to leverage this tomato blockchain environment where I want to add information to, like, you know, I'm part of that delivery chain of maybe getting the tomato and picking it up. And it's part of that. I'm part of that process. Would I, as an application developer that provides software for that to kind of record that activity, would I simply use an API that somebody is providing to me that actually hosts the whole blockchain for the tomato sequence? Or would I build the blockchain into my application? I assume it's the it's the first read somebody says I run the blockchain for tracking tomatoes from seeds to consumer and Andy happens

to write one of the applications that allows farmers or people that do the packaging to actually say he was packaging that tomato into that box. And I'm using APIs as well. Yeah, yeah. No, that is actually, Andy, that is pretty much exactly what's going on here. So someone would be, some author out there would be writing an application that would contain the actual blockchain itself.

And then the people that want to access this would be using exactly what you described, essentially an API to make requests into this. Now, this is the kind of interesting thing that's going on in the industry around blockchains is that it's kind of funny how many people talk about blockchains is that nobody like it's kind of funny how how many people talk about blockchains and then how many people actually understand how the blockchains themselves get generated like what's what's the actual code base that's running underneath everything to make this work and so when we talk about you know blockchains they they almost take on this sort of mythical, well, we're going to have this blockchain and it's going to be part of our application, but nobody really understands what that means. Here's the short and sweet of it. And this is the interesting thing.

It's that blockchains are actually built out on top of really sort of commonly understood technologies. And from an underlying technology standpoint, they are not particularly special in and of themselves, other than being this sort of digital ledger. There's two main competing technologies right now that we're seeing the vast majority of organizations sort of gravitate towards. One of those is very popular specifically when it comes to using blockchains as sort of a cryptocurrency, and that is called Ethereum. Now, the Ethereum project is essentially built out on top of a language by Google called Golang or the Go language. you know, platform is available out there. People can actually, it's, you know, they could, they could literally, someone could create their own cryptocurrency if they wanted to using something like Ethereum. Now there's that for that sort of seed to consumer or tomato to table, however you want to describe that, that type of blockchain application would be more likely based on something that's called Hyperledger.

Now, Hyperledger is, again, interestingly enough, it is a platform that is also built out on Google's Golang. And so the processes that are actually doing the computation of the blockchain themselves are written in this language called Go. And all of these, both approaches, either Ethereum or the Hyperledger, basically both of them have very specific sort of APIs. And that's how you would be making requests basically into these sort of blockchain-based applications and and so andy you're you're absolutely right in that sort of synopsis and so to to bring the example that means there will be some type of institution uh that would run the blockchain itself assumingly on a distributed system right Because that's obviously what this is all about. So that means you install, you run your Ethereum or your Hyperledger in a distributed environment

and basically providing as a service, your API to that consumer of that blockchain, your farmers to produce it, your distributors, your supermarkets and all that stuff. Is this right? That is exactly correct, Andy. So what becomes really interesting about this is that, you know, a lot of the technologies that are involved in doing this and most of the projects that we're seeing are utilizing very sort of, you know, commonly understood platforms like the cloud, for example. And you can very easily deploy these blockchain-based platforms into something like AWS or out into Azure. Or if you wanted to host it yourself, you could just as know, just as easily do, you know, something with Pivotal, for example, like using Cloud Foundry as the basis for building out one of these platforms.

The actual, you know, technology that the blockchains are based on, these are, you know, these are fairly well-known, fairly well-understood technologies. That being said, they exist in very sort of complex deployments. And what I mean by this is, so you can imagine that you've got, say you're using Ethereum or Hyperledger, it doesn't really matter, but you're using one of these different platforms. So you have some processes that are running within your environment. Now, those processes could be running directly on a virtualized machine, but more often than not, what's going to happen is these processes are going to run within complex cloud environments that are perhaps taking advantage of, you know, sort of, you know, the elastic scalability and capabilities that the cloud provides. And so those, you know, these processes, this Ethereum process that's running, you know, in, say, Golang could be running just as easily in a container. And in that particular case, obviously, when you start deploying these blockchains out into an elastic, highly scalable, often ephemeral sort of cloud-type container-based deployment model, things get really complex really quick.

And so it basically introduces a whole bunch of really sort of interesting technology challenges. And I think, um, the, this API approach is new to my understanding. So thanks for, for covering that because from my, my understanding of the way it worked with, um, with say Bitcoin was, it was a distributed blockchain where everybody had a copy of the blockchain who was engaging with it as opposed to calling into an API, which meant that there had to be replication along the blockchain network, which also meant that as the blockchain grows, in a distributed way, you're managing this larger and larger and larger file.

And when we were talking about having this discussion, I kept on thinking, how is this going to be practically useful in real institutions? Because the attractiveness of the Bitcoin style of it, I think, is that being decentralized opens it up for all sorts of nefarious uses, but it's not really maintainable. So by having it in a centralized location, not only can you manage it better, it could probably scale better because you have it in a single location. But then when you're talking about having it in a single centralized location, you can actually monitor and make sure, as you're saying, as it gets really, really complex, you can make sure that it's running healthy and things are going well with it. Is that true then too? So, and that's why we see this general trend towards, you know, most of the projects that at least I've had conversations with have really focused around Hyperledger as opposed to the Ethereum. There's, you know, the Bitcoin example is exactly how you just described it.

And so that's, you know, what you have to, if your blockchain based application is a cryptocurrency, then it has to be widely distributed and you run into a whole bunch of challenges around doing that. But for the more commercially specific blockchain examples that were, for example, for following a tomato to table sort of example, in that particular case, you are very likely going to be talking about an application that's based upon, as I mentioned, something like Hyperledger, or there's probably other more proprietary blockchain platforms that are being developed by some of the major vendors out there. But Hyperledger is a perfect example of this.

And the idea is that Hyperledger has essentially this sort of fabric model that takes into account things like these different sort of, you know, you know, assets, you know, basically being able to then tie these assets to the, you know, different sort of, you know, chain codes, which sort of is tracking capability. And this is essentially what we use for, you know, understanding different levels of trust and verification across our node types. And then there's going to be all sorts of other capabilities that Hyperledger sort of brings to the table around the actual ledger features, the controlling the privacy through limiting the channels to access this, the security and membership services, being able to also prove consensus on this. So in that particular case, to how you described it, when you talk about a blockchain application being used in that more specific sort of commercial example where we're not talking about using it as a distributed cryptocurrency,

then yeah, you're right. This is going to be something that is going to be more manageable from that standpoint. And so from a monitoring perspective, then I see two major use cases. On the one side, it is the applications that are using and calling into blockchain to either access data or add something to the blockchain. And then I assume you want to monitor the performance of these calls and because you want to make sure that if you are relying on the blockchain API from a certain vendor, that it's not going to slow your application performance down. And the other use case would then be you are actually hosting one of these blockchain based

ledgers. And you obviously want to make sure that you have enough capacity and you scale up so that you can actually secure a certain SLA to your end users. Is this kind of right? So the one that is consumer of a blockchain, you want to figure out, you know, is it fast enough and not impacting my application performance? And on the other side, you are actually running blockchain for a certain type of application to actually, you know, and then expose the APIs to the outside world and make sure that it's stable, it's running, and it has the right capacity. Yeah, no, you're absolutely right, Andy. Those are the two main sort of use case scenarios from a monitoring standpoint that really sort of come to the top.

Applications that are calling into a blockchain-based API or service, you're absolutely right. You will need to understand the performance impact that calling somebody else's sort of blockchain API is going to have on the performance of your application. And obviously, if you're providing one of these blockchains, you know, you'll need to understand the performance of all of the different components and processes that are running. And, you know, this is where, you know, from a monitoring standpoint, if you are creating your own, if you're thinking about creating your own, you know, blockchain service that others can then access, in that particular case, you're going to have to, you know, you're going to have to be thinking very hard about, you know, the complexity that's involved in all of the different parts and layers of those applications. Everything from not just managing, obviously, the underlying infrastructure that these applications

are going to be based on, but understanding the performance impact that you're that you're in this particular case, you're you're the processes that are running those blockchains are having on that infrastructure to even being able to understand, you know, the, you know, the complexity of those of those blockchain applications when they are, you know, entering into states that are, you know, they're they're throwing messages out into log files and, you know, being able to understand, you know, when those messages are occurring because, you know, they are all, you know, this complexity that really sort of surrounds these, you know, blockchain-based applications is going to be very difficult for many organizations to manage. And if these organizations think that they can use the same approaches that they've used in the past to manage them, I think they're going to be in for a really sort of rude surprise because these blockchains, they're adding an additional layer of complexity into what are already complex environments. And help me one more thing to understand a little bit better. So if I would base, let's say, an installation of blockchain, let's use Hyperledger, that means I would run one or multiple instances, obviously, of that core process that runs on Go.

And the reason why I would add more instances of this process, whether it runs in a container or on bare metal, is the only reason scalability? Or is it also kind of making like the more distributed nodes I add, the more secure the whole thing is? Is this kind of, is it just, again, scalability? Why I would add additional containers that run my blockchain? Or is it also security related? So my understanding is definitely from a scalability standpoint, that's why you would want to be running more of these processes. From a security standpoint, the security, if you recall, it's actually kind of inherent to the actual blockchain itself.

But therein lies the rub. The more secure the blockchain becomes, the more processing that is required. The more processing that's required, the more nodes you want to scale out to, right? So they kind of go, they are sort of one in the same. I could almost see security auditing being required. You know, back a while ago in the Bitcoin realm, there was an issue, I think it was,

and I'm not sure if I have the story absolutely correct, so don't hold it against me, where there was some compromise to the blockchain, right? And they had to fork and start over or fork from that point on. But the reason why that's so important is that with something like the decentralized, the Ethereum style, with it being decentralized, there's like a full transparency. If somebody is going to break that blockchain and try to manipulate it with that distributed style. Everybody knows about it. Whereas if you're running it internally, let's say there's,

and I'm not saying there's some grand conspiracy of banks, but let's say there's a couple of banks that are using it for some sort of, um, you know, just transferring funds, you know, wire transferring funds around within, in, uh, you know, a closed circle of financial institutions. If you have one central component of it or one copy of that chain only, someone could theoretically go in there and make a change and not, nobody else would know about it. Whereas if at least like maybe each participant on a much smaller scale did have some sort of replicated instance of it, there would be that automatic inherent auditing

in there for security, which again then would require, Andy, as you're going to, more instances of them running, more communication between those instances. And that would also then require faster performance and monitoring to make sure all those channels are opening and talking to each other. I would agree with what you're saying. The interesting thing about, and let's use some of the, like I hate to go down this route, but let's talk about some of those sort of interesting scenarios that we've seen sort of crop up with the sort of cryptocurrency-based approaches to blockchains

and Bitcoin being the obvious one. There's actually been a number of interesting sort of hacks that have occurred out there that are well-documented, well-publicized. There was certainly the one back in February of 2014 2014 that, you know, comes to mind. So, you know, even attacking a public ledger like Bitcoin, you know, it is certainly something that is, you know, possible. It is something that is, you know, we've seen examples of it happening. So, you know, the blockchains themselves, you know, they add a, you know, they definitely add a, a level of security, but they're not, you know, in and of themselves, they are not unbreakable. They're not unbreakable from a, from a, from the standpoint of, you know, a hacker who is actually a malicious actor trying

to, you know, interact with them, But they're also, they are also not, you know, unbreakable from the, you know, from the standard sort of, you know, operational sense of managing a complex application. Here's the perfect example of that. So, you know, recently in the past couple of weeks couple of weeks, the news has all been about how Bitcoin has just exploded in value. And one of the more interesting pieces of information happened, I think it was last week. And that a failure to the point where people that are trying to access the exchange were getting like 503 errors. And a 503 error, for people that are unfamiliar with this, is usually directly attributed

to something going wrong on the server side. That is a very severe server- side error. It brings the user to a screeching halt. And in that particular scenario, that just emphasizes that these blockchain-based applications, whether or not it's a cryptocurrency or if it's more of a private, very specific commercial application of blockchain, they do need to be managed. These things in and of themselves, you know, are not unbreakable. They need to be managed in the way that you would manage, you know,

any other type of, you know, commercial application. And so what that means is that you need to apply a certain amount of expertise and capability when it comes to monitoring them. The complexity that they have is going to be as complex, if not more complex, than any other application that you have out there. So these things are not foolproof. You need to have eyes on them. Yeah, for sure. Yeah. So also, Jonesy, you wrote a nice – I think we should link to that. You wrote a nice blog article.

I think we mentioned it earlier, but we want to definitely link to it. It's called – in this case, obviously, using Dynatrace AI-based monitoring to ensure blockchain performance. I think a really cool piece to get started and learning more about it. Is there anything else? Do you know of communities where people can read up on blockchain that people can go to, whether it's online or maybe some conferences,

in case people want to know more about it, that we can reference them to? Yeah, so the one that I've been following is in case people want to know more about it that we can reference them to? Yeah. So the one that I've been following is a number of the different LinkedIn discussion groups on blockchain. That I've been getting actually probably my best intelligence about what's going on in the industry. It tends to be very relevant and it tends to be very timely.

So that's definitely what I've personally been using. But also, as I mentioned, the Ethereum project, there is a community that is certainly built up around Ethereum. Hyperledger is another example. There is a community that is built up around Hyperledger. So definitely getting involved and having a look at those communities as well. Ledger is, you know, another example, there is a community that is built up around Hyperledger. So, you know, definitely getting involved and having a look at those communities as well. Cool. Awesome. Anything else we should cover? Any other final thoughts before we kind of wrap it up? So, you know, the, here's the, here's the interesting thing from my standpoint.

You know, I've talked a little bit about, actually more than a little bit, I've talked about, you know, the whole concept of, you know, blockchains existing in now in the industry, what I've been seeing is most of the literature, most of the information around blockchains is based upon the activity of the blockchain and not the underlying infrastructure of the blockchain. So don't fall into the trap that if you've got, if your organization's concept of monitoring your blockchains are monitoring sort of the transactional health, that's what the blockchain does. But you need to monitor the infrastructure that the blockchain is running on because the infrastructure is what the blockchain is, right? So if you're not monitoring that and you're only monitoring the, you know, how many exchanges has occurred, you know, my block details, my mining information, my network activity, my wallet activity, if that's all

you're paying attention to, you are exposing yourself to a significant amount of risk in that a technical issue can crop up and bring your blockchain-based application to a screeching halt. And as I mentioned just previously, this just happened, you know, in the past couple of weeks and, and everybody saw it. It's, it obviously can get ugly, not to be a naysayer, just folks need to be aware that they've got to monitor this stuff and they have to put the same diligence into monitoring this, that they do everything else, if not more. Right. Cause at the end of the day, it's still a process running on a host. Exactly. Yep, that's what it comes down to.

Interesting. Excellent. Andy, then, would you like to summon the Summaryator? Let's do it. Yes, we shall. So here's what I learned today. First of all, I think there's two major use cases from a monitoring perspective. The one use case is, are you running blockchain for a particular scenario? We talked about the seed to consumer or tomato to table.

And I'm sure there's many other examples like financial transactions, obviously, packet delivery, and I'm sure there's many medical records. So you either are a provider of blockchain by using one or the other framework that is already out there. Then obviously, it's about monitoring how fast your blockchain really is to the outside world. So that's one use case. And the other use case is if you're using an external blockchain so if i for instance write an application that is going to put data into an existing blockchain so for instance record

a certain transaction or record a step along a production process then i want to call the blockchain i want to make sure that this call to an external API is not slowing me down and therefore impacting my end users. So I believe these are two things I learned today. Thanks for the references to Ethereum and Hyperledger. There's a lot of great material out there where we can learn more. I believe we're in the early stages, but we also, as Jonesy said well, we have to really think hard about performance.

And it's very complex because these environments can get very complex and you want to make sure that you're not getting to a screeching halt as what happened not too long ago with bitcoin so yeah i love it it was a great great session and it's a topic that is obviously new and hot and i think there's a lot of stuff still to learn but hopefully this was a good way to get started yes i agree um i'm going to take my little stab here uh the first thing i learned was that if i was a developer and knew a lot about blockchain i could probably like make a lot of money selling the state of colorado a blockchain platform um the other thing that I want to point out is,

as I was doing a lot of research and reading for this, there's a lot of out-of-date data out there. The idea of the, what's the ledger one called? I'm sorry, Hyperledger. The Hyperledger use case, I didn't see any references, not that I was doing extensive research, but everything that was coming up was in terms of Bitcoin blockchain and so many naysayers about saying why that blockchain is terrible. It doesn't scale. It become, you know, all these problems that exist with that

type of blockchain. And in my mind, I was thinking, I don't see how this can be used to anybody's advantage outside of something like Bitcoin. And obviously there's things like Hyperledger, which is a similar but different enough model where these things do work. And this kind of reminds me of the early cloud days. And I'm going to give credit to the Harvard Business Review. I was reading one article, and again, this is from a year ago already but they were talking about whether or not blockchain is a disruptive technology or a foundational technology and I don't know enough about it to pick a side but I do definitely see the foundational technology type of way because

this isn't meant to be replacing disrupting an entire industry. It's changing. It can be used to change the foundational basis on which current things already exist and run. It's maybe kind of swapping out for a different way of doing that, which may prove better in the long run, which means aside from saying, Hey, we can already monitor the performance of that from the process and host style. If it is more foundational, that means there is going to be a slower yet steady adoption. As we saw, you know, 10 years ago with the cloud, it was like, yeah, it's cool and all, and something will probably happen with it to nowadays, you know, where it kind of had a slow adoption and now it's everywhere because of the disruptive technologies like Docker that were built on top of it.

With blockchain, I think, you know, again, process, host monitoring, absolutely critical. And there is, I believe, time to evolve and figure out the best way to actually evolve the activity of blockchain, because there's probably a bit more runway before that really picks up really large scale. So it's definitely very exciting. Jonesy, I learned a ton from it. So thank you so much for being on today. My pleasure, guys. Awesome.

Well, hopefully we'll have you back on the proper show sometime, and you and I still have to maybe catch up on a postmortem of the Black Friday stuff. So hopefully that'll air before this one airs. But anyway, any last words from anybody? Nope. Muget.

Okay. Well, thank you all for listening. Thank you. Thank you.