 The Cube, an open-stack summit at Lata 2014. Is brought to you by Brocade. Say goodbye to the status quo and hello to Brocade. And Red Hat. Here are your hosts, John Furrier and Stu Miniman. Okay, welcome back everyone. This is The Cube, our flagship program. When we go out to the events and extract the signal from the noise, I'm John Furrier, the founder of SiliconANG. I'm Joe, my cohost, Stu Miniman, and all of us at Wikibon.org. Next to us is Troy Toman with Rackspace, cloud architect, been part of the board of directors, been involved in the open stack for a long time. Welcome to The Cube. Thank you for having me. So you're up on stage, so 4,500 people, big crowd, were you nervous? I don't know how you can be a little bit nervous. You know, you walk out and you know, but at the end of the day it's the energy that really feeds to you when you walk onto the stage and ultimately, you know, I know it's an audience of my peers and so you just kind of go with that and you hope at the end of the day you have a message they want to hear. I just tell my daughter, she gives it to them. And so I'm nervous in front of every public speed, even in front of the three cameras here, which is hundreds of people watching. Really appreciate your time coming on here. I want to get to the heart of a couple of conversations that are really important to folks out there. I'll get your opinion on it. Obviously, OpenStack has a great foundation and just the vote of confidence from the feet on the street here in Atlanta is pretty significant. Almost double it seems like in size. On the intro, I said it seems like the same, but actually getting the numbers was closer to almost double the size. So there's interest. You've seen the proprietary vendors, you mentioned 25 billion dollars being spent. HP just said they're going to match IBM's billion. It should be like 10 billion. What's the number of these guys that have put up there? So the commitment is there, right? The energy and the enterprise and certainly in the service providers is momentum. What's the status of this foundation and what's changed over the past year? Well, I think there's been a few things that have changed. I think we're going through a maturation process as a community and as an organization. And as I kind of talked about in my keynote, I think we've reached a certain level where we've earned the right to compete for the future of cloud. But we certainly haven't fixed it and we certainly aren't done yet. The things that have changed is I do believe that the foundation itself has matured. This is an organization that didn't even exist in the early days. We've now got a strong foundation board. We've been through a couple of election cycles. I think yesterday, for instance, we actually had the first joint meeting between the technical committee and the board. To be honest, in the early days, there was a little bit of like, oh, it's the business guys and the developers. We weren't sure, but we got in the room yesterday and we realized we all see the same issues. Maybe we have different perspectives, but bringing those perspectives together is going to allow us to sort of move forward and really solve some of those. So I think we are sort of seeing the community grow up a bit and mature and start to recognize that we're not completely perfect. So talk about the technical committee and board. I saw some tweets yesterday. Some positive love came from the Twitter sphere. What actually happened yesterday? Why were people positive on Twitter yesterday about that meeting? I think we were a little bit probably surprised at how aligned both perspectives are. You sort of think of the board as being a little bit more representative of the business side. I'm actually a community elected member of the board, but we also have a racked-based appointed members and some corporate appointed members. I think sometimes there's a perception that there's a lot of tension between the business side of racked-based and the technical side of racked-based. And what I think we found when we got in the room together tomorrow is that that's really, it's an idea that's not real. And when we brought up the question, we all had the same problems and we all recognized the same issues. We had very similar priorities and there was a real willingness to get around the table and start to engage to solve those issues. That's a real fear people have, is that when you have a board of corporate overlords on there that they can muck up the momentum. I mean, that's legit fear, right? Yeah, well, it certainly is a fear and you look historically, that's probably true. And there's kind of a natural distrust sometimes on the engineering side of the business side of any group, whether you're in a foundation or inside a company. But the way that trust actually gets built is you start building some familiarity, you start to build some common experiences. The fact that we spent a couple of hours in the room and some time over dinner last night was a great start to really build that knowledge and really kind of that empathy between the board and the TC that's really necessary. Before I give it up to Stu, I know he's beggin' to get a question and you had a great quote up there, conflict without trust is politics, conflict with trust is a search for the truth. That resonated well with the folks out there. Is that, were you referring to the meeting last night or just in general the whole community? Well, I really think it's about the whole community. I think we all, anybody who's involved in OpenStack really feels this tension constantly, right? In the community you wonder if the guy from Red Hat has an agenda or if the guy from HP is trying to take over a project and whether or not you should believe what they're saying is their opinion or whether they're trying to accomplish something. But we feel it in our own companies, right? At Rackspace, we have probably too many conversations about how do we win OpenStack and we need to be having more conversations about how does OpenStack win the marketplace. But we live in a real world where we've got, it is co-opetition, right? We cooperate and we compete. And my goal is just to remind people that the cooperation comes first. So Troy, in the open source community, it's often been a really strong leader that's helped driven adoption and helped keep the community going. So you think back to the early days of Linux, I mean it was Linus Dervales, Red Hat's got Jim Whitehurst and a strong team there. Drupal's got a pretty strong leader. How can OpenStack get that maturation and get that adoption if it's kind of management by committee? Well, I think we've gotten that far and I do believe it's fundamentally that committee has a lot of trust within it. And I said this on stage and some people find this a difficult adjustment. They come into OpenStack because we do argue a lot and there's some pretty blunt people. But at the same time, the statement was made in one of the meetings I was in yesterday which is Linus doesn't work here. We actually don't have the kind of people that wanna go around and tell everybody what to do. They wanna have an opinion, they wanna express it strongly, but they value that interaction and that debate. And I think as long as we keep a foundation of putting the project ahead of the individual goals and the all boats rise kind of mentality, that we don't need to make up for that by somebody who ultimately comes in and says, well, I'm the one who's gonna make the decision. It may be a little bit slower but my experience has been that when everybody's in alignment, it all eventually moves with a much more force and I think in the long run, it's better. So you've been involved for quite a long time on this. Rackspace helped found OpenStack. Absolutely. And if you look at the community now, there's so many vendors involved. Has Rackspace in a way kind of fumbled the leadership of this? I was at a show last week and was talking to some of the people working the Rackspace booth and there were some people that actually came up. They said, oh, hey, Rackspace, you're involved in cloud. Do you guys do anything with OpenStack? I mean, when I think about Rackspace, I mean, OpenStack was very important in the course. So talk about Rackspace positioning in the OpenStack community. Yeah, I think, look, everybody's looking for a story and what I think in the Essex release, we might have been something like over 50% of the contributions now we're down to about 10%. But you look at that, you look at the size of our company, the number of developers that we have. And I think we're contributing at a very substantial rate and we're doing a lot of the contributions around things like scale. The places that we actually know, the places where we bring particular knowledge, we run what we think is the world's largest public cloud that actually uses OpenStack, that runs on tens of thousands of hosts. We're absolutely right in the middle of OpenStack and it's essential to the future of the company. So I think this is more about maturation of the community where you've got IBM coming in with their Linux background and systems expertise contributing where they're the best. Look, they've got 300,000 people in their company. They're probably gonna have more developers working on OpenStack than a company of 6,000 like Rackspace. Red Hat, just an unbelievable tradition in open source, HP with their enterprise chops. When we're in the room for OpenStack, we're rarely sitting around going, okay, that's the HP thing, we're a guy, why is Monty saying that? And I think that's a lot of the noise that comes around the business people trying to figure out how to position this stuff. Or in some cases, the press that are looking for some story that people wanna listen to and the fact that we're all collaborating together isn't very exciting. But we're still, I'm very proud of the contributions. We've stayed in a consistent top five position in code contribution. And if you really start looking at the number of our guys that are participating in the Operator Summit, one of the Rackspace guys actually led the operator, the definition of the track here on operators and it looks like we may be hosting the next Operator Mini Summit. I think we're contributing all over the board. Yeah, I mean, we gave, last year, we did a broadcast last year at Portland. We gave Jim Curry, he was on theCUBE, and I was there from the beginning when he was trying to do the pre before it started. I know what those, when you guys had the cloud build out, you guys really wanted to onboard developers. And I was there, I could testify to Rackspace, it was instrumental in OpenStack, you guys were awesome. We had some commentary on the crowd chat saying, you know, Rackspace got ganged for being too close to OpenStack and you guys kind of pulled back for the betterment of the community. And may have maybe lost that position. But, you know, I think that's worth pointing out that you guys did pull back and not try to bogar the position. I mean, I would necessarily use the pull back. I mean, that pull back or perceptions. No, what you're saying is, look, we intended, we always wanted this to be a community-driven effort. Yeah, you weren't trying to, you weren't trying to put your arms around and hone it. What I'm saying is, I think you deserve that, deserves to be clarified. Well, thank you, I'm glad, I think it does. And, you know, looking the long run, people who are close to the fountain to what's going on here get that. And, but I'm always happy to go profess that. Yeah, I was talking to Rick Jackson, I said, hey, you know, I've always been there. You guys can, you guys are at the table. It's not like you lost anything. But, you know, I think sometimes for everyone to win, you can't really bogar the position. I think that's the critique that people are afraid of. As I mentioned earlier, a lot of people are scared. Like, they see HP, they see IBM come in. You know, they're nervous. They've seen this movie before in other generations of stalling, you know, proprietary vendors have a tactic, and that's well documented in history of tech, which is coming in and stall things down. Yeah, and I think, you know, we're all sort of aware of that. In some ways, almost too much. I mean, there have been points, I think, where we as Rackspace have not asserted a position for fear of looking like we're trying to be controlling, when in fact, what the community needed was leadership where we could help. And so, look, we're doing something new here. I think four years in we're doing great, but these are all areas that we just got to continue to get better at. And one of the reasons that I wanted to remind people of that as we go forward. Yeah, and I think the whole trust thing is good. I also want to talk about the ecosystem. Actually, the ecosystem is growing. You can't really bump into a tweet or some sort of promotional thing on Twitter or online, on LinkedIn without seeing someone moving into an open stack job. I mean, if you put open stack on your LinkedIn, rumor has it that you're instantly going to get pinged like 20 times that next day. There's a huge demand for jobs around open stack. Yeah, well, you know, we're always looking for people. So I know that's true for us. Well, even in the large enterprises, I talk to CIOs all the time, they want to tool up and they want to build these composite applications. They want to look under the hood. They see Amazon succeeding with shadow IT and they say, hey, you know what? We'll do a little of the public cloud. We've got to build our own. So where are we on the architecture side foundation set? There's no real politics yet involved. It seems like in the foundation side, but on the ground for the guys who are building, where are we? What's the solution set look like? What do those guys need to do to start building and monetizing that, you know, grow and monetize? Well, I think we're starting to see people do that today, you know, but the challenge is it is, it does take a lot of open stack expertise to bring up a usable sort of sizeable implementation. And so some of the more sophisticated people like Wells Fargo and Disney that we talked about today are doing that. And so the good news is it's a solid product that if you've got the knowledge and the sort of skills around it, it's clearly delivering value in the companies today. And, you know, we're seeing a rise of available skills for hire. I mean, certainly, you know, cloud scaling and Marantis, Rackspace has services, we're helping people build their own clouds. And I think you're seeing a broader range of people that get there that, you know, sort of get to that next level of people that have some resources to spend against this. But I think, you know, we recognize inside of the project that we need to make this more accessible, that I think this whole area of what's the right way to install and build and manage. And look, it is the reason that we are doing so much around operators at the mini summit. And here I'm having special tracks is knowing what the operators need to make this easy, being able to replicate that super user knowledge that Jonathan talked about. So we've got them. How do we replicate that knowledge and make more super users make it easier to become one? I think that's the big challenge for us. I know you're not a financial expert. I know Stu wants to join me. Stu wants to question. I know you're not a financial guru, but a lot of people comment on things. Ask Troy when the financial markets will value racks. Hope it's that activity seems like they don't get it. I don't want you to talk about the comments on the financial stop, because you're really not, you probably won't even be in that position to do that. But really the valuation of where we are, you talk about the future. How should someone value the technical and the enablement that's happening in cloud? Honestly, we have an opinion on that. We're very pro cloud in terms of value creation. You're enabling the sense of the economics. How would you talk to a friend and say, hey, I run a hedge fund or Hamas analyst. What is this value of this cloud stuff? This open stack. Give some possibilities on what it could look like. Well, I think it's difficult. I mean, we're talking about really a fundamental transformation of the way that services in IT actually get delivered. And it's very hard going through these revolutionary periods because these transitions don't happen overnight. And we're in an environment where people want you to be able to start a company and sell it for a billion dollars a year later. If you're not doing that, then people think you failed. And what we're talking about, Shut up is pop, by the way. That's called WhatsApp. Well, I keep thinking it's pop and then I'll see another one. But the reality is, I think Wall Street and others. Well, Box has pulled their IPO. So they're seeing that, hey, the enterprise, this is real infrastructure. This is real stuff. Well, it is real and it's at the core and you can't go too fast. Because what you can't do is go so fast that you trip everything up. And look, the world didn't switch to Linux in 1993. It took a long time for that to sort of get to the point where people felt comfortable. And one of my big worries, and actually I wrote about this in a blog post that we put up on the Rackspace site today, is that this idea for this quick, fast, super return is actually gonna get in the way of us realizing this is a long haul. That we're really just getting started. And we need to conserve some energy, right? It's the marathon, great. We got a good four mile time, but we got a long way to go. And look, the financial markets put a lot of pressure for those returns. It makes it tough. So Troy, it's been the developers that have been driving this adoption in the early days. I really like Junior Keynote. You talked about really trying to expand the contributors to kind of the operators and the users and how we need to make sure we don't rebuild silos that we'd done in IT before. Can you tease that out? I'll unpack that a little bit for us as to, you know, who's contributing? Where's it going? What's this meet for the IT organization? Well, I think it goes back to this idea of really getting a common understanding. I mean, a guy named Jeff Susna wrote a blog post recently that I've referred to people too on my Twitter stream, but around this, that the essence of DevOps is empathy, right? And I think a lot of people want to equate DevOps to being tools or DevOps to being automation, but the reality is it is about getting the people who are building software and tools and the people that have to run and use these tools to understand each other better, to not throw walls up between themselves. And look, what better to do that than an open source community where we can bring people in and, you know, if a developer makes a change and, you know, like, let's take an API. The developer may say, well, this API we built in the first version of OpenStack doesn't work right. I don't like it. I want to change it to make it more efficient. It's more elegant from my computer developer sort of background. Well, you might have a user who's written an application or an operator over here whose tools are going to blow up in a minute that API change would come out. Well, it'd be a lot easier if that developer had that understanding of all the tools and the instrumentation that they're building and really had that knowledge before he made the change or before he adjusted things. And so this is really about, you know, kind of getting to the point where you get more developer and more operator and user knowledge infused into the development community directly versus just kind of an abstract list of feature requirements that I think we all too quickly fall into the trap of. And what's been your experience, you know, how are customers along this kind of journey to the adoption of the solution? Well, I think they're struggling a little bit. And I think we as vendors aren't doing a very good job of helping them understand it, right? Look, it started with cloud washing, right? Everything was cloud. Anything was cloud, you know, if you weren't buying a box with a CD, it was cloud. And it confused a lot of people about cloud. Now the same thing is happening with DevOps, right? People want to put a DevOps stamp on everything. And the reality is, you know, they're all clear about the benefits of DevOps, which gets everybody interested in it. But if everything is DevOps, where do you start? And I think we've got to get better at having a conversation about this underlying essence of DevOps, which is, you know, rethinking the way that we build an organized software so that the users that are going to consume this get benefit right from the start. And, you know, the rest of it is all just building off of that. Sure, to do that, you're going to want better automation tools. Sure, you're going to use CI and CD and all these other things. But the reality is, you know, much like when the whole Dev community moved to Agile, and people thought, oh, I bought a tool. I'm now an Agile development shop. Actually, you had to go to the principles of Agile behind it. And we need, you know, I think we need to have that same conversation with cloud and DevOps that says, there is a logical evolutionary way to get there. As much as people want to make you think it's sexy and new and complicated, it's not, but it's a long journey. And you need to take a step-wise function. I always talk to folks about DevOps being like the Navy SEALs, guys who E-class and spitnails, it's a unique breed and they've actually pioneered this great, great movement we have. And I do agree on the Agile side. I think process is key. People in process change management, all that stuff. It really comes down to operationalizing the cloud mindset. So when you see the DevOps transitioning to, say, the mainstream enterprise and service providers, some of those guys in there, just, you know, they've been in careers. Some of the new guys, young guns coming up out of school, they don't have the playbook. So it has to be simplified. So how do you move from DevOps as a specialty, certainly in demand, to more of a cloud ops role where it's, not, I don't wanna say like a boring IT function, but like a relatively, you know, an IT function, there's a lot going on in IT. It's gonna have a lot of orchestration, automation. These are the kind of key words. Well, I think that you sort of get to the heart of it. I mean, the reality is to do what we describe as DevOps, you had to be some kind of Superman because honestly, we built code that was hard to use. And we built cultures where operators often felt like they didn't have the right to complain about it. Their only choice was to take the craft that was thrown over the wall and figure out some way to make it work and hack scripts around it and build some other stuff. And so they became these kind of ninjas that could make it all work. And, you know, Rackspace, we talk about, you know, we wanna make our support people look like heroes to the customer. And often they do that inside of Rackspace by heroic acts. But the purpose of the cloud and the tooling and all the stuff that we do is make sure that people that are building this, right? The people who are actually writing the code for OpenStack, if they know what those operators have had to hack around and script around all those super human things, build the software so it doesn't need the super human work, right? Make it so that everybody using OpenStack looks like a DevOps ninja as opposed to requiring a DevOps ninja just to use it. And that's the real shift for us. And you guys, we're living that. I mean, when you guys moved from hosting to cloud almost eight years ago now, or six years ago, seven years ago, you had to do that. Clean shit, paper. We had to do it with every evolution. How hard was it? I mean, what are some of the things you guys learned, share with the audience and what you guys went through? There's some pain involved. I know that. Talking to some of the folks over there. Well, absolutely. I mean, you did, I remember the first day I walked in and we started talking about moving to the OpenStack cloud and I said, you know, I want deployment of our cloud tools to be completely automated. And they're like, oh, we have them automated. And I was like, really? How do you automate them? Well, we deploy them in our test environment. And if that works, we move the scripts over here. We edit this file to change this value and then we push it out. And I said, well, did you just say you edited the file? And they were like, well, yeah. Well, that's not automation, right? And so we had to learn, you know, that common language so that the developers when they said automation and the ops guys when they said automation understood the same thing. We also had to teach the operators that they didn't have to put up with code that was hard to operate. If something didn't work, they went and sat down with the developer and showed him the pain, got that sharing. And so we've learned how to bridge that. I think a lot of what we do at Rackspace is about how to either do that for customers or help customers learn how to get down that path. Okay, let's take a big picture here. My final question for you is obviously, there's still some experimentation. It's not broadly accepted yet in the industry. It is now from a mind-share standpoint, but as it goes mainstream, a leader has to emerge. Leaders are emerging. So can you point to some examples where, hey, that's leadership, that's leadership, leadership deployments, obviously the HP as I mentioned earlier and the money coming in and supporting that, but who's leading? Who's the big leaders? When a leader comes in and you're seeing the leaders come in now. And put the stake in the ground, then it moves fast. It's kind of like that bowl of jello in the fridge. Just all of a sudden comes together really nicely. So who are the leaders and who are the leading deployers out there? Well, I think you can look at what companies like IBM and Red Hat, who came into the game relatively late from an open-stack standpoint, but have moved into very influential positions certainly within the development community that have done huge and incredibly valuable contributions. HP has really stepped up. Their whole organization provides the CI infrastructure that we have that we're in right now. And so I think what we're seeing within the community is companies are leading in their area of expertise. Cisco has the new PTL for Neutron on the networking side and the networking companies are getting engaged there. And so hopefully that stuff starts to come together in a little bit better way. You know, in terms of the marketplace, I still think we have probably the largest public cloud out there and we're doing a lot of private clouds that maybe people don't even know about. And so I think the names are the names that are there, but we're still at the early stages of this, right? We really need to see this. Actually, put the bumper sticker on this event. What's the single takeaway for the folks out there? Share in your own words why open-stack summit this year, what's happening right here in the ground that's important for the folks to know about. I think the most important part is really bringing the operators and users together with the developers and really emphasizing that as a part. This started as a design summit where just the developers came in and talked about what code they're building. And it may sound simple, but the reality is we have designed summit sessions where operators will be in the room with the lead developers of each project. So they'll be a meeting with the Novigas. They'll be a meeting with the neutron team where the operators and developers on those projects are getting into the nitty-gritty of what the problems are. And so I think that's the real sign of evolution, the most important thing that's happened here. And I'm really excited about it. I think it pretends well for our future as a community. Searching for the truth, that's what trust and collaboration comes down to. Great keynote, thanks for coming on theCUBE. This is theCUBE, we'll be right back with our next guest live in Atlanta for the Opus Dex Summit. This is SiliconANGLE's CUBE coverage. I hope us next time we'll be right back.