 Hi again Red Hat Developers, this is Jason with the Red Hat Developers Program. I'm here at day two of Summit 2017 in the Dev Zone with Michael Walker from Red Hat who's going to talk to us about the Red Hat Open Innovation Labs. Thanks Michael. And magic. All right thank you very much for the introduction. And I want to give a short and sweet overview of what Open Innovation Labs is and I thought it would be more fun to make it hands-on and do a little bit of technical work so we're going to actually fix a demo that I just gave which is now broken and we'll make it better. So my role as director of Labs and we created this 12 months ago and it's been absolutely phenomenal to take what was an idea and see where we've come over 12 months. At its essence, Labs is a residency style engagement where small teams from a customer or a partner, maybe three to six folks, they might be developers, they might be infrastructure, they might be operations, usually a product owner of some sort, comes together and works with small teams of Red Haters, usually three to six people. And it could be subject matter experts, it could be consultants, it could be engineers. The idea is we're opening the door to all of Red Hat and inviting folks in to see how we build software and co-create together. So at Labs we experiment and we use real scientific method approach. So we come up with a hypothesis and we test that hypothesis and we rapidly iterate over it to come up with something that has real business value. So what we do is build application prototypes and along the way we're doing DevOps, we're applying lean engineering principles and learning to be agile if that's a focus area. But the other interesting thing about Labs is we're really reflecting principles of open source software, principles like learning to use open standards, releasing early, releasing often and engaging with communities both inside and outside that allows us to come around a common purpose and really change more easily and be more agile. So everyone that goes through Labs gets education and understanding of how we do things at Red Hat, how we build software the Red Hat way. And so we hope that that will help catalyze change within their organization. So we come up with a set of recipes, I like to say at Labs, for changing and transforming your enterprise or relationship and that can be brought back to create more change. So that's Labs in a nutshell and then a bit about our process. So it's typically one to three months long where we're working together and we can work in a Red Hat Labs facility. We've got an amazing one getting built in Boston. We've also got one in London that will be publicly launched in two weeks time and we've got a smaller facility in Mountain View in Singapore yet to come. But we don't have to work there, we can work anywhere. We've done pop-up facilities, worked in colo spaces or worked on the customer site. The idea is over the course of one to three months, we start by getting together and doing a discovery session which is a one day exercise to figure out why we're doing what we're doing and what kind of business value we want to provide from the experiments that we run in Labs. Then we deploy something called push button infrastructure and this allows us to have everything we need to start rapid application development on day one rather than tell you anymore about it, I'm going to show you in the demo and we're going to actually deploy a push button infrastructure in a minute or two. Then over the course of the residency we code, we test, we examine and we change our thought process along the way. It all culminates in demo day which is when we get together with stakeholders and show everybody what we've built in a relatively short amount of time. Think of it like a startup going to an incubator and being able to show what's been built. Finally, we understand that Labs is part of a much bigger picture. It's sort of the first step to catalyzing change. We come up with two things in a retrospective. We recommend where to go from here from our application prototype so we build out a product backlog and have it prioritized and we also create a roadmap. How do we take the learnings and the recipes back home? We create a set of recommendations for further work efforts back at the enterprise. Let's go ahead and see a Labs in action and let's actually log into an environment and use push button infrastructure to build a Lab and let's actually write some code and see how easy it can be to start rapid application development when we're using the foundations of open innovation Labs. I want to show you two things. One is push button infrastructure. I won't talk about it, I'll just show it. The other one is delivery pipeline. Once we've got the infrastructure, what's really interesting and important is building an application with real value and along the way learning things like infrastructure as code and continuous delivery. I'll show you a little bit of all of that in our demo. First I want to show you this. This is an infographic, it's a web graphic that we created and originally it was non-functional. We whipped this thing up just to show people all of the technology that we've integrated at Labs that allow us to facilitate rapid application development but since then, we've actually given it some real functionality and so we're going to use this to deploy a real Labs environment. Now, it all starts at Labs with a container platform. Everything we write in terms of applications are containerized. This is done on purpose so that it's portable so that you can take it back home so that you can take it to a different environment whether it's on public cloud, private. Heck, you don't even have to run it in an open shift. You can run it anywhere, you can run containers which is essentially Linux. We give you a choice of hosting infrastructure. So if you want to experiment on Red Hat Enterprise Virtualization you can do that on OpenStack. Google Cloud Platform, Azure, Bare Metal. Today, I want to deploy a stack in Amazon Web Services so I'm going to go ahead and select that. And then we provide a rich set of tools for doing application development. So these are all images and templates most of which are available in OpenShift in one form or another. So you can see we can pull in and experiment things like JBoss Web Server or the mobile application platform or if we wanted to separate our business logic from application logic we can bring in BRMS and experiment with that. Now today I want to build a simple Node.js application and I'm just going to use JBoss Web Server and I'm going to have Mongo as my backing store. So I'll select those options. Please have a seat. I'm just broadcasting and I'm actually on film as well so you're now on camera. Congrats. Join the party if you like and please take a sticker. So yeah, as I was saying I've also got a tools for doing DevOps so we like to work with Jenkins which is our tool for continuous integration and continuous delivery. But we provide a set of tools and you'll notice these aren't all Red Hat tools here. In fact, I don't think any of them are. But this is how we get stuff done. So in this case I've got a code that's already out there on GitHub. I'll just show it to you. This mysterious code that's apparently Node.js application. So I'm going to go ahead and select GitHub as my code repo and I can bring other things in here. So if I wanted to do Slack for chat ops I can integrate that with my lab environment automatically, JIRA, Nexus for artifact management, testing tools, et cetera. So these are all options that are automated and ready to roll in labs. So you can see I've added all of these tools to my shopping cart on the right here and I'm going to go ahead and click submit. And what I get here is a reference architecture diagram describing all the things that I want in my labs environment available on day one to accelerate application development and experiment. So that's what I'm looking at here. It looks like icons on a page. The interesting thing is it's not just icons. We've done the hard work of integrating automation to help build all of this out and it's done in Ansible Tower. And what's powerful here is that we can deploy this environment from start to finish in public cloud in 60 minutes or less. And we can deploy it in a private data center in about 35 minutes. So if you ask yourself how long does that take in your data center, in your environment, it's usually a lot longer. It might be days or even weeks. And that's because of all of the bells and whistles you have to deal with, security and compliance and getting logins and network and storage. We have all that figured out at labs. It's fully automated. And so that allows us to begin innovating and creating new ideas from day one rather than waiting weeks to provision this entire stack for doing application development. Okay, so that's push button infrastructure. Where do we go from here? Let's go ahead and actually build a lab environment. Now we don't have 35 minutes. I want to do this in like two minutes. So what I've done is I've already set up open stack and open shift, but it's completely empty. And there's no other tools and technologies, no pipelines, no code, nothing like that. So let's go back and actually I want to build this code here, which is in GitHub. And it's a fork. So I'm going to go ahead and provide the repository URL. And I'm going to say dev zone, project and click build. And when I click build, if I'm connected to the internet, which hopefully I am. Yes, it's going to send all of the parameters that I just picked from my particular labs environment and send it to Ansible Tower. And Ansible Tower is the secret sauce behind all of this because it's got APIs on the front end. We were able to take this web app and quickly connected to Ansible and then leverage all the playbooks that we've developed over the last really two years from working with other customers and open sourcing it. And by the way, this is all open source and we love community contributions. So you can find it in the RHT-Labs GitHub repo, which I can show you later. And it's absolutely open to communities to use, reuse and contribute back. So let's go ahead and log into Ansible. Unfortunately, I just got rid of the URL. So I am going to open a new tab. Well, I'm just going to do this, right? Do a new build and open. And that may kick off two builds, but that's fine. And what you can see here is two jobs running and those jobs are actually running all the set of playbooks to set up my labs environment. I'm looking at the job template. But if we look at the job here and let's take a look at the one that I kicked off first, which I got a job ID 1708. So this is live and you can see all the parameters. Actually, this is the second one. You can see all the parameters for what I provided for it. And so it should be setting up actually two different projects that we can now use for development purposes. And in fact, if I look at OpenShift now, I've got different stages of a pipeline for my DevZone project and I've got a Jenkins pipeline that'll help me build code. So what did I not tell you? I didn't tell you what code I'm actually building. So let's go ahead and take a look. And if I click on this URL, I can show you I'm building a version of the infographic, but something is wrong. What is it? Something is different. It says attention, exact exchange. What the heck is that? That's the demo I just came from. I don't like that. Let's change it. So I'm going to put my developer's hat on for a moment. And one of the things I like to ask developers and communities of developers is if you're working in an enterprise environment, how long does it take to get your ideas from idea to production or from concept to cash? And often it can be really lengthy because environments are not built for rapid integration and innovation. So what I'd like to do is now use all of the pipeline that I've already set up to make changes to that code. So let's go ahead and go back in this infographic and I'm going to make some code changes. First, I want to change that text that says attention, exact exchange. I don't like that. So I'm going to edit the file directly in GitHub actually and I'm going to say attention dev zone instead. That makes more sense for what we're doing here. And I also did not like the icon. It was weird. It said executive exchange. I want to use the new labs icon that just came out. So let's go ahead and change that. And I'm going to upload a file. I actually have grabbed it in advance. And what I need to do here actually is rename it. So let's make this smaller for a moment and give this guy a different name because it's actually hard coded to look for something called Red Hat Logo. So it wouldn't find it if it was called Red Hat Logo Lab. So I'll name it Red Hat Logo and actually just drag it in here. I like that icon with the light bulb. This is hot off the presses. Just came out last week. So I'm going to go ahead and commit my changes to GitHub. All right. So as a developer, I didn't interact with OpenShift. I didn't interact with the push button infrastructure. I'm just writing my code, committing it, and away it goes. But what's cool is because we've used push button infrastructure and it knows about how to build this code, I can now go back to OpenShift and I've already got a pipeline ready to go to configure and build and compile new versions of my code in a containerized fashion. So I'm going to go ahead and click on the URL and log in to Jenkins. So this did not exist before we built our push button infrastructure nor did these pipelines exist. And if I go into this DevZone project pipeline, which I promise that's the name I really use when we started this demo and I click build now, it knows how to get my code from GitHub. It knows how to build it. It's a node application. It's got a template to run it. It knows how to scan it for some security vulnerabilities and it knows how to build an image-based deployment. And why is it important to build an image here to check in to the Docker registry? Because we only want to build the application once and build an image that we can then promote from one environment to the next. And that's really important because we want consistency. You know, the other real problem with a lot of real enterprise environments is manual error. Hey, I just had everything working on my laptop. Why didn't it work in Dev? And I'm going to even promote it to test. One click here. Why didn't it work the same way in promotion? In production. Well, it's because somebody introduced an error somewhere along the way. And by putting all of the application code in a compiled format with all the dependencies wrapped up into a container and then an image, that allows us to really make an immutable deployment artifact that can be deployed from one environment to the next. Okay, so I talked too much. Let's just actually look and see if we've been able to change it. And I could see here now a minute ago. I really do talk a lot. Version two has already been deployed. And if I click on it, I should now see my changes, attention to have zone and a logo that I really like, the new innovation labs logo. So wrapping it up, as you can see when we use push button infrastructure, when we use continuous delivery pipelines, we can start to iterate over good ideas and share them with others really quickly. This is powerful. And by working at labs, it gives you a chance to get out of your day to day and really do things differently and move at a different pace. So my final comments are, first of all, you can read a lot more about this. If you go to our GitHub repo where we've got all this code, it's in rht-labs. So I encourage you to check that out. That's actually our organization. We probably got 10 or more repos in terms of where we are. As I mentioned, we're launching an office in Boston this summer. We have an office in London. We'll be doing a launch party in two weeks. We're also targeting Singapore and have a small facility in Mountain View right now. But we can do labs anywhere, including an area near you if you're around. And the way we get started is by engaging for free in something called a discovery session. So this is when we get together for that day and really map out why we're doing what we're doing and how it maps to business value. So that in a nutshell is labs. Thanks a lot for watching and for joining and for sitting here today. And I appreciate your time. Oh, any questions from anyone in the audience or comments also? I'm sorry, what? When you changed the heading and the weapon. Yes. I'm glad I actually did it right. That was with no practice. And I'm a little rusty to be honest. It should have been done by someone more skilled than I. But if I can do it, anybody can, right? Yeah. Anything else? Well, thanks. Appreciate joining. And yes, stickers are available.