 Live from Boston, Massachusetts, it's theCUBE, covering OpenStack Summit 2017. Brought to you by the OpenStack Foundation, Red Hat, an additional ecosystem of support. And we're back. I'm Stu Miniman with my co-host, John Troyer. Happy to welcome back to our program, Chris Wright, who's the vice president and chief technologist at Red Hat. Back to back weeks here in Boston. You've been up on stage and kind of a couple crowds. Chris, what's new with you? Well, right now I'm a little bit tired. I don't know about the two weeks in a row of big summits, but we're spending a lot of time talking about what we're doing with a combination of OpenStack and containerized platforms, like for us that's OpenShift built around Kubernetes. And so that's a big piece that's new, something that I'm focused on. And a lot of areas that touches into how do these components, or how do the technologies go together as components? Yeah, new technologies. I think that's a great topic. I saw these tweets coming into it, and it was like the Kubernetes and OpenStack sandwich and to eat one without the other, do I really need this one? Does containers and Kubernetes, it's been a discussion for a couple of years, does that obviate the need for OpenStack? I think we know Red Hat's position, but maybe you can help tease that out for us a little bit. Yeah, absolutely. I mean, I think it's really important to think about what task are you solving? What job are you trying to do? And in that context, pick the right tool for the job. And so there is this reality, which is infrastructure exists, and you need software to help manage that infrastructure. And I think we've put a lot of, as a community, we've put a lot into making OpenStack, that infrastructure layer. And if you look at it from a, so that's more of an infrastructure ops perspective. If you look at it more top down from the application point of view, you've got application orchestration, and pick a tool, a good tool for that job. And to us, that's Kubernetes. It does a spectacular job of helping build out an application sort of multi-tiered or microservice based type architecture, where your goal as an application developer is define what your app needs and just deploy it, and underneath the infrastructure needs to support that. So I think it's important to look at that combination and even look at it as layers. I like to draw an analogy. Back in the day, which wasn't that long ago, we had physical servers, hardware at the bottom, an operating system that creates a layer of abstraction between this heterogeneous hardware environment and an application. Maybe you evolve a little bit, your applications aren't all written in C, you need a higher level language, runtime like Java, Ruby, whatever. So a couple of different layers between the hardware and the application. And today, we've got your hardware as a data center, you need some infrastructure, hardware level management down at the bottom, and you still need that kind of application, higher level application view of the world, like OpenStack at the bottom and Kubernetes supporting the applications on top. Let's talk a little bit about applications and about application modernization. If we look at the through line, again through ancient history, which was only a few years ago, the beginnings of OpenStack, AWS and Amazon were a big topic of conversation there. We talked a lot about pets and cattle and kind of got used to that metaphor of us. Now we talk a little bit more about stateful and stateless, but also in the container conversation, I'm hearing a lot more about stateful applications, about enterprise applications, about containerizing legacy applications, about OpenShift as a platform for all your applications. Is there, and we're here specifically in the context of OpenStack, OpenStack Summit, at this point, are there different infrastructures for, say, legacy applications and for modern cloud native applications? Can people start to approach them using the same set of tools? Well, it's an interesting question because part of that is what do you want to do with your legacy application? People always ask me, should I containerize it? Like, well, you should ask yourself why? Just because the containers are cool doesn't mean you should immediately jump to containerizing your application. I think what we always are struggling with is understanding how much can you move forward into these modern paradigms of stateless applications and templatizing your images and really managing your state externally and pushing configuration state into the application image at runtime versus the legacy that we are all very familiar with which is all that stuff is kind of lumped together. And as you're trying to move forward, one piece that you can benefit from is adding automation around any task, including managing a stateful server which could be a VM or a container as well as certainly the stateless pieces. So I look at it from the point of view of how can you get more efficient? Automation is a key to that and the promise of containers as the next generation stateless everything is the same discussion we had with cattle versus pets. And we start to realize that you have a lot of investment in stateful portions of your application. What you're really trying to do is find the right balance and the bridges between the fast moving new parts of your apps and maybe the legacy part that could really be the core transaction processing that's running your business. Chris, we've seen some maturation of the base technology for the last year we talked about the big tent now, how large it gets, even this year there's now the open stack days as to all the everything from Ansible and Cloud Foundry and lots of other pieces. Where do you see is kind of where we are today for the stack and where some of the interesting areas that Red Hat in particular is working to help mature the solution. Actually one thing I like is narrowing some of the focus. So I was never a huge fan of big tent just in the sense of there's a lot of work to be done in those core projects in open stack. And then some of the new pieces in term maybe adding security and security infrastructure. And for us we spend a lot of time thinking about not just the different services. People ask us DNS as a service and services that expand away from the traditional basic compute storage network. Some of those are really critical. Some of those I think might be better served closer to the application. But we really are thinking a lot about how we can do not just deployments but also the day two operations of the platform. So now you're building out a big distributed system and what is the most efficient and cost effective way to manage that infrastructure. That to me I think is interesting. And you've heard it for a while about maybe open stack is a scale out web app that we could run as containerized services and manage it with the container orchestration platform. Those kind of things I think are interesting because it starts to really leverage what's the best tool for the job. And again if you want to bring in outside the open source days, bring in outside projects as kind of sister projects, I think that's a great way to do it. So we don't have to bring everything under the same big tent. Let people specialize and excel. Yeah absolutely. Something we've heard quite a bit is right, with too much air under the big tent, like I said, need to narrow down a little what we're saying. Matureing some of those core pieces, you mentioned security. I feel like since I started coming here four years ago, Neutron always requires some tightening of the knobs and pulling things down. Anyplace particular you think that we've made good progress in the last year, anything we should highlight or things that still the community needs to nail to make this even better? One thing I'm excited about is in Neutron. One of the things that we built in Neutron was a collection of different agents that make up essentially an SDN controller that was the default choice for Neutron, which is ML2 of yes. And it's served us well, it's gotten us this far. It's built around OVS as the virtual switching layer, but definitely brought in some complexity and it took a while for it to really get to the maturity level it's at now. Relatively in relatively short order, we built something in the OVS community that centralizes some of that logic and configuration data storage around virtual network topology management, created a consistent single agent that sits next to OVS and have a very simplified plug-in on the Neutron side. And that's something that we're going to bring, we're working at how can we bring that into our platform and help simplify the picture. And it's not a really kind of sexy thing with a bunch of new features, it's really about keep it simple, get the expertise from the right communities and I think that's an important way to look at it. I think we tried the last couple of years, some of us made comments. It's a good thing when some of the basic building blocks are boring, right? Customers, IT departments don't like risk, boring, sometimes keep my job. Yeah, I mean, speaking to that, I mean, hey, simple is very sexy. So can you speak at all to maintainability, operability, upgradeability, day two and beyond and open stack, that was always, in the early days, right, that was a concern. People thought you had to bring together a bunch of computer scientists even run it, which wasn't necessarily true then. I take on it from talking to people here, not true today. We're getting good feedback from our customers that it's, you know, I like to remind people you are building a distributed system. So there's inherent complexity in that. But, and some of the challenges associated with that are understanding how transactions flow through that system and then the associated debugability. And if you've got kind of hard to pin down performance issues or things like that, you need the right tooling. So part of that is just getting the right data out of the infrastructure. Call that logging, telemetry, monitoring. And so building that into the platform, I think is important. And getting the right data out of the platforms that you can do analysis, I think is really where we are now. And so first it was just get it deployed. We're well past that. Now it's get it deployed, get it up, get it running forward, rolling it forward and doing rolling updates. Something that we've spent a lot of time at Red Hat focused on both in the community and then in our products. So 100% important. And one of the things I like to talk about is we think of it from the point of view of the customer. And we don't want to create unnecessary change or backwards incompatible change that they can't move forwards. We're always looking at a measured kind of strategic set of changes and evolution so that we can bring our customers forward as this technology changes. Speaking to say the community for a bit. This is actually my first summit. Been a watcher from afar. And I wasn't quite sure what I was going to see here in Boston this year. The tech track has been split off a little bit. But even here I see very enthusiastic folks. Still very feels very much like a community. Lots of t-shirts and branded swag people proclaiming that they're open stackers. Can you comment at all on the evolution of the community over the years? Kind of where you see it now. The other thing I'm struck by is real world deployments. This is not just a bunch of vendors getting together. There are actual people here who are implementers. Yeah, that's right. So first of all, I love the community. It's a good, it's a high energy place. I'm an engineer. I spent a lot of time in the open source communities. And one of the things I loved about open stack in the beginning was that energetic feeling that you get being surrounded by a bunch of other people who are passionate about the same subject as you. And the format's changed a little bit. We don't have the same by design overlap of the development developers summit and the more project wide, industry wide open stack summit, but that doesn't mean we don't have a lot of engineers here and developers. And it doesn't mean we've kind of lost our soul and we're only over here focused in the business vacuum. And I think that's part, testament to just the community and the type of people who are involved across the board, both on the more developer side and on the business side. And then something that I'm glad you brought it up. It's important to stress that this is a vibrant community building real platforms that are really helping companies change how they run their businesses. And it's not only private cloud. That's primarily what we focus on, but open stack also gets used to build out public cloud. So it's a growing, growing kind of market as well. Yeah, I wonder if you have any commentary on just the people that still help build it. I mean, one of the things I always loved in the early days is there were a lot of the users, you know, NASA started at the beginning, many companies here when you pull up stack analytics, you know, the other category is still the biggest. You know, Red Hat is the largest corporate entity that has employees there, but as on the outside, people are like, oh, well, you know, HP took all their stuff and moved it over to SUSE and certain companies come in and out, the people building it, any comment on how that's changed over the last few years? I think that you're always going to get a few core vendors that are going to be able to do the deepest investments. And that's certainly an important part, but you also need that long tail. And that's inclusive of other companies that are providing support and services around the platform and then people who are building it themselves and deploying it themselves in their companies. And when I talked to some of the foundation folks, they really like to highlight that kind of diversity of people involved in the community. And my experience is without a great breadth of diversity, a really diverse community, projects just aren't as dynamic and ultimately could stagnate. So here I see we have got good diversity, both, you know, deployers, implementers, operators, as well as developers across the board from vendors and internal kind of DIY shops. And that's critical to the health of the community. You can see some open source projects, in my opinion, kind of get caught up in the contributor community only. And they kind of, the danger is you don't want to lose track of the operator community, which is can be people who are contributing, but you know, is can be much broader, especially as the platform matures, right? And it's even, I mean, I could pick on your language for a moment, it's one of these semantic things. Contribution comes in so many forms. So I think it's fair to say people often conflate contributor and developer or code committer. But a contribution is a bug report, contribution is documentation, a contribution is explaining to us why this is a difficult workflow. So there's a lot of different ways to consider a contribution. We actually need all those. Community isn't just developers. It's developers and users and the value is that we're close together and we're working directly. There's not a lot of barriers through, you know, commercial agreements and things like that to bring together both users and developers. There's so much change going on in the industry. We talked about containers some, we were talking to Lou earlier about serverless, would love your take on that. But how do you make sure that people stay focused enough to work on those things that need to get done and aren't just working off on the next new shiny? New shiny. Yeah, well I think, Squirrel, we touched on that a little earlier with just that boring, there's value in boring. And so we serve an enterprise customer base and they're really looking for stability. And there's big challenges in building out systems and maintaining their stability without getting distracted by the next new shiny object. And so part of what we do as a company is help our customers consume change in a measured, safe, sort of stable way. Which means at the same time that we're investing in the core platforms, we're also looking forward and looking ahead and understanding what's next. And so we were early investors in the container space. We're absolutely looking at serverless ourselves to understand what's the value of that and it comes back to the customer, what do they need, what do they get from that. Simplifying operations is a core theme and where we've been going from, you own the entire server as a pad or special snowflake to all you care about is your business logic and your lines of code and everything else is managed for you and in the sort of function as a service or serverless environment. That's a trend that I think will continue but we can't forget the layers that we're building and they have to be stable. We don't want everybody to be distracted by new shiny. All right. Chris, as you look forward, what's exciting you moving to the next summit? We still have kind of the six month release which I think they've modified a little bit but as we look forward, what are you looking forward to? Well, I think we're seeing a continued strong relationship between the container community and the OpenStack community or the Kubernetes community and the OpenStack community. And that's something that I look forward to continuing to get to the point where we actually have joint projects that we're looking at together. We've got Courier already in OpenStack. It's a way to simplify networking for container networking on top of OpenStack. There's also work in the hardware accelerator space. So how do you enable GPUs or FPGAs for highly specialized workloads? We talk a lot to labs like the Oak Ridge lab that we recently announced. And those are HPC type environments where virtualization always sounded like a penalty. And if you can create the right runtime environment that might include this GPUs or FPGAs for highly efficient vector processing, you start to untap a new world of users or tap into a new world of users. And we know that machine learning is really also getting a lot of hype and interest right now. It's going to be an important workload on top of OpenStack. We already see that with some of our users. They're using machine learning to help build out their applications. We're also seeing those kind of things put into the public cloud. Those kind of GPUs and add on processors. So this idea of a homogenous C of x86 servers that turns out the cloud is a little more interesting than that. It's the cloud has a little more features than just that endless whites. John, I'm sure you're going to tell me hardware matters again. Hardware always matters. It's a great starting point to make it, to simplify it, make it homogenous. And then that addresses some significant portion of the market. And then you look at, well, okay, there's a bunch of other needs out there. And so one of the projects we're working on with Massachusetts OpenCloud is looking at how can you do specialized clouds? And that's, HPC is one example. Machine learning or big data analytics platforms is another example. That's I think interesting and it does, maybe it helps expose some of the features and hardware that are evolving and you're not just looking at a plain old vanilla platform. Yeah, although they're, so they're, obviously there's OpenStack based public clouds. A lot of the deployment is OpenStack based private cloud. Of course, there's still the big two or three or four public clouds that are going on. How do you see both OpenStack and your customers? I don't know, embracing this kind of multi-cloud hybrid world. What's the model? Are there separate stacks for separate clouds? Are people, does the Kubernetes and OpenShift then become the peanut butter that spreads over everything? We're seeing a lot of success with our customers with that, the peanut butter analogy. So it is, that's why I kind of liken it to that hardware operating system, higher level language like Java and application where Java was the portability layer. Here I see similarities with that picture and Kubernetes and application orchestration done with containers as that, that a way to create, whether it's portability or at least consistent runtime environment so that your operations teams and your developers are using the same tools independent of that underlying infrastructure, which I think, again, the infrastructure doesn't go away. Somebody somewhere is managing it, whether it's off-prem in the public cloud or whether it's on-prem. The other thing that we see with our customers is public cloud is a very real part of their strategy as is on-premise, depends on the workload and public cloud is never which public cloud provider do I pick, it's which public cloud providers am I working with? So it is a complex environment and having consistency across that complex environment I think really helps both developers and ops teams. All right, well, Chris Wright, we're going to have to leave it there. I always appreciate having the conversation with you at all the events and glad you got to have two weeks of Boston. We'd love to do some more CUBE events over in the Portland area that was the first open stack that the CUBE did. So thanks so much for joining us. We'll be back, getting towards the end of day one of three days of live coverage. Thanks for watching theCUBE.