Welcome everyone to the weekly firefly community call. Just as a reminder, this is a public call and it is being recorded. So I just wanted to let everyone know about that today for our agenda for the first part of our call. Hayden Fuss will be presenting on deploying firefly and lots of cool DevOps related things there. So thank you Hayden for the slides you put together. And then, as always, the second half of our call will be just open discussion on whatever topics folks want to talk about. So I would know further ado I will hand it over to Hayden. Thank you Nika. Yeah. So, as Nika said, I'm Hayden Puss. I'm a site reliability engineer here at Colorado. And so I've been working on deploying firefly in various clouds recently. And so I'm here to share some of what we've learned and more just show up what we have so far. So, really excited. There we go. Sorry about that. So today what I'm going to be showing you are discussing first is just the challenges of deploying firefly because it's a multi party system and kind of the inherent challenges that come from that. I'll cover that first and then I'll introduce some cloud native technologies that help make the deployment process of firefly a bit smoother in terms of how we can create a consistent experience for various folks who want to play firefly. And then, and then I will get into a demo of actually deploying it on to Kubernetes, which will be most of the session so without further ado. So what is deploying firefly involved. If you recall from previous architecture discussions and other community calls. Firefly consists of a core that is the actual engine and sort of orchestrator of the system but then it has lots of infrastructure runtime components that it requires so there's the blockchain interface, private messaging which is fronted by a data exchange connector. And then you also have public storage that's required as well as a database. And so with all the, with the deploying firefly itself is relatively straightforward but it's the infrastructure around it that can actually be the more challenging part. And so just to reiterate, when you're deploying firefly you need a database you need a blockchain node, which is fronted by a connector, you need peer to peer storage and you need a data exchange. And so when you're using the firefly CLI which I highly encourage, if you're, you know, wanting to develop against firefly, go check it out it's, it's great. It does this all for you using Docker compose. But what about in cloud environments is is kind of where I want to take this obviously and then zooming out a little bit and thinking about firefly in more production scenarios with lots of members in a multi party system. So everyone in every member in the network would need their own firefly node, and additionally it will need to have that surrounding infrastructure that I just described. And so, and what's really important to highlight then is that components such as blockchain, the storage layer and the data exchange are all peer to peer and are requiring network connectivity between all the parties and that's a very difficult problem to solve in a multi party system This is just framing it for and then sorry the last, the last challenge we kind of face as part of this as well is each of these members could potentially be running in different cloud environments, whether it's private cloud on Prem, AWS, Azure, Google Cloud, etc. And so it's difficult to then provide a, or it can be difficult to provide a consistent deployment experience for firefly as a result of that and so that is kind of bleeding leading right into this idea of cloud native and how, as we're developing firefly actively we're also keeping it in mind to immediately have it be cloud native or as cloud native as we can and iterate from there. And what I mean when I say that I got a good quote from the red hat folks on this one is when an app is cloud native it's it's kind of what we highlighted in the last challenge is, is designed to be fried a consistent development and automated management experience across these various clouds. And so, while there might be folks who could argue that there are other container orchestrators out there the industry solution that seems to become emerging, or as pretty much emerge as a standard to solve this problem and create help create a consistent experience for cloud native apps is Kubernetes. And so, just in case you're not familiar, I'll give an overview of Kubernetes in 60 seconds, or 60 seconds ish, and then we'll get into the actual demo and some of, and you know kind of show off what we've been able to do in terms of making sure that there is a cloud native app so far. So, Kubernetes in 60 seconds. It's an open source platform for managing containerized workloads at scale. The idea is that you're deploying Docker containers across various BMS and you're needing to, you know, have a layer that's orchestrating all that and managing the between all the stock containers. And so, just kind of like how Firefly is aimed at attracting away various pieces of a multi party system like the blockchain and a few others. Kubernetes is aimed at abstracting away the underlying cloud infrastructure so you want to have the networking in between all these BMS, as well as the load bouncing in front of them, abstracted away as well as the persistent storage and, and it's you know, emerged as an industry standard for doing exactly that and it's achieved it to these sort of pluggable interfaces known as controllers, and these controllers are continually reconciling any resource you give to a Kubernetes cluster and ensuring that the state that you've asked for is actually what's getting made and so that's how it ensures containers are in the right state the storage that they might require is in the right state the load balancers etc. So essentially to give you kind of an idea of what the interface when you interact with Kubernetes is like and if you're not familiar, it's a declarative configuration, and it's aimed, and it provides, like I said that a continual reconciliation is what it limits the it's doing it for you. So, on the right what you're looking at is an example of defining a Kubernetes job. All it's going to do is spin up a Docker container using a particular Docker image, and it'll just, you know, print hello Kubernetes and sleep for a few seconds before wrapping up Kubernetes would take this job, see that the container gets deployed to a VM out in the cloud and ensure that the container either completes or if it goes into a failure mode it would you know gracefully back off on retrying until it gives up basically. So, that was Kubernetes in 60 seconds ish. I hope that was helpful if you're not familiar. I think it'll be, you know, obviously more helpful to see some real examples at this point so what we're going to show for the demo today is we're going to deploy a two member network flyer find network onto a local Kubernetes cluster that I have on my laptop. And this, what will actually get deployed to the Kubernetes cluster is firefly the firefly data exchange that's using a GPS with mtls and and Postgres, we're going to use a package manager for Kubernetes called helm to do so. And this is with a, what's called a home chart that's in the process of getting into the firefly repo, you know, this week, as we're talking so, and then I eat connect and IPFS, the blockchain and storage layer are going to be remote and they're going to be a little bit easier and like I was saying since they're peer to peer. There can be challenges with with running that locally a little bit easily so that's an overview of the demo and I'll get into that now. So wanted to first start. Sorry, just fighting. Yeah, so, so like I said, the first thing is if you were using the firefly CLI. I'm just using my Docker UI to kind of show all the containers that would get spun up in a two party network as part of the firefly CLI, you know, it's a very similar idea and so we're going to be doing the exact same thing basically but using Kubernetes and then you know some pieces of it will actually be remote. And so what I have running on my laptop is a is a tool called kind. It's aimed at Kubernetes and Docker is what it stands for and it's aimed at making it very easy to run clusters locally so an entire Kubernetes cluster is actually running in just this one container right here. And so if I do kind get clusters, you'll see I have one made called the kind cluster and that's what I'm actually logged into right now. And so what I've gotten it done in advance is the clusters already up and it's got a controller that will help manage automate certificate management which is needed for the MTLS layer and the date for data exchange. And otherwise it's just the vanilla installation of kind that comes right out of the box. So, Hey, just to clarify, yeah, you're demoing how to run firefly not on your laptop by showing it running on your laptop. Exactly. Yeah, yeah, yeah, I'm trying. Yep, yep. Yeah, the whole idea is by because of the packaging that we're using for Kubernetes this home chart that I'll show up. Yeah, we'll be able to move it from the cloud on my laptop to the cloud. Exactly. Yeah, I'm just running the cloud on your machine. Yeah, yeah, exactly. Yeah, makes sense. Okay. Yeah, no thanks for pointing that out. So, so yeah, like I said, I got the Kubernetes cluster up. We're good there what I wanted to show off is kind of what I met by home chart and a little bit of that so just like that example Kubernetes job I was showing you. So all declarative configuration for Kubernetes what ends up kind of being in order to write a cloud native app for it, you end up writing a lot of the animal. And, and so what then becomes a challenge is distributing the animal templating the animal so that it's configurable across various environments across various clouds which might have a few, you know, smaller details that need to be changed between them and things like that. And so, Helm is kind of like the RPM or MPM of Kubernetes package manager for Kubernetes it sort of provides the structure of how you format your YAML and how you package it up as a tar and then distribute it out so that others can reuse it. So we're in the process of writing a home chart so that it can be shared via Helm repo and folks could pull that down and reuse that to deploy Firefly and the data exchange kind of ala cart and configure it however they need for whether it's a post press they have running already in their whether they're using blockchain it's provided by Colorado in the SAS or their own blockchain notes. You know you name it we want it to be as configurable as possible and you know you own it as much as you can. So, and that's what this ultimately facilitates without getting into the weeds of all all the the YAML and code that has been written to make that happen. That is at a high level what what it's ultimately doing and so it's a lot like a Docker compose file if you look at the Docker compose that gets made by the Firefly CLI, but it's just, you know, cloud native is the whole point. So, that was a quick overview of the home chart itself that I'm about to show off. And then, yeah, and so without further ado, we'll get into actually deploying it so right now if I asked the cluster that I'm running in for the pods, or if it has any pods there currently none. And I'm going to what what I have what you do when you deploy a home chart is you basically provide what are called values to it, you know YAML config that are that is being used to template the rest of it. So, I have two values files one for one member called ACME another for another member called Randalls. And they're both have enough config defined for them to be able to connect or to spin up their own data exchange to spin up their own Firefly node. And then they're connecting out to a remote ETH connect and IPFS that's being hosted quite a little show off once once the Fireflies are up themselves. We have this demo dev chart written that could actually run IPFS and ETH connect locally or in Kubernetes for you as well. But like I said network connectivity and a few other pieces running blockchain itself, it's easier to sometimes just use something remote. So, yeah, so what I will first do is create what's called a helm installation I'm going to deploy the chart and create an instance of it which is called a release. And so the first release is going to use the values file for the ACME member that will stand up a Firefly node for ACME. And then we're going to create another release for the Randalls member and we'll see some Firefly containers get spun up too. So this is the interface into helmets just to go CLI, just like Kubernetes and Firefly CLI as well. And so what we're doing is an installation of it we're using the chart I was just showing off Firefly dev chart, we're providing the ACME values for that particular org, and we're creating a release called ACME Firefly that will spin everything up. So helm is noticing that a release hat doesn't exist. It's creating that and now if I do cube CTL get pods and I watch what we're going to see is a few containers kind of spinning getting going so Firefly is currently crashing only just because post postpress and Firefly DX are still coming up. Firefly DX is getting its MTL certificate through certificate manager which is a feature of the chart that we've written. And it's a controller that kind of helps automate a certificate authority within Kubernetes for you. And so once both now at Firefly DX and Postpress are up we're going to see Firefly come up shortly. And then we have a job container that is going to auto register the Firefly member into the network. So that if another member joins it can it can discover this Firefly node. So this should get going. This should finish up shortly. And as I said just to kind of show up what's at the blockchain layer. In the collider sass I've already beforehand stood up both IPFS for ACME and Randalls as well as a go Ethereum node for ACME and Randalls and then using the smart contract management feature of fire of collider I've deployed the Firefly payment and Firefly smart contracts into those blockchains. And so all that's preloaded in advance. And would be, you know, something to work towards and actually having the maybe automated as part of some of the home charts or things like that going forward. So the auto registration is complete for ACME. So we're going to now install Randalls. And then we will show off kind of the actual network that's been made and running and we'll send a transaction over and that'll wrap up. So just like the, oh, and I think it's worthwhile just to show off helm. And you can list releases and installations so I've done a helm LS and you can see this ACME Firefly release has been made. And that is what ultimately created all these Kubernetes resources that we just saw it's fun. So what I'm going to do next is install Randall, and we'll do the same thing again and just watch for it to come up. Or actually, I think we've already seen that before that's not as useful. What we can go ahead and do in the meantime is while Randalls is getting up will start forwarding the ACME Firefly node so that we can connect to its explorer and I can show that off in the meantime. Kubernetes allows you to connect to connect containers if you need to using what's called port forward. There's also other ways of actually exposing them for real external traffic, but we won't get into that right now. But so I'm just port forwarding ACME locally, or the ACME Firefly node that I stood up its API to my local port 5000 and that will also enable me to then go to its explorer. So if we go to the explorer, we've seen that there's one member in the network currently. And if we go into the Firefly system. Name space within Firefly we can see that some messages have been exchanged for registration registering the node. But otherwise there's still not another member yet. And if we list pods and a few namespace again sorry. We'll be able to see that yeah Randalls is now up and it's still registering. And once it's done registering we should see that to, we can now see two members are there. And while there's no messages in the default namespace if we go into the Firefly system there's now been some additional messages and transactions to register the second member as well. So if the other members up, we can see that the auto registration has completed. What I'm going to do next is then port forward Randalls, and then I will show using one of our Firefly sample apps, doing a broadcast over the two member network. We'll kind of explore that in the Firefly UI. I'll actually take the transaction hats and show that in the actual blockchain layer that's hosted in collido. And that will at that point conclude the demo. Yep, so the next step is to port forward Randalls and this one will listen on my local host 5001. And so now if I go back to my browser and refresh this page. I'm also now I'm now connected to the Randalls Firefly Explorer and can see the same thing on its side with in terms of members. And we haven't exchanged anything in the actual default namespace yet. And so that's the next step. So, in, in my other terminal while I have some for forwards going. I'm using. We have a Firefly samples repo in the hyperledger community. There's two applications. One is an actual UI react app. The other is a CLI and so today I'm just going to use the CLI to quickly send a broadcast from one of the members to the other. So the CLI by default assumes that you have two fireflies running on 5000 and 5000 one, and it's going to send broadcast from 5000 to 5000 one. So we should see a broadcast from ACME to Randalls using the CLI. So by just doing MPM start, we'll get we'll see that we're broadcasting data values hello and world via Firefly one which is the ACME note. So what we're seeing on the port forward from Kubernetes, you know, some requests and connections are being made. Just kind of nice and response. And then we actually see that we receive the data on the other end from the other Firefly member. And then what was printed here was a record of the actual transaction that was made on the blockchain as a result of that. So if I take this transaction hash. Go into client is data explorer. For transactions for the blockchain as that stood up. I can actually then search for that transaction. And we can look into it and so you can even see from there. Sorry, there actually knows this is right there. This was from the ACME one of the ACME note wallets, and it went to them the Firefly contract as a result. And so, you know, again, none of this data, the actual hello world was ever put on the blockchain itself only hashes and the transactions. Yeah, only hashes of the data was actually what was put on the chain. So, and you can see what method was called within the Firefly contract that facilitated that. And, and, yeah, you can see the hash data as well. And so, you know, that was a, we could even reverse it if we wanted to where we send it back and forth or send it from one member to the other but I think the last thing to show would just be to show that that popped up in both data explorers so you know we're in the default namespace on the ACME Firefly node. We see the broadcast that have been sent. And we can see the same thing on the Randalls node as well in the messages. So, that was getting Firefly working on Kubernetes locally and so, like I said to wrap up here and emphasize what this home chart would then allow is, you know, if you have your own Kubernetes cluster whether it's running in EKS or on-prem, and you have, you know, some of the infrastructure may be already pre-provisioned that would need it to be around it, you could take this chart, provide some config to it, and then deploy it out and get your own Firefly network running as well. And so, yeah, I think that that does it. I really appreciate folks giving me the time. I hope you enjoyed it. Thank you, Hayden. Appreciate the work you put into making the chart. That's great.


Live from the Frederick P. Rose Hall, home of jazz at Lincoln Center in New York, New York. It's theCUBE at IBM Z Next, redefining digital business. Brought to you by headline sponsor IBM. When we are here live in New York City for the IBM Z System Special Presentation of theCUBE, I'm John Furrier, co-founder of Silicon Angle with my co-host Dave Vellante, co-founder of wikibond.org. Dave, we are here with Catherine Porrini, Vice President of the Z Systems Technology. Welcome to theCUBE, great to have you. Thank you, I'm really glad to be here at the exciting day for us. We had a great conversation last night. I wanted to just get you introduced to the crowd. One, you're overseeing a lot of the technology side of it, you're involved in the announcement, but you're super technical and the speeds and feeds of this thing are out there. It's in the news, it's in the press, but it's not really getting the justice. And we were talking earlier on our intro about how the mainframe is back and modernized, but it's not your grandfather's mainframe. Tell us what's different, what's the performance, tech involved, why is it different, and what should people be aware of? Sure, so this machine really is unmatched. We have tremendous scale performance in multiple dimensions that we can talk through. The IO subsystem provides tremendous value, security that's unmatched. So many of the features and attributes of the system just cannot be compared to other platforms. And the Z13, what we're announcing today, evolves and improves so many of those attributes. We've really designed the system to support transaction growth from mobility, to do analytics in the system, integrated with the data and the transactions that we can drive insights when they really matter and support IT cloud delivery. So there's two threads that are out there in the news that we've wanted to pivot on. One is the digital business model. And that's out in the press release. It's all the IBM marketing and action. Oh, digital business, we believe it's transformative. That's pretty much something that's going to be transformative. But performance with the cloud has been touted. Hey, basically unlimited performance with cloud. Think of compute as a, not a scarce resource anymore. How do you guys see that? Because you guys are now pushing performance to a whole other level. Why can't I just get scale out, say, or scale out infrastructure, build data centers? What is this fitted with that mindset, or is it together? So there's performance in so many different dimensions, and I can talk you through a few of them. So at the heart of the technology in the system, we have tremendous value in from the processor up. So starting at the base technology, we build the microprocessor in 22 nanometer technology, eight cores per chip. We've got four layers of cash integrated on this, more cash that can be accessed from these processor cores than can compare to anything else. Tremendous value don't have to go out through IO to memory as frequently as you would have to in other environments. We also have an IO assist subsystem that has hundreds of additional processing cores that allows you to drive workload fast through that. So I think it's the scale of this system that can allow you to do things in a single footprint that you have to do with a variety of distributed environments separately. Coupled with unique security features, embedded encryption capability on the processor. PCI attached tamper resistance cryptography, compression engines, so many of these technologies that come together to build the system. So IBM went to the woodshed back and took all the good technology from the back room, cobbled together, because you guys have done some pretty amazing things in what they call proprietary days. It's been the mainframe back in the 60s, 60s, 80s and client server, a lot of innovation. So you guys, is that true? Would that be an accurate statement? You guys cobbled together and engineered this system with the best? Engineered from soups and nuts, from the casters up, we literally have made innovations at almost every level here in the system. Now it's evolved from previous generations and we have tremendous capabilities in the prior ones as well, but you see across almost every dimension we have improved performance, escape scalability, capability. And we've done that while opening up the platform. So some of the new capabilities that we're discussing today include enterprise Linux. So Linux on the platform, run Linux on many platforms, Linux is Linux, but it's even better on the Z13 because now you have the scalability, the security, the availability behind it and new open support, we're announcing KVM will be supported on this platform later this year. We have OpenStack supported. We're developing an ecosystem around this. We're announcing PostgreSQL Docker, Node.js support on the mainframe and that's tremendously exciting because now we're really broadening a user base and allowing users to do a lot more with Linux on the mainframe. So one of the big themes that we're hearing today is bringing in, marrying analytics and transaction systems together. You guys are very excited about that. One of, even the New York Times article referenced this. People are somewhat confused about this because other people talk about doing it. We go to Hadoop World, we talked Big Data, Spark, in-memory databases, SAP doing their stuff with HANA. What's different about what Z systems are doing? That's a great question. So today many users are moving data off of platforms including the mainframe to do their analytics and moving back on this ETL process, extract, transform, load. It's incredibly expensive, cumbersome, multiple copies of that data. You have redundancy, you have security risk, tremendous complexity to manage. And it's totally unnecessary today because you can do that analytics now on the system C platform, driving tremendous capability insights that can be done within the transaction and integrated where the transactions in the data live. So much more value to do that. And we've built up a portfolio of capabilities and some of them are announcing as part of today's event as well that can allow us to do transformation of the data, analytics of that data. And it's at every level, right? We have embedded analytics accelerators in the processor, a new engine we call SIMD, Single Instruction of Multiple Data, allows you to do a mathematical vector processing. Let's drill down on that. I want to take a quick take on this. The in-processor stuff is compelling to me. I want to drill down on that technical. Right now all the rage is in-memory. Even on the big data spark, it's got traction for the analytics. DTL thing is a huge problem. I think that's 100% accurate across the board. We hear that all the time. But what's going on in the processor? Because you guys have advanced, not just in-memory, it's in-processor. What is that architecture? What are some of the tech features and why is that different than just saying, hey, I'm doing a lot of in-memory. So the processor has a deeper, richer cache hierarchy than we see in other environments. That means we have four layers of cache. Two of those cache layers are embedded within the processor core itself. They're private to the core. The next layer is on the processor chip and it's shared amongst all those cores. And the fourth layer, I heard it, right, is on a separate chip. It's huge. It's embedded DRAM technology. It's a tremendously large cache. And we've expanded that, which means you don't have to go out to memory nearly as frequently because you have that data. Which is state-of-the-art. That's state-of-the-art today. In-memory is state-of-the-art today. You guys have taken it. Advanced inside the core. What kind of performance does that do? What's the advantage? There's huge performance advantages to that. We see we can do analytics. Numbers are something like 17 times faster than comparable solutions. Being able to bring those analytics into the system for insights when you need them. To be able to do faster scoring of transactions. To be able to do faster fraud detection. With so many applications, so many industries are looking to be able to bring these insights faster, more co-located with the data, not have to wait the latency associated with moving data off and doing some sort of analysis on data that's stale. How? That's not interesting. We really want to be able to integrate that where the data and the transactions live and we can now do that on the main. So in-memory obviously is awesome, right? You can go much faster. A best I.O. is no I.O. as Gene Amdahl would say. But if something goes wrong and you have to flush the memory and then reload everything, it's problematic. How does IBM address that? So to minimize that problem. Relative to what you hear, you hear complaints in other architectures that that's problematic. How do you solve that problem? Or have you solved that problem? Well, I think it's a combination of the cache, the memory, and the analytics capabilities, the resiliency of the system. So you worry about machines going down, failures. And we've built in security, reliability, redundancy at every level to prevent failures. We have diagnostic capabilities, things like the IBM Z-Aware solution, right? This is a solution that's been used to monitor the system behavior so that you can identify anomalous behaviors before you have a problem. That's been available with ZOS. Now we're extending that to Linux for the first time. We have solutions like disaster, recover, continuous availability solutions like the GDPS. It's now extended to be a virtual appliance for Linux. So there's so many features and functions this system allow you to have a much more robust, capable solution. Popular is Linux. Can you quantify that you guys talk a lot about Linux? Can you give us some percentage? Linux has been around for 15 years on the mainframe. And we have a very good user adoption. We're seeing a large fraction of our clients are running Linux, either all by itself or in concert with ZOS. So double digit workloads? Yeah, it's a very significant fraction of the myths in the field today. Catherine, I want to get a personal perspective from you on some things. One, you went applied physics degree from Yale, masters from applied physics from Stanford, PhD, applied physics from Stanford. And all the good graduations, by the way, you're super smart. I guess it means you can go to the schools, it means you're smart. But the rage is software defined, right? So I want you to tell us from your perspective, being an applied physics, the advances in silicon is really being engineered now. So is it the combination of that software defined? What's your perspective? What should people know about the tech at the physics side of it? Because you can't change physics. At the end of the day, the silicon is doing some good stuff. So talk about that convergence between the physics, silicon and software defined. That's a great question. So I think what sets us apart here with the mainframe is our ability to integrate across that stack. So you're right, silicon, silicon, piece of 22 nanometer silicon, we can all do similar things with it. But when you co-optimize, what you do with that silicon, with high performance system design, with innovations at every level, firmware, operating systems, software, you can build an end to end solution that's unmatched. And with an IBM, we do that. We really have an opportunity to collaborate across this stack. So can we put things in the operating system? It can take advantage of something that's in that hardware. And being able to do that really gives us a unique opportunity. And we've done that here, right? Whether it's the SIMD accelerator and having our software capabilities, our C-Plex optimizers and Java be able to take advantage of what's in that, in that microprocessor. We see that with new instructions that we offer here that can be taken advantage of compilers that optimize for what's in the technology. So I think it's that co-optimization across the stack.  But to get that, you need the infrastructure underneath it. You need the capabilities that can be exploited by the software. And that's why that- And we're seeing that in DevOps right now with the DevOps movement, you're seeing I want to abstract away the complexities of infrastructure and have software be more optimized. Here, you guys are changing the state of the art in memory, in processor architecture. But also you're enabling developers and software to work effectively. Right, and I think about cloud service delivery, right? You know, we would love to be able to offer end users IT as a service so we can access the mainframe, all those qualities of service that we know and love about the mainframe without the complexity, and you can do that. Technologies like ZOS Connect and Bluemix with system Z, mobile-first platform allowing you to connect from systems engagements to six systems of record to deploy Z services. So you can, we're trying to help our clients to be able to not be cost centers for their firms, but to provide value-added services. And that can be done with the capabilities on the mainframe. So Node, Docker, OpenStack, KVM, obviously we talked about Linux. What does that mean from a business standpoint, from the perspective of running applications? Can you sort of walk us through what you expect clients to do or what clients are doing? It's all about standardization and really expanding an ecosystem for users on the platform. We want anybody running Linux anywhere to be able to run it, run their applications, develop their applications on the mainframe, and to be able to take advantage of the consolidation opportunities driven by the scale of the platform. Be able to drive unmatched end-to-end security solutions on this platform. It's a combination of enabling an ecosystem to be able to do what users expect to be able to do. And that ecosystem continues to evolve. It's very rapidly changing. We know we have to respond, but we want to make sure that we are providing the capabilities that developers and users expect on the platform. And I think we've taken a tremendous leap for the Z13 to be able to do that. So obviously Linux opened up that was the starting point. Right. What do you expect with the sort of new open innovations? Will you pull in more workloads, more applications? I certainly believe we will. And new workloads on the platform, this is an evolution for us. We continue to see the opportunity to bring new workloads to the platform. I think support of Linux and the expanding ecosystem there helps us to do that effectively. We see that whether it's the transaction growth from mobile and being able to say, what does that mean for the mainframe? How can we not just respond to that, but take advantage, enable new opportunities there? And so I think absolutely Linux will help us to grow workloads to get into new spaces and really continue to modernize the mainframe. John and I were talking at the open, Paul Moretz at the time CEO of VMware in 2009 said, we are going to build a software mainframe. Interesting, very bold statement. Do you have a software mainframe? Have you already built it? I don't think you can have software without running on something. And so the mainframe is not a piece of hardware. The mainframe is a solution, it's a platform that includes technology, infrastructure, hardware and the software capabilities that run on it. And as I said, I think it's the integration, the co-optimization across that really provides value to clients. I don't know how you can have a software solution without some fundamental infrastructure that gives you the qualities of service, the so much of the inherent security availability, all of that is- That's a marketing, it didn't pan out, the vision was beautiful, it put a great power point together. Honestly, he went to Pivotal now, but I think what's happening is what you're talking about is it's distributed mainframe capability. The scale out open source movement has driven the want-to-be mainframe market to explode. And so what now, you look at Amazon, you look at Google, look at these power data centers, they are mainframes in essence. They are centralized, physical places. Yeah, why is it in pan out? I mean, it's moving in a direction. Well, VMware want to say the cloud is a software mainframe. Software runs on these data centers, so instead of having Rackinstack 3x86 processors, you just drop in a mainframe, or Godbox as I call it, and you have this monster box that's highly optimized, and then you can have clusters of other stuff around. But your argument is the integration is what makes the difference, that end-to-end. So Amazon makes their own gear, right? We know that now, they don't do open compute, they're making their own gear, so people who want to be Amazon would probably go to some hybrid mainframe like. Well, they're not making their own. How do you make sense of that?  To a point, though, right? I mean, to the outside of the box. Right. The way I see it is for mission-critical applications where you cannot support any downtime. You want to have a system that's built from the ground up for pure availability, for security. And we have that, right? We have a system that you can prevent failures, right? We have redundancy at so many levels. We have, you know, it's a different model. Right, when you take money out of your account or when you transfer money more importantly into your account, you need to make sure it's there, right? You want to know that with 100% confidence. And to do that, I would expect you feel more confident running that. And credit card transactions. It's not just banking. It's the same game all over again, mission-critical versus non-mission-critical. I mean, internet of things. Well, what's not mission-critical? Is my follow-up question here. I agree with you. I agree with you. Internet of things, some sensors data that's passive. If it's running my airplane, that's mission-critical. Is Nest running your temperature? Oh, you're down for 10 minutes? I mean, yeah. There are some times that we would accept some downtime? No, it's really about lumpy SLA perform. Amazon gets away with that because the economics are fantastic, right? So non, you can't be lumpy in bank transactions. So, Catherine, what about cost? Everybody says, oh, mainframe's so expensive, so expensive, you guys put out some TCO data that suggests it's less expensive. Help us squint through that. What's the... Yeah, so I think when we look at total cost of ownership, we're often looking at the savings to administration and the management of the complexity of sprawl. And with the mainframe, because you have such scale and what you can include in a single footprint, you can now consolidate so much into this literally very small environment. And the cost savings, because of the integration capabilities, because of the performance that you can contain within this box, you see end-to-end cost savings for our clients. And that break-even point is not so large, right? And so you talked about mission critical. You're doing your mission critical work on your mainframe and you have other things that you need to do that you don't consider, perhaps, as mission critical. You have an opportunity to consolidate. You can do that all on the same platform. You're not, we can run with tremendous utilization. You want to use these machines for all their work. So the follow-up on that.  He got me. I got to keep buying mainframes. You're saying now the stickiness is for the types of workloads that your clients are running, it is cheaper. That's your premise. It's cheaper and I think it has unmatched capability. Availability security features that you can't find in other solutions. In theory, you could replicate it but it would just be so expensive with people. In theory, okay. But I think the fundamental technologies and solutions across that stack, who else can do that, right? Can integrate solutions in the hardware and all the way up that stack. And I don't know anyone else who can. Tell me what, tell me in your opinion, what gets you most excited about this technology platform? I mean, is there a couple of things? Is there one thing saying that is so game-changing, I'm super excited by this, I can't sleep at night, I'm intoxicated, technically.  Well, I'll tell you, today's a really proud day. I have to say, being here and being a part of this launch, personally having been a part of the development, been an IBM for 15 years, I spent the last eight years doing hardware development, including building components and key parts of the system. And now to see us bring that to market and with the value that I know we're bringing to clients, it's, I get a little choked up. I truly honestly feel really, really proud about what we've done. So in terms of what is most exciting, I think the analytic story is incredibly powerful and I think being able to take a bunch of the technologies that we've built up over time, including some of the new capabilities, like in database transformation and advanced analytics that we'll be continuing to roll out over the course this year, I think this can be really transformative and I think we can help our clients to take advantage of that. I think they will see tremendous value to their business. We'll be able to do things that we simply couldn't do with that old model of moving data off and having the latency that comes with that. So I'm really excited about that opportunity. So this is a modernized platform, not just a repackaging of mainframe. Absolutely. Okay, great. So second final question for me that I want to ask you is two perspectives on the environment, the society we live in. So first let's talk IT, CIO, CEO. What mindset should they be in as this new transformation, the digital businesses upon them, and they have the ability to re-architect now with mainframe and cloud and data centers? What should they be thinking about? As someone who is a PhD in applied physics been working on this killer system, what is the, what's the moonshot for that CIO and how should they be thinking about their architecture right now? So I think CIOs need to be thinking about what is a good solution for the variety of problems that they have in their shops and not segment those as we've often seen. You have the x86 distributed world and maybe you have a mainframe this and that. I'm thinking to think about this more holistically about the set of challenges you need to go address as a business and what capabilities do you want to bring to bear to solve those problems? I think that when you think about it that way, you get away from good enough solutions, you get away from some of this mindset that you have about this only plays over there and this only plays over there. And I think you open yourself up for new possibilities that can drive tremendous value to their businesses and we can think differently about how to use technology, drive efficiency, drive performance and real value. We were talking last night at dinner, we all have families and kids. And there's a lot of talk about software driving the world these days. And it is, software's amazing. It's the best time to be a software developer since I've been programming since I was in college and it's so awesome with open source. However, there's a real culture, hacker culture now with hardware. So what's your advice to young people out there? Middle schoolers or parents that have kids in middle school for women, young girls, young boys, with this now you got drones, you got hackers, Raspberry Pi, these kinds of things are going on. You got kind of this homebrew computer mindset these young kids and they don't even know what Apple computer is. I would say it is so exciting. The engineering world, the technology challenges, hardware or software and I wouldn't even differentiate. I think we have a tremendous opportunity to do new and exciting things here. I would say to young girls and boys don't opt out too soon. That means take your classes, study math and science in school and keep it as an option because you might find when you're in high school or college or beyond, that you really want to do this cool stuff. And if you haven't taken the basics, you find yourselves not in a position to be able to team and build great things and deliver new products and provide a lot of value. I think it's a really exciting area and I encourage people. It's a resurgence, I'm seeing like this. I mean I went to the 30th anniversary for Apple's Macintosh in Cupertino last year and that whole homebrew computer club was a hacker culture, you know the misfits if you will and yeah. Over camp. I think there are people who grow up and always know that they want to be the engineer, the software developer and that's great. And then there are others of us and I'll put myself in that space that you may have a lot of different interests in what has drawn me to engineering and to the work that we do here has been the ability to solve tough problems, to do something you've never, no one has ever done before, to team with fantastically smart people and to build new technology. I think it's an incredibly exciting space and I encourage people to think about that opportunity. From a person who has a PhD in applied physics, that's awesome. Thanks for joining us here inside the QVP of these systems. Again, great time to be a software developer, great time to be making hardware and solutions. This is the Q, we're excited to be live in New York City. I'm John Furrier with Dave Vellante. We'll be right back with this short break.