>> Host: Live from Boston, Massachusetts it's The Cube, covering Red Hat Summit 2017 brought to you by Red Hat. >> Welcome back to The Cube'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 Mower. He is the senior director Programs and Tools here at Red Hat. Thanks so much for joining us. >> 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, Open Shift 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 we've had in a long time, and it's a 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 open shift online. 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. If this were the '90's, we would have called it a new ALM platform, but now it's dev-ops, right? It's our new approach to dev-ops. It completes the open shift experience, and makes it easier for development teams and developers to build those applications and host them on open shift online. >> Why did we need a new approach to dev-ops? >> 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 wanted to take that off the table. We wanted 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 wanted to make that simple for our customers. Second thing we wanted to do was make it really easy for developers to use containers in development, and help them get started faster. Developers can spend as much as 50% of their time just maintaining their local environment to do dev-end test. What we wanted to do was make it simple. One click, automatically create containerized development testing and staging environment without the need to type doctor commands or learn Kubernetes files, make it super simple for developers. And then 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 dev-ops 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. 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 on open source projects, plus other data that we use. 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. >> Harry: Yes. >> Harry, been to a lot of shows where we're talking about digital transformation. It's kind of a trope these days that says, software's leading the world and every company's becoming a software company. >> Harry: Or is a software company. >> Or is a software company, everything from the banks, to whatnot. Do you have some examples of what, some early customers that have been playing with Open Shift IO, how does this help them along that way, learn from your peer, and therefore know when you'll when to jump in? >> Sure. We don't have any customers on it now, this is one of those projects that we have 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. If you look at, probably one of the obvious ones that we look at are automotive companies. The four wheels and the engine is the commodity part of the car, sort of today. 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 can only go so far with hardware, it's really software that powers everything else. And so you could think of most car companies now. That's how they become software companies. It goes down the line. If you think of banking, if you don't have a mobile banking app, is that a bank you're going to choose? 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 Open Shift IO help them forward faster? >> Sure. Building software is building software. No matter where you deploy it. 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. Open Shift IO provides all the tools to do that. And then once the developer's get working on actually coding and doing the testing, and everything that the developer's 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 data environment. Like I said, Open Shift IO makes it really simple for those developers, because we can let them choose pre-defined 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. Where they're working doesn't have to be their local machine, we host it for them in the cloud, so they never had to install anything or worry, again, another thing they don't have to worry about is, is it mismatched 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, the steps are the same, and that's why we feel like it's commodotized 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. >> We want to talk big picture here about this space that you are 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 generations of going through the technology fads is one thing, now we're back to multiple micro-service 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? 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 a bug, it's how do they shift better software faster? >> And so this focus on teams, and the end-to-end process, I think is a fundamental shift that we've-- 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've 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 usuallay 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 is the new, I call it the atomic unit of app execution. No matter where they're going to execute, their app's going to be in a container. Now whatever pattern they choose to use inside that container, I think it's still up for debate,, whether it's microservices or some other sort of pattern 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-- >> And just to be clear, 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? >> Harry: Exactly. And even in the case of microservices, it depends on how many containers you're going to use. The debate is, do I put, is 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, 'cause complexity grows pretty quickly when you start to get into that world, and we're going to focus on the tools for that as well. >> 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... 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? >> So our approach in Open Shift IO, is to have developers worry up to the framework level. Everything below the framework, don't worry about it anymore, including containers. 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 a Kubernetes value, 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 my application, and how I express myself in code. And that's kind of where we, at least in Open Shift IO, that's where we see the dileneation. I don't want developers to have to worry about containers and everything below that. It should just come for free. Especially when we get in the world of serverless, where it's debatable what you're ever going to have to worry about at that point. That's the way 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 cutlure 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 out with? >> Yeah, so one of the first things we knew we had to do and decide we had to do, is we're going to build Open Shift IO with Open Shift IO So our first customers are us, ourselves. >> Rebecca: You're the guinea pig. >> We're the guinea pig, and if anybody knows anything about Red Hat, its' 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 that the product that we're building today is a direct reflection on the culture of Red Hat, because if it can work it for Red Hat, it can work for many and most companies, let me tell you (laughs). >> Can you help connect the dots between Open Shift IO and what's happening with Open Shift in adoption there? I think that speaks to the maturity and the adoption of Open Shift itself that led you to this new tool. >> Yeah, 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, Rel and other platforms. But as we went through the process of building the application, we really did realize that Open Shift is becoming our default platform. Especially for containers as applications, and what developers want to do. So we decided to maximize our efforts around building the best experience for Open Shift, because it is the future for Red Hat. So the name shift at that point, we then went from a Redhat branded name to an Open Shift branded name. I think right now the Open Shift IO name, I will admit, is a little confusing for people, and it is intended to be kind of one of the first of the family of Open Shift products. Over time, it may emerge and be part of Open Shift overall. But right now, it's meant to complement Open Shift Online. And it's the developer experience for Open Shift Online, >> And it's free, the Open Shift IO, eventually, some of what you create there ends up in Open Shift, which would be something they paid for, right? >> 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 Open Shift Online, we'll start to charge for the resources on Open Shift 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. >> Harry: Work in progress, definitely. >> Thanks so much for your time, Harry. >> Thanks for having me, it was great. >> From Rebecca Knight, and Stu Miniman, we hope to see you back here again for more from Redhat Summitt. (electronic jingle)