 Live from Boston, Massachusetts, it's theCUBE, covering Red Hat Summit 2017, brought to you by Red Hat. Welcome back to theCUBE's coverage of the Red Hat Summit here in Boston, Massachusetts. I'm your host, Rebecca Knight, along with my co-host, Stu Miniman. We are joined by Harry Maurer. He is the Senior Director Programs and Tools here at Red Hat. Thanks so much for joining us, Harry. Thanks for having me. So I want to start out by talking about the product launch that you are announcing this week, a new set of developer tools, OpenShift.io. What does it do? What does it not do? Break it down. Sure, absolutely. So on the first day of the summit, we announced probably one of the largest developer tools announced since we've had in a long time. And it's a new, brand new product. It's a hosted online environment for building cloud services, whether you choose to do that as a microservice or a monolith or whatever architectural pattern you choose. We provide end-to-end tools for development teams to build them and host them on OpenShift online. So when I say end-to-end, what that means is it comes with everything development teams need to plan, code, analyze, and deploy their applications. And if this were the 90s, we would have called it a new ALM platform. But now it's DevOps, right? So it's our new approach to DevOps. It kind of completes the OpenShift experience and makes it easier for development teams and developers to build those applications and host them on OpenShift online. Why did we need a new approach to DevOps? Yes, exactly. So with this release, we were really trying to solve three fundamental problems. The first is we see a lot of our customers spending probably too much time and money to integrate and maintain their tool chains. We know customers have entire teams dedicated just to integrating all the tools that they need and keeping it up and running. We want to take that off the table. We want to make it really simple for our customers just to get coding and not have to worry about creating this entire end-to-end environment. We feel like a lot of this stuff has been commoditized in some way and it's not really differentiating. If you can integrate your tool better than mine, it doesn't really help you produce better code at the end of the day. So we just want to make that simple for our customers. Second thing we want to do was make it really easy for developers to use containers in development and help them get started faster. So developers can spend as much as 50% of their time just maintaining their local environment to do Dev and test. What we want to do is make it simple. One click, automatically create containerized development, testing and staging environments without the need to type Docker commands or learn Kubernetes files, make it super simple for developers. And then the third thing we want to do which we think is really unique is help developers make better decisions. This is one of the things that gets overlooked in the whole DevOps process is that developers have a lot of freedom of choice to choose things, basically anything off the internet that they want to use. And a lot of times development teams and developers aren't quite sure if it's the right decision. And so we're taking an analytics-based approach to helping solve that problem. We've created a new AI service that's built into the platform that analyzes their packages that they choose based on 15 years of history that we have working in open source projects plus other data that we use. And it really helps developers and we help developers make better decisions because we recommend packages based on that information. So if we see a package that they chose that might have a known vulnerability or that is one that developers frequently don't use, we flag that for them and offer suggestions for better ones for them to use. Nudging them in the right decision, right way. Harry, been to a lot of shows where we're talking about digital transformation. You know, it's kind of a trope these days that says, you know, software is eating the world and every company is becoming a software company. Or is a software company. Or is a software company. Everything from, you know, the banks to whatnot. Maybe, do you have some examples of what, you know, some early customers that have been playing with OpenShift.io, how does this help them along that way? You know, learn from your peer and therefore you'll know when to jump in. Yeah. Well, we don't have any customers on it now. This is one of those projects that we've been developing over the past year and we really just announced it today. But we did take a lot of feedback from customers and saw what they were doing. You know, if you look at, you know, probably one of the obvious ones that we look at are like automotive companies, right? You know, the four wheels in the engine is the commodity part of the car, sort of today. You know, much of the decisions you make are based on the technology that you choose. So it's really important for them to differentiate at the technology level. And, you know, you only go so far with hardware. It's really software that powers everything else. And so you could think of, you know, most car companies are now, that's how they become software companies. It goes down the line. You know, if you think of banking, if you don't have a mobile banking app, is that a bank you're going to choose, right? And so it's, you know, it's, you know, it's pretty obvious examples of companies that are now software companies. So let's, if I'm an automotive car and saying, okay, I got to worry about autonomous vehicles and all the competition, how will OpenShift I.O. help them move forward faster? Sure, well building software is building software. No matter where you deploy it, right? And so the process that you go through to get your team to envision the project, to set up the project and then divvy out the work and then have the work be done, OpenShift I.O. provides all the tools to do that. And then once the developers get working on actually coding and doing the testing and everything that developers do, one of the things that we provide is, like I said, every developer struggles, whether you're developing for something in a car or somewhere else, struggles with the idea of setting up my local environment, setting up my dead environment. Like I said, OpenShift I.O. makes it really simple for those developers because we can let them choose predefined technology stacks. So in the case of the automotive maker, they can set a corporate standard for what type of technology stack they want to use. Developers choose those stacks and then we automatically create a containerized environment for them to work off of. And that where they're working doesn't have to be their local machine. We host it for them in the cloud. So they never have to install anything or worry. Again, the other thing that they don't have to worry about is it mismatch from everybody else working on that software? So we ensure consistency across the team and what's going in production. So we minimize the risks there. And it doesn't matter if you're building a banking application or an embedded application. Those, the steps are the same. And that's why I feel like it's commoditized at this point. It really is non-differentiating. So if we can streamline that whole process, we feel like it's the right decision for all developers. I want to talk big picture here about the space that you're in. Before the cameras were rolling, you were telling us about your prior career at Microsoft, but you've been in this developer evangelism. You call it an evangelist space for a long time. Can you tell us how it's changed over the years? Yeah. So the obvious durations of going through the technology fads is one thing. Now we're back to multiple microservice type architectures and those sorts of things. So the technology trends and fads always come and go, but I think there's one fundamental shift that is sticking more. And it's not necessarily about the individual developer. It's about development teams. It's how do you get the entire team to function well? How do you build not just better code, but better applications? And how do you fix that end-to-end experience, right? Because at the end of the day, the way developers add value to your business isn't by writing another line of code that doesn't necessarily have bug. It's how do they ship better software faster? And so this focus on teams and the end-to-end process I think is a fundamental shift that we've, well I wouldn't say it's a shift, maybe it's a maturity that I've seen over the 20 years almost that I've been doing this. And so that's why we're really honed in on that. And I think another thing, people ask me questions about, we see these new modern types, new modern trends in application development, mostly containers and microservices, and they usually put them together. And I try to tell people not to do that because they're two separate things. And I think the one thing the industry has made a decision on is containers. I think that that is the new, I call it the atomic unit of app execution. No matter where they're going to execute their app, they're not going to be in a container. Now whatever pattern they choose to use inside that container I think it's still for debate whether it's microservices or some other sort of pattern that they want to use. So I think focus on teams and shift to containers and a new type of level of isolation I think are two big things to see. And just to be clear, right? You're saying that if I'm choosing microservices I'm probably going to use containers but just because I'm using containers doesn't mean I'm using microservices. Exactly. And yes, exactly. And even in the case of microservices it depends on how many containers are you going to use. Do I put, is it a service per container? Is it some level of services per container? I think there's a whole set of technology there to help manage people moving into that space for, because complexity grows pretty quickly when you start to get into that world and we're going to focus on tools for that as well. Yeah, I want to get your opinion. The question is also how much does the developer, where in the stack do they need to worry about? Can they just focus on writing the application? Do they have to worry about what, how far underneath it do they have to worry about? What's your thoughts, things about, we talked about containers, Kubernetes going, the whole serverless development function as a service. How do those fit into your thinking? Yeah, so our approach in OpenShift.io is to have developers worry up to the framework level. Everything below the framework, don't worry about it anymore, including containers, right? We, if you saw the demos on the Summit keynote, all of that was containerized and we never once typed a Docker command, you never saw Kubernetes file, you never saw anything about containers. We just did it all for you. What you did see is choices around the frameworks and the components that I want to use inside of my application and how I express myself in code. And that's kind of where we, at least with OpenShift.io, that's where we see the delineation. I don't want developers to have to worry about containers and everything below that. It should just come for free, especially as we get into the world of serverless where, you know, it's debatable what you're ever going to have to worry about, right, at that point. So that's where we see it. When you're talking about workplace culture and you said that there's a really big emphasis on teams and helping teams make better decisions, collaborate more effectively, Red Hat is known for having such a powerful culture, a culture of candor, a culture of risk taking, a culture of openness and transparency. How does that translate into the kinds of tools that you are coming at with? Yeah, so one of the first things that we knew we had to do and decided we were going to do is we were going to build OpenShift.io with OpenShift.io, right? So our first customers are us, our cells. You're the guinea pig. We're the guinea pig. And if anybody knows anything about Red Hat, it's exactly what you said. We have a very diverse, very geographically dispersed, very opinionated set of people at Red Hat, right? And so we had to take all that into account when building the application to satisfy our team first. And so I would say the product that we're building today is a direct reflection on the culture of Red Hat, because if it can work for Red Hat, it can work for many, most companies, let me tell you. Harry, can you help connect the dots between OpenShift.io and what's happening with OpenShift and adoption there? I would think that it speaks some to the maturity and adoption of OpenShift itself that led you to this new tool. Yeah, so when we first started to build the product, which was a little over a year ago, we wanted to build a product that was going to service the entire Red Hat portfolio, which included Bare Metal, RHEL, and other platforms. But as we went through the process of building an application, we really did realize that OpenShift is becoming our default platform, right? Especially for containerized applications and what developers want to do. So we decided to maximize our efforts around building the best experience for OpenShift, because it is the future for Red Hat, right? And so the name shifted at that point, and we then went from a Red Hat branded name to an OpenShift branded name. And I think right now, the OpenShift.io name, I will admit, is a little confusing for people, and it is intended to kind of be one of the first of the family of OpenShift products, right? Over time, it may emerge and be part of OpenShift overall, but right now it's meant to complement OpenShift online, and it's the developer experience for OpenShift online. And it's free, the OpenShift.io, eventually some of what you create there ends up in OpenShift, which would be something they'd pay for, correct? Yeah, and we're trying to figure out what that model is right now. I think right now it is all free. We don't have any intentions to charge for the tools themselves. I think as developers use it and then they consume more resources on OpenShift online, we'll start to charge for the resources on OpenShift online. That's probably the most obvious model, but that's still all stuff we're trying to work out as a company. It's a work in progress. Work in progress, definitely. Thanks so much for your time, Harry. Thanks for having me. It was great. For Rebecca Knight and Stu Miniman, we hope to see you back here again for more from Red Hat Summit.