>> Voiceover: Live from Boston, Massachusetts, it's the Cube covering Red Hat Summit 2017. Brought to you by Red Hat. >> Hi, I'm Stu Miniman and welcome back to the three days of live coverage here at Red Hat Summit 2017. The sixth key note of the week just wrapped up. Everybody's streamin' out. We've got a couple more segments. Happy to welcome back to the program a couple gentlemen we had on actually the Open Stack Summit. John Allessio, who'd the vice president of - And Nick Hopman, who's the senior director of Emerging Technology Practices, both with Red Hat. Gentlemen, great to see you again. >> Great to see you again Stu, good afternoon. >> Yeah, so a year ago you guys launched this idea of the Open Innovation Labs. We're opening these labs this year. You've got some customers. We actually had Optum on earlier in the week. We're going to have the easiER AG guys on, I should say - I was corrected earlier this week. I shouldn't say guys, actually I think it's two doctors, a man and a woman that are on. >> Andre and Dorothy. Andre and Dorothy - so really amazing customer testimonials for working through. So John, why don't you start with, you know, give us the update on the innovation lab program. Open and innovation get, you know, discussed a lot. Give us the real meat of what happens. >> So, just maybe a quick recap. >> Yeah. >> So Stu, we had about oh a year and a half ago or so, our strategic advisory board tell us, Red Hat, we really are looking for you to help show us the way in how to develop software, but also kind of help us leverage this culture that Red Hat has and developing software the Red Hat way. And so we worked with about a dozen clients across the globe, got a lot of great feedback on what they were looking for. We created an offering and then we launched it, as you said in Austin at Open Stack Summit. And now we've done many engagements in Europe and in North America across multiple different industries. We had here at the Summit this week actually two clients talk on the main stage, both Optum and easiER AG. And both of them have been through innovation lab engagements. Very different industries, very different clients, but what it has proven in both cases is it's really been a great way and a great catalyst to kind of spark innovation, whether it's within an existing IT infrastructure or building out some capability in particular customer environments, like we did with Optum, or kind of taking some ideas. And I'll let Dorothy and Andre tell their story when they come on and work with you. I don't want to take their thunder. But a great way to show you how we can work with a start up and really help them kind of take their vision and make it reality in an application. >> Yeah, Nick, you know, we've done so many interviews about the various pieces, lots of interesting business. It reminds me of that kind of pipelining that you talk about. One of the announcements this week was Open Shift IO, which it helps with kind of the application modernization. Can you maybe help us, you know, put together how the products that Red Hat does and what you're doing in the Open Innovation Labs, how do those go together and mesh and new stuff come in? >> It's actually kind of at the core of what we do anyway. So, we are building on top of the foundation, the technologies at Red Hat's core platform. But in a residency with Open Innovation Labs we are tying in other technologies, other things outside of the Stack. But with like Open Shift IO, what we've created was what we called the push button infrastructure. How are we showing with the process and everything to innovate on top of the Red Hat technology? How do we accelerate that journey? And so we created what was called the push button infrastructure to show that foundational acceleration, and Open Shift IO is actually now kind of part of that core. And adding in other components, other technologies that Red Hat has, whether it's our ISV partners, things in Open Shift commons, all those things to accelerate the application development experience. And so I think with Open Shift IO and as Red Hat continues to evolve in the development kind of tooling landscape, you're going to see how we are helping our customers do cloud data of application development more so than ever before. >> Yep, and maybe to add to that too, Nick, we were talking to a client this morning about some of their challenges and their priorities for this current physical year, And that particular client was talking about Jenkins and a number of non-Red Hat technologies as well because at the end of the day, our customers have Red Hat products, have non-Red Hat products. I think the great thing that maybe you can mention is when you look at that push button infrastructure that we've built, it's not really a Red Hat thing, although it clearly is tied to the Red Hat technology. But it's even bigger than that. And I think that would be important for the team to understand. >> Yeah so we actually have online is what we call our text stack, and it allows the customer to kind of select the current technologies that we've currently got integrated into our push button infrastructure, and it's always evolving. So I think what we're trying to bring to the table from a technology perspective is our more prescriptive approach. But it's always changing, always evolving. So if customers are wanting to use x or y technology, we're able to integrate with that. But even more so, if you take that technology to the foundation, put a couple of droplets of the Red Hat DNA and the culture is really where that innovation and that inspiration kind of where it's - it's culminating on top of it. So they're building out the applications, like the easiER AG examples. >> John: Yeah, excellent. >> It's great, I always love - By the time we get to the end here, oh I see some of the common threads. You know, for example, Ansible's acquired a year and a half ago, boy we've seen Ansible you know weave it's way into a lot of products. >> Nick: Sure. >> Was talking to Ashush just a sort while ago. And the Open Stack commons, which reflected what you were just talking about is customers are coming, they're sharing their stories. And it's not all Red Hat pieces. One thing I think, I go to a lot of technology shows, and it's usually, "Oh, well we want to talk about solutions." But by these pieces, and Red Hat at it's core it's all open source, and therefore there's always going to be other pieces that tie in. How do you extend as to how much of this is driven by the Red Hat business versus you know the problems of the customer? I'm sure those mesh together pretty well, but maybe some learning you've had over the last year that you could share on that. >> Sure. I think one of the great starting points Stu is what we try and do in every case is start with what we call is a discovery session. So it's one of our consultants, or one of our solution architects really going into the client and having a discussion around what is the business problem we're trying to solve, or what is the business opportunity we're trying to capitalize upon. And from there, you know we have a half day to a day kind of discussion around what these priorities are, and then we come back to them with the deliverable that says okay, here's how we could solve that problem. Now there will be areas that we of course think we have Red Hat technology that absolutely is a perfect fit. We're going to put it in and make that as a recommendation. But there's going to be other technologies that we're also going to recommend as well. And I think that's what we've learned in these Innovation Lab engagements. Because often it's a discussion with IT of course, but also a discussion with line of business. And sometimes what happens in these discovery sessions is sometimes it's the line of business and IT perhaps connecting for the first time on this particular topic. And so we'll come back with that approach and it'll be an approach that's tailored to that customer environment. >> One thing kind of pivots a little bit from the topic of the technology, but I mean the culture and how we're doing this. I mean we are working with ISV's and things of how they could come through the residency to get things spun up into Open Shift commons and get their technology in the Stack or integrated with Red Hat's technical solutions. But on the other hand, you know really when they come in and they work with us, they're driving forward with looking at you know changes of their culture. They're trying to do digital transformation. They're trying to do these different types of things, but working with that cross-functional team. They're coming up with, oh wow, we were solving the problems the wrong way. And that's kind of just the point of the discovery session, figuring out what those business challenges are is really kind of what we're bubbling up with that process. >> Yeah, I'm curious. When I think to just open innovation, even outside of the technology world, sometimes we can learn a lot from people that aren't doing the same kind of things that we've been doing. I know you've got a couple of case studies here, customers sharing their stories, but how do we allow the community to learn more? When they get engaged in the innovation lab are customers sharing a little bit more? We know certain industries are more open to sharing than others, but what are they willing to share? What don't they share? How do you balance that kind of security if you will of their own IP as separate from the processes that they're doing? >> John: Sure. >> It's actually kind of interesting, we had a story this week, we have an engagement going on in our London space, which will be launching in a week and a half. But they're going on right now. And there was a customer that was kind of coming through for a regular executive briefing if you will. And we walked him through the space. And they saw the teams working in there and they were before in the sales kind of meaning, they were a little bit close-minded and close-sourced if you will. Trying to not want to share some of their core nuggets of their IP if you will. And once they saw kind of the collaborative landscape, and this is not even technology based, but just the culture of an open conversation. You know I hate to overuse - you know the sticky notes everywhere, the dev ops. I mean they were really doing a conversation with the customer that was engaging. And all of a sudden the customer that was there on the sales conversation goes, "I want to do this session, I want to go through this discovery session with you guys." And so I think customers are trying to do that. And the other thing is, in our spaces and in our locations, like Boston, we are actually having two team environments, and we've designed it to try and create collisions. So they're basically on two sides, but there's also a common area in the middle where we're trying to create those collisions to inspire that open conversation with our clients as well. Some may be comfortable with it, some might not be as comfortable with it, but we're going to challenge them. >> Nick, I love that term collisions. There's a small conference I go to in Providence. Haven't made it every year, but a few times. It's an innovation conference. And they call it the random collision of unusual suspects. It's the things we can learn from the people we don't know at all. Unfortunately, we're too much. You know, we know the people we know. We know a lot of the same information that we know. If somebody outside of the like three degrees of separation that you might find, that next really amazing thing that will help us move to the next piece, it brings me to my next point. You mentioned London and Boston, how do you decide where you're building your next centers, what's driving that kind of piece of it? And, you know, bring us up to speed as the two new locations, one of which if we had a good arm we might be able to throw a baseball and hit. >> Excellent, so let me just start by first of all saying, you know part of what we're doing here is it's this experiential residency is what it is. And that residency can happen at a client location, at a Red Hat location, or even a pop-up you know kind of third party location. And quite frankly, over the course of the last year, we've done all three of those scenarios. So all three of them are valid. As far as it relates to a Red Hat facility, what we try and do is find a location if we can that's either co-located with a large percentage of Red Hat clients, and or maybe Red Hat engineering. Because oftentimes we'll want to bring some of the engineers into these sessions. So, Mountain View, where we have a center today was a natural 'cause we have some engineering capability out on the west coast. And Boston is of course very natural as well because we have a very large engineering presence here in Boston. In fact, I'll let you talk a little bit about the Boston center 'cause that's going to be our next one that opens here in just a few weeks. So maybe Nick, talk a bit about you know what we're doing in the Boston center, which will be, if you will, our world wide hub for Red Hat innovation. It's not just going to be the Boston center, it's also going to be our world wide hub. >> No pun intended that it's in the hub that is Boston. >> You got it, you got it! >> Excellent. >> So you know, what are we doing in the innovation center, and the engineering center, and the customer briefing center all co-located in Boston. >> Yeah so it's actually going back to the collisions. We've even try and create collisions in our own organization. So it's actually an eight-shaped building. We've got four floors, or two floors on each side. So kind of effectively four floors. Engineering on one side on two floors, and an EBC on a floor above the Open Innovation Labs, and the Open Innovation Labs on the third floor if you will. And there's actually floor cut-outs, so people you know if they're coming in from an executive briefing, they can see down, see what's going on there. And then engineering on the other side. And the point there is that open culture just even within our organization, working with the engineers across the board, getting them over into our space, working with us to solving the problems. And showing, you know, I think the key point that I would hit on there is really trying to inspire customers what it's like to work in a community. So community powered innovation. All those types of things. And so the space is trying to do that. The collisions, the openness obviously, flexibility, but also what we're trying to do is create a platform or a catalyst of innovation. And whether or not it's in the location or pop-up location, we're trying to show the customer some of these principals that we're seeing that's effectively allowing Red Hat to drive the innovation, and how they can take that back into their own. So, you know the locations are great for driving a conversation from a sales perspective, and just overall showcasing it. But the reality is we've got this concept to innovate anywhere. We want to be able to take our technology, our open culture, everything you would want to use and go be able to take that back into your organization. 'Cause our immersive experience is only you know, it's kind of camp for coders or camp for the techies if you will. So you know that's working well, but that's not long term. Long term we have to show them how they can drive it forward, you know with themselves. >> Where do I sign up for the summer program? (all laugh) >> It's coming this summer. >> So Boston will launch in the end of June. >> End of June, early July. >> And the June timeframe we had, I don't know how many dozens of clients, and partners, and Red Hatters go through in hard hat tours this week, here at the Summit. And then in two weeks, we'll open in downtown or really in the heart of London. >> Stu: Alright, yeah, quick flat flight across the pond to get to London. Anything special about that location? >> I think just overall the locations all have a little bit of uniqueness to them. I they're definitely - we did design them to inspire innovation, thinking outside the box. So I think you know, if you go visit one of our locations you might a couple kind of hidden rooms if you will. Some other unique things. But overall, they are just hubs in general for the regions. Hubs of technology and innovation. And so from the go forward perspective I mean we are trying to say, you know, Red Hat is doing things different, thinking different. And these are kind of a way to show it. So trying to find that urban location that is a center point for people to be able to travel in and be able to experience that is really kind of the core. >> So London will open in two weeks, and then we're already working on blueprints for Singapore. >> Singapore, yeah. >> For our Asia hub, and had some great conversations with our leader for Latin America about some very initial plans for Latin America as well. So you know, we'll have great presence across the globe. We'll be able to bring this capability to customer sites. We've already done that. We'll be able to do pop ups. 'Cause even in some cases customers are saying you know we don't want to travel, but we want to get out of our home environment so we can really focus on this and have that immersive experience, and that intimate experience. So we'll do the pop ups as well. >> Driving change, we are seeing that that's the best way. Especially with this kind of, you know, the residency. It is a time box. So if we get them out of their day to day, some of the things, you know, sometimes are the things that are holding them out. Get them in the pop up location, get them outside of their space. All of a sudden their eyes open up. And we had a large retailer, international retailer that we did a project with on the west coast, and getting them out of their space got them coming back. The actual quotes from their executives and the key stakeholders were like they came back fired up. >> Stu: Yeah. >> And they came back motivated to try to make change without our organization. So it's disruption on every level. >> Yeah, you can't underestimate the motivation and the spirit that people come out of these engagements with. It's like a renewed sense of, "I can do this." And we saw that exactly with this retail engagement of really already working on preparing for Black Friday, and putting some great plans in place and really building that out for them. >> John Allessio, Nick Hopman; we always love digging in about the innovation. Absolutely something that excites most people of our industry. That doesn't? Maybe you're in the wrong industry. >> Exactly. >> We've got a couple more interviews. Stay tuned with us. I'm Stu Miniman, you're watching the Cube. (light music)

>> 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)