 Live from Boston, Massachusetts, extracting the signal from the noise, it's theCUBE, covering Red Hat Summit 2015. Brought to you by Red Hat. Now your hosts, Dave Vellante and Stu Miniman. Welcome back to Boston, everybody. This is theCUBE, SiliconANGLE Wikibon's live production of Red Hat Summit. Paul Cormier is here. Paul Mahatma Cormier. Good to have you on theCUBE, in reference to ignore us. They ignore us, they laugh at us, they fight us, and then we win. Gandhi, famous for saying that. Welcome to theCUBE. Thanks very much. Thank you very much. Sort of something we live under every day. So you saw that progression, back when you're selling t-shirts out of your trunk. Yeah. When nobody was paying attention. Yeah, we actually saw that progression all along the way. And so we sort of kept track of it all along the way. You can almost see the delineation points across each of the points. Now that we've conquered the OS in the data center, and we move out to the rest of the infrastructure, the same thing is happening. So you're from the Boston area, you're like a good fight. What was the fight part like? I mean, what were they fighting you on? Well, I'll give you a great example. It's a tough question I get asked all the time, but something that's confused. One of the things that we do is we sort of put together our open stack with RHEL and our KVM. And we got, the only time in my career I got in the Wall Street Journal, it was a smear thing on how bad we were because we weren't open, has nothing to do with open. It has to do with what we can credibly support in the enterprise. And all those three layers are tied together. For example, networking goes from the service all the way through the Linux kernel all the way up down to the KVM layer. So how you can put those out as separate layers and be reliable is beyond us. And so that's why we do it. But our competitors got upset with that and fought us and said we were being unfair and said we weren't being open. When in fact, we've still, every day, put everything back to the open source community, but we said we could not support it. Two different things. I remember that. Actually, I think it was, you could not, wouldn't certify it. Is that right? Can't cert, same thing. Certify or support is the same thing. So what certification means is that we certify that we can support that. If you have an issue, that we can get to the bottom of the issue. When it's between two companies, for example, we certify RHEL on Microsoft's hypervisor. We have an agreement with Microsoft that if we run into an enterprise, a problem in an enterprise site, we'll work together to resolve it. We're certified together. I remember that little kerfuffle and I remember saying at the time, I didn't understand it. So I think I read a blog that somebody put forth and we talked about on theCUBE. So just to clarify, everything you do goes back to the open source community 100%. You're like John Mattock and see no CD about that. Every line of code. 100%. Now my qualifier, I said this morning, if we acquire a company that doesn't have open source technology, it may take us 60, 90 days to get it through the process. But your promise is you'll get it there. Absolutely. Okay, and then you choose the configuration that you will certify and support. And you can't support an infinite number of configurations. Exactly right. Our number one priority is rock solid platforms for our enterprise customers. And so we'll never say we support something that we don't feel we can give that experience on. And the decision to what to support and what not to support is, I presume an economic decision. Is that right? Like how many customers there are, what the demand is for it, how much it's going to cost you to support it, what the return is going to be? It's a part of it. I mean like from a hypervisor perspective, we support three. Our own VMware ZSX and Hyper-V from Microsoft. That's an economic decision. For us to support a multitude of hypervisors to be very costly, those are the three that are in the market today. And so we get as much scale by supporting those three as any other. So that is. But in the case of even a lot of OpenStack with RHEL, being so tightly tied to the Linux kernel and the Linux pieces, that really is an economic but mostly a technical decision. You know, if I've got a vendor out there that's putting unknown things in a piece of software that I can't deal with or it's not a real company that can scale like us, we can't physically support it. So it's really the level of service we can give and certainly an economic decision for a company. Yeah, so Paul, I was at the OpenStack Summit in Atlanta in 2014 when that was, I mean everybody was talking about that. At Vancouver 2015's OpenStack Summit, nobody was talking about it. I actually, I think it was Matt Essay who wrote a great article talking about, we remember we went through this for, you know in Red Hat released advanced server and enterprise server as to like, oh it's limiting it, it's not going to be, give me the choice of everything else. But I mean Red Hat brought adult supervision and something that we could support. I was working for an enterprise soft storage company at the time and boy, supporting kernel.org and the 12 different distributions was a mess until you guys came out with something that we could point to and say, it works, I'll put it in the enterprise and I can draw a box around it and that was good. So, I guess on the OpenStack side, how's the traction been, where are we seeing it? Do we think there's going to be a big distribution market for OpenStack? Yeah, I do, I mean, I say this a couple of times today. I mean, RHEL is at the heart of it. Someone asked me, where do you think the RHEL business is going? I think the RHEL business is going into these platforms, whether it's OpenStack or infrastructure as a service or OpenShift or platform as a service, I think there'll be a time down the road, I can't predict if it's two years, three years or four years, but I think there'll be a time down the road where we sell most of our RHEL as part of the platforms, as the foundation for the platforms that are out there versus as stand-alone operating systems. I mean, to your point, we lived this in RHEL, I was there, I've been here 15 years. I mean, it was a big decision. Frankly, to do what we did with RHEL was a really big decision. I bet the company 12 years ago, but what we did with RHEL and OpenStack wasn't that big of a decision because we already knew the outcome because we had already lived it. And so, we really know this because we've been through it for the last 12 plus years. So I got to ask you, Linux is to OpenStack as what? Is to VMware, what's the analogy? What does VMware represent today that you're trying to disrupt? Is it the VMS of today? No, VMware in my mind is a management company. I mean, and here's what I'll say. So VMware disrupted the, and their partners are, but they disrupted the Tivoli's of the world, the BMC's of the world, the management companies that were trying to manage everything. And what VMware did was they came in and they slipped the proprietary hypervisor in, which they were the only one that could get into the various pieces of the hypervisor and became a management company because they locked everybody else out from managing that piece of the stack, right? So that's what they are. They're a management company. But what's happening now is with open virtualization, with OpenStack, with containers, when a hypervisor isn't always needed anymore, the whole management paradigm is changing. And what those layers are running on now is open technologies based on Linux. So that paradigm shift, in my opinion, is going to shift for VMware because I think over time that they won't have the luxury of having that proprietary layer that touches the hardware that no one else can get into. So you guys, you know, on your earnings calls, you kind of get this question, I'll ask it a little differently, but in the early days you had support, broad support for Linux for people like IBM. I had motivation to try to, you know, slow down Microsoft a little bit and gave some tailwinds, but the industry sort of let Linux and Red Hat bake. They absolutely, right? Now, you fast forward, it's like your big company and a lot of people see you as a competitor. But at the same time, you have a big install base. I presume you take your position as to where you are now. It's always fun to reminisce about the old days, but what if you could talk about that dynamic and how you see it progressing for you, Red Hat as a company? Well, I don't think, when we first started with Linux, it was absolutely a commoditization play. What we did for the world is we commoditized the Unix world. And everyone liked that, the hardware guys liked that because we're lighting up their hardware and they were giving their customers choice against Microsoft. And so that's what we did. And that's how we looked at RHEL as well as a commoditization play. I mean, our initial marketing was we can do it better, faster, cheaper, right? And, but what happened over the last 10 or 12 years is because the community had this powerful platform of Linux out there now to develop all the innovation. I'll say all. I'll say all the innovation in the infrastructure happened on Linux. And so all of the innovation that's happening around Linux is very tied to Linux because it's developed on Linux. It takes advantage of Linux services. It moves with Linux in many cases. So all of that happened around Linux. I don't think anyone, including us or them, thought that was going to happen. So now, as you, I mean, I'll be honest about that. And so now as you move out, you know, bringing this innovation to the market, we happen to be in the best place, I think, to do it because of our Linux heritage. And so the other guys are trying to figure out where they compete now. So what are they doing? I mean, do you see them as, is it, is it thought are they trying to slow down the market? I mean, you got IBM and, you know, Linux on the mainframe, Oracle, Linux. I mean, what are your thoughts on what they're trying to do? Is it genuine? Is it, is it sort of half? Well, you'll, I'll say, I'll say many of them and you can, you can leave to yourself which ones. Many of them are doing their own Linux. Right. And I think that's going to be very difficult because it's called Unix. And that's what happened with Unix. And, you know, Unix had common heritage in system five in Berkeley. I'm old, I lived it, I remember it. And, you know, for a while at work, but then you get so tempted to put your own, what I call, isms in it, that you start to stray from each other. And I think that's the risk of all these guys doing their own Linux is they will stray from each other. I mean, what we do with Linux, it's completely open. But when we take Linux down the rail path, after we snap off to take it in its 10 year support cycle, which by the way, is very tedious and expensive to do, when we take that down, it's different from Ubuntu. It's not that it's not open, everything we do, we push all the way back up to the latest kernel. But unless we and every other Linux vendor fix the same bug, put the same feature in at the same time in the same way, they're going to stray from each other. We're different from SUSE and Ubuntu, just as we're different from IBM Linux and HP Linux. And so that's the difference. I got to make you laugh. John Furrier called me last night, he said, hey, tell the guys at Red Hat, I was at DockerCon, I asked them, you know, I said, hey, Red Hat supports for 10 years, what do you support? I was like, 12 months, so. That's a long time. Yeah, right. So Paul, maybe, you know, let's get into the container conversation because, you know, you made a bunch of statements, you know, in your opening keynote, you know, first of all, I think we all agree, open source is mainstream. Linux is ubiquitous. One of the questions we have is server virtualization, change some of the hardware reliance, but, you know, didn't get rid of the servers, but a lot of things change. What are containers going to do? Some people have said that it, you know, lessens the impact of the operating system, could pull people off of Microsoft, but Microsoft's there big time. You know, obviously, Linux and containers, and especially Docker, together are tightly tied. You know, what's the Red Hat play? Why does Red Hat stay relevant? Confused things, I think, you know, I said it this morning, people think containers are magic and they run in air. It's an operating system. If you look at what containers are, the host is essentially what functions that the kernel provide today, right? There's the user space packages, you know, in our distribution, we have around 2,400 packages, the kernel is one. The other 2,399 are user space. When an application developer builds their app, they only need a fraction of those user space packages. They pick them up. Those user space packages, if you look at the last, a lot of the security flaws that have been out there over the last 12, 24 months, they're in the user space packages. Someone has to maintain that through a life cycle. So what's in a rel container is rel OS. What's in a windows container is part of the windows OS, and what's in an Ubuntu container is in an Ubuntu, you know, container, depending on who built the Ubuntu release, but that's another story. And so that's, it really is an OS technology. And I think one of the problems and mistakes we've made with containers, because they're not quite in the full-fledged production in a big way yet, people aren't thinking about these production level issues. So if I have containers and I deploy 100,000 containers and the shell shock bug comes out, what happens? We, that's what we'll address just as we've done with rel. That's what's made rel. You said yourself, what we did with rel was adult supervision to bring it to the enterprise, same thing with the container. And why I'm so confident of that? Again, we've done it already. Yeah, I mean, it's such early days, Paul. We kind of laugh about like how much money Red Hat used to make on t-shirts. Well, Docker's not trying to monetize the t-shirts, but everybody's wearing them. And we do admit it's early days. So could you talk a little bit more about, you know, why Red Hat brings security containers, what are their advantages you see and what's the white space? What do we need to do to kind of mature this space going forward? I mean, I think there's a couple of reasons. One of the security containers, just the life cycle that we bring that includes security is a big part of that. But also the parts of the rel operating systems, things like SE Linux and C-groups, the ability to separate containers, space from each other is a big thing, part about the security thing as well. I mean, one of the things that our developers did, which I'm so proud of, they built containers into rel seven, which actually shipped 12 plus months ago and actually was in development for the last three or so years. So the fact that they built it into rel seven and it can now, you can run the same container around across bare metal, virtual machines, private public clouds is very powerful model. I think in terms of the white space that's out there, it's management and deployment. And that's what we addressed in the platform that we announced today with Rel Atomic Enterprise. A container by itself is interesting, but having the ability to deploy, manage, and monitor and maintain hundreds of thousand containers is what it's going to take to get it into production. Right, and so can you also speak, you've got not only full Docker support, it's full Kubernetes support, how that happened and what does that mean to customers? Well, we've worked with the Docker community from day one. So we have a great relationship with the Docker community and Docker the company. So we've worked with them from day one. We worked with them on initiating the open container project with them and Microsoft as the two OS vendors and the container guys that were out there. We thought that was appropriate because it's so tied to OS technology. So that's a strong relationship that we've had with them forever. So that continues on. Docker has their business model. My understanding is they're going to be in the container management space. We think that's wonderful. We manage containers as well, but one of the things around management that I hate to go back to VMware, but one of the mistakes that VMware, actually I'd love to go back to VMware, let's talk about VMware. One of the mistakes that VMware made was they locked out partners from the management space and that upset partners, customers and a lot of people. We, at the time we didn't have management, we just weren't big enough of a company. We've invested a lot in management now, but even for example with OpenStack, we have a set of management APIs. Same API, our management tools use the same APIs as partners. We certify partners to those management APIs. We welcome management partners there. If we would love to see customers buy Red Hat management tools, but if they want to buy our partners, we welcome them on our platform. We're not going to make that mistake. Okay, so you make it easy for the customers to make that choice. Even though we have competing products there. As a business model. Yeah, we're not going to make that mistake. The problems to solve, I said this 100 times today, the problems we have as an industry to solve today are too big for one company to solve alone and that's how we look at everything we do. Well, VMware's changed a lot. Todd Nielsen used to talk about for every dollar spent on VMware licensed, there's $15 or $18 spent on the ecosystem. That metric has sort of gone away. It's obviously part of the friction. How many management companies can manage ESX? Yeah, one. So now, back to this sort of high level topic is proprietary versus open. The conventional wisdom of the proprietary guys is we can stay ahead of open source, full stack, et cetera, et cetera. Open source takes longer. What I'm hearing is that's so not true. I think open source is much faster. So I want to get your perspective on that. Why do you think that? It's proven. I mean, what I said out there today in terms of bringing, look at JBoss, look at the JBoss stack. When we bought JBoss eight years ago, it was just an app server. In the last eight years, we've built a complete set of services around the app server to compete with web sphere, web logic, et cetera. It took over 20 years for the proprietary guys to do that. We did it in seven, six or seven years. And so I think that's the proof of, it's the model. It's the development model. You iterate and make it better. You iterate and iterate and iterate. That's the development model most contemporary applications developers are using today. So history would show that you're right. I mean, look at UNIX, you know, look what happened there. Look where all the innovation is now. Though maybe the one interesting possible exception is just to see what Oracle's doing. They're the only company trying to go from silicon all the way up to apps. From an integration standpoint, we hear integration is really, really important. But there's probably not a company that's perceived to be more proprietary than Oracle. Except maybe Amazon. So what do you make of what someone like Oracle is trying to do? I think it's back to the 80s, you know? Or the 70s. Or the 70s. I grew up in the area here. I worked for DEC for the first 15 years of my life. You had a DEC stack. You had a Sun stack. You had an IBM stack. It was good. It solved a lot of problems. It did solve a lot of problems. It was great. Having said that, it's more expensive. It's less flexible in all of those things. And so I just think that that's contemporary thinking has moved beyond that. And over time, your model, well, obviously has the momentum now. And you think it'll have a flywheel effect and even gain momentum. Oh, absolutely. I mean, you see it every day. There's open source projects springing up every day. I mean, I said in my talk this morning, even when the JBoss community gets started, I think one of the reasons why they went so fast is because they had a platform, Linux, to build upon. I think that's why all the innovation you're seeing is built on Linux. Docker's built on Linux. Hadoop's built on Linux. I mean, I can keep going down the sparks built on Linux. I was talking to a developer a couple of weekends ago, kid out of college, just out of CMU. And I said, what's the most exciting thing that you're working on? He goes, I'm so psyched to get Linux on an ARM processor, because I'm going to go wild with it, with internet of things. And I'm going to start companies. And this is what the kids are thinking about today. And it gets you thinking about the data that's going to be generated everywhere. I wonder if you could talk about your play there. In ARM? In ARM? In ARM, yeah. Well, in ARM, the play is we have an ARM distribution. We're not bringing it to the market yet. Don't know when we will, but we will be ready. I mean, if ARM, I don't know if ARM's going to make its way into the data center, it will. I mean, it may. If it does, we'll be ready. We have a distribution that we bring RHEL to ARM, but we'll bring it. Intel will dominate the data center for a long time. We can sort of agree on that. But we want to be ready. We can't get caught. But IoT might be a different story. No, IoT, we see ourselves, you know, IoT is almost a state of mind, right? It's a solution. No one's going to go out and order 10 IoTs, right? Yeah, you don't buy it. Yeah, you don't buy it. It's really a solution. And we have a lot of the pieces to really put together IoT solutions with our customers. We certainly have the back-end servers and services in the back-end. We have, even with the JBoss application tools, we bought a company called Feed Henry to move in mobile development for the back-end. That goes all the way out to the devices. We have the services like messaging in the middleware stack that go all the way out to devices. So we have all the pieces to put together IoT solutions, not all, but many of the pieces to put together IoT solutions. And that's how we look at it. Yeah, unfortunately, we're out of time. We haven't even talked about, you know, Ceph and Gluster and where are you going to store all this data. But anyway, Paul, great stuff. Thanks so much for coming to theCUBE. Congratulations on the event and all your success. Appreciate it. And thanks for having us here. All right, keep right there, everybody. This is theCUBE. We'll be right back right after this short break.