 Everyone, this is theCUBE, SiliconANGLE's flagship program. We go out to the events, extract the student from the noise. I'm John Furrier, the founder of SiliconANGLE. I'm Jordan, my cohost. Do me a name and analyst at wikibond.org. And we're here at the Red Hat Summit Live, getting all the action. And one of the things we love about going to theCUBE is we like to go out, be independent, talk to the thought leaders, ask some tough questions. Not so much that people just walk out and leave, but we want to be engaging and friendly. And our next guest is Gene Kim, who is the author of the Phoenix project. Tech geek, tech athlete, as we say. Really in deep in the DevOps. And you were just at the chef conference I saw on your Twitter. Welcome to theCUBE. Welcome to theCUBE. I'm delighted to be here. So Stu and I love talking about DevOps because we get to really kind of talk about something that's really emerging, cutting edge, bleeding edge, but very relevant to the conversations that are happening around Red Hat. Certainly around the major innovations going on around this tech bubble, this tech innovation. Whatever you want to call it, we're seeing massive growth. We're seeing a massive paradigm shift where software is the center of the value proposition and where virtualization and technology and open source is a tier one citizen enabling that. And the DevOps mindset is driving it. So I want to get your take on, what's your take on DevOps today? And it's not just a corner case of dudes who are eating glass and spitting nails. It's now going mainstream. You know, I like you, we go to all these conferences and it's just, I love that because you're surrounding yourself with some of the best thinkers in the space, the best practitioners in the space. But what I love being here at Dev Nation and the Red Hat Summit is to see that DevOps is such a prominent part of the program. And so in my mind, to see that even your mainstream developer cares about the downstream consequences of the code rewrite and we actually do want the code to run reliably and predictably in production. Yeah, that is probably like you just warms my heart and it says that DevOps is not just for the few, it's really for, it's not just for the one percenters, it's for all of us. But Gene, I want to ask you and also I want you to talk about the Dev Nation things. That's obviously trending here at Red Hat Summit, a lot of activity. But if you go back seven years ago, you could have a barbecue and invite all the DevOps guys to it all show up. You get a handful of guys. Now it's an industry. So I want you to talk about the evolution of the industry and what's going on at the Dev Nation? What are the conversations happening around DevOps? You know, I think what we are observing is the emerging of continuous integration and continuous delivery as a standard practice. So it's not just for Amazon and Google and Etsy and Netflix. So this is for any developer who wants to have fun doing their job. And I think one of the lessons I learned in the DevOps community and the continuous delivery community that came from Jez Humboldt is that what we all want is fast feedback. No one actually achieves their goals when it takes us six weeks or maybe six months to determine whether our code even runs. And so that requires automated testing. That means quick deployment to the production. And that even involves something that we would have, or I would have thought, was immoral. Developers doing their own deploys, right? And yet I think that if we were to conjure up as former developers, when we were actually having the most fun, it was actually when we wrote the code, deployed the code, got to see it in production and fixed it right away by ourselves. And I think that's kind of the end state for both development and operation. I mean, you love to do QA in context to your baby but not be just doing QA on someone else's work. And the old model was, you know, very linear process. Developers, product manager, so developers, developers built the QA and then you have guys shipping it now. It's different. It's much more of a personal thing. Absolutely. And I think, you know, in contrast, right? Whenever we have to rely entirely on someone else to test our code, deploy the code, right? And then it takes them six weeks. I think that really does take a lot of the joy out of coding. And I think it's one of those amazing things where it's great for development, great for tests, great for operations and good for the organization we serve. So let's talk about, for the folks out there, let's unpack DevOps and kind of take it a little bit higher level. I mean, let's talk about things like infrastructure as code, agile programming. These are buzzwords that you hear around that talk about kind of a methodology. But let's talk about how broad is the definition now? How has DevOps changed, Gene, in terms of has it changed, has it broadened? And what have we learned? And what is it? What is the DevOps all about? Is it programming infrastructure? Is that it? Is it a mindset? Is it a culture? Yeah, I think there's not a very precise definition of what DevOps is. But in my mind, DevOps is not so much of what you do. Is it the outcomes, right? Show me the results. And I think the hallmark of any great DevOps shop is they have very fast flow of features in production where they can quickly go from code being written to code deployed, code running. And that's where you get to hundreds or thousands of employees per day. But it's also the fact that they can do that and have world-class stability, reliability and availability and security. And so before DevOps, I think most of us, the way we were trained is you could do one but not the other. We could be agile but not reliable or it could be reliable but then you're not agile. And the fact that what the unicorns have shown us, like Googles, the Amazons and the Netsys, they've really shown that you can actually do both at the same time. And that's what every organization needs to be able to create inside their own organizations. Fast flow and reliability and stability. So what do you guys talk about at Dev Nation? Because obviously Linux hits a sweet spot because it's an interesting dynamic going on around Red Hat. You have a company, publicly held, the open source communities, which is a whole conversation of itself. And they have huge enterprise customers, right? So that have built businesses on open source, all of it going through the clouds through this continuum from data center to cloud. And now DevOps is kind of like in the middle of it, kind of creating some energy. Absolutely. So what is DevOps doing to the traditional enterprises who are now rolling out and building business solutions around which is development software? And then the open source communities as well. You know, I think it's actually, what DevOps is doing for large enterprises is, and the CIOs that run these IT organizations providing a solution to the challenge they face, which is how do you get to market more quickly? How do you foster the ability to innovate? And name one large organization that doesn't have an innovation initiative, or maybe have a culture statement that says we need to innovate. And then what DevOps allows them to do is to actually create the capability to rapidly experiment, rapidly prototype, and then quickly scale that if you create a winner. Okay, so this is what I want to do. I want to go down the line I'm starting with myself, Gene, then Stu. I want to ask you for your DevOps moment. When did you have that DevOps moment where you said, damn, this is real? So I'll start. So I think the iPhone was interesting. I think that created some buzz around connectedness and social media and all that stuff. But to me, it was the iPad was the DevOps moment because what that showed people in businesses was, wow, I want everything on this. And then IT would be like, oh, we can't do that. But the guys who were doing DevOps said no problem. I can put that together. And then quickly built out some middleware and made that happen. Analytics, for example. So to me, the iPad was the DevOps moments because the business outcome, the business manager said, hey, can I bring this to work and can I run it on that? So to me, that was the DevOps moment. Oh, amazing. You know, for me, it was in 2007. I was with a friend of mine. He's a CTO of AOL, American Online, right now. And we were talking about the operations problem and what really happens when operations can't upgrade the Linux 2.4 kernel to the 2.6 kernel. And he shared with me this aha moment where he said, that is not an ops problem. That's not even a development problem because the effect of that was that they needed the multi-threading support that only Linux 2.6 had, the kernel support. And he said, it was like a nine month code freeze where we had the code written but we couldn't run in production. And we lost this deal and that deal and we had to do all these other things to compensate for the revenue that we couldn't attain. And he said, that is not an ops problem. That's not even a dev problem. That's why that is my boss's, boss's biggest problem. And for me, that was a really an aha moment that says with the problem that DevOps solves is not just ops or dev, but it's really people and the business, the businesses that we serve. So, I remember- I guess, too, I'm putting you on the spot now. So John, the eye-opening moment for me on DevOps was actually at Amazon re-invent last year. I mean, just to see some of the gaming and mobile, just whole new companies just spawning out of being able to spin something up quick and go. It was just a different world. I mean, I come from really the enterprise world and you think about how long it takes to build a process and make things change. And here was really an immersed culture of people that don't do things the old way and know that there's just so much potential out there. In fact, I have another DevOps moment that I just, I can't resist sharing. There's a guy named Patrick Lightbody. He was a founder of a company called Browser Mom. So, it was one of the first massive low-testing tools in the cloud. And I remember he gave a presentation at Velocity and he said, we found that when we woke up developers at 2 a.m., defects got fixed faster than ever, right? And it was just for me, it was huge- Automation. Yeah, it was, you know, to have shared goals, we have to have shared pain. And, you know, I think that's when I think I really gained a better understanding of the mechanics of DevOps. Yeah, so Gina, I'm sorry, John, I'm just curious when you talk to all of the developers out there, how much is open source, you know, where is it on their list of, you know, things that they care about and are passionate about? Well, I mean, so when you talk about like this incredible, you know, innovation happening where people are going to, you know, concept to prototype, to present to something running at scale, you know, in general, you can't do that if it takes nine months to go through procurement cycles, right, or maybe even years, right? So the fact that, you know, we can do so much with things that are available out there, we can leverage, you know, patterns that other people have generated and are presenting here at Dev Nation, it is, in many ways, in my mind, we live in an age of miracles, right? We can do so much that we couldn't even think possible, you know, five years ago. Yeah, so I was looking at the future open source survey that came out last week and they said over half of all enterprises will be contributing code back into the stream, you know, basically this year. So my question for you is, you know, do we want everybody to be coding, I mean, or, you know, where is that balance as to, you know, who should participate and be part of, you know, the development of code? You know, I think, you know, as human beings, as developers, what we really get fulfillment out of is, you know, contributing back, right? And, you know, it doesn't have to be code necessarily, it's documentation, it could be tests. And I think the community needs that and values that. And, you know, one of the great presentation that was given at Dev Nation was the head of open source at Facebook. And so Facebook has often had a reputation of creating these things like Memcache, these great open source projects, and then neglecting it for five years. And so essentially, you know, he's had a nine month, he was describing the nine month journey of rebooting that process to make sure that, you know, Facebook as a creator, they have responsibility to bring every enhancement back to the community and maintain, you know, the code repositories on GitHub or so forth. And I thought that was just an amazing story where, you know, that is, I think gives us a hint of why organizations want their engineers to be contributing back to the community. And Facebook has a significant management commitment to, you know, make sure that, you know, they contribute back. You know, in the open source community, there's really some of the luminaries out there that have helped driven some of the contribution. I mean, everything from Linus Robales, you know, Jim Lighthurst, the people running Drupal, you know, in the developer world, you know, who are those, you know, kind of luminaries out there that are helping to, you know, pull the industry along? I did hear this yesterday. It's actually Docker is a number two active repository open source project right now with over 400 contributing developers. So when you pull that, you know, report on GitHub, you know, it's number two. So apparently that's, and essentially, you can't help but notice that, you know, half the, you know, all of the second half of yesterday were talks of Docker. It's interesting, a developer conference talking about Docker, it's just awesome. It really shows that the dev and ops world really have crossed and, you know, that there's common, you know, we even both care about the same things. So we interviewed Patrick on theCUBE. You mentioned Patrick as a dev ops, and you know, he's an adventure of a variety of things. But I wanted to be, that spurred my memory around some components of dev ops that's really not being talked about here because it's more of an OS show. And that's the evolution of Node. Node.js has become really a very important component of dev ops because now the guys who do dev ops, the developers who are the younger guns is the older guys who want to move fast, who aren't quote network gurus or infrastructure guys. They're coders. They move fast, they break stuff, as Mark Zuckerberg would say. So Node has become a really big part of the dev ops culture. What's your take on that? You know, it's one of the great things about going to all these conferences. You get to see the amazing thing that people are working on. You know, I think this goes back to the theme of you can do so much with so little. I heard a story about how the Walmart e-commerce team was able to increase the rate of transaction they were doing by a factor of like 10, 100X, by essentially cobbling together something in Node.js. I mean, this is something that 10 years ago, you would rely 100% on your hardware vendor. You'd have to put an emergency engineering order in and probably have to spend a million dollars and they did it in a half day. This is, tell me that's not amazing. So we have, there's a startup called CrowdChat which we're involved in and I'm the co-founder of with Dave Vellante and Danny Ryan and we use Node.js for the CrowdChat application and we recently did it on Hadoop and HBase. And when we put it to Amazon, it was like we saved three hires, okay? No admins, we didn't have to have a lot of more engineering help, fully integrated stack, elastic beam and auto scaling. So as coders, our team was to have the ability to actually push code and iterate really, really fast and versioning control. I mean, this is the new generation. The notion of updating a Linux patch, that's kind of like going out the door. I mean, that's gone. So DevOps is a mindset. It's also, it seems to be the method, preferred experience for the younger developers. Do you agree and what can you share on that trend? You know, I had, I saw a fantastic session that was part of the Red Hat Executive Summit and the gentleman, he was the director of IT at Intel and he said he spent 22 years in the fabs, right? In the manufacturing domain, right? And only two years in IT and he said, one of the things that they have in common, they have many things in common, but the one thing that really stood out to him was the fact that what really kept him up at night was the human factors, right? Is that in manufacturing, over a decade, the skills in the manufacturing workforce changed what was needed, right? And he said in IT, it happens so much faster, right? You wake up one morning and you find out you're irrelevant, right? And so I think it's good news and bad news is that it's great for the young engineers who can bring these capabilities quickly to bear. On the other hand, what do you do with the people who have been doing essentially the same thing for 20 years and now have to generate some new skills in order to get relevant? Yeah, they got to get relevant and they're going to be out of a job. I mean, that idea of complacency is interesting. You're seeing even at the computer science programs in most of the major colleges and universities, it's interdisciplinary, it's a huge deal. So I think that's a macro trend that's crossing over where you got to be able to do a couple of things really, really well. Right. And so I think the real challenge is, anyone who leads an IT organization is how do you elevate the average skill level so that this is not a 1%, only the 1% benefit, but we can actually increase everybody's ability to achieve their own goals. Yeah, now we were talking earlier about some of the open source dynamics and the old expression of herding cats really comes from software engineering now it's more of a social interaction too because now you have to have good teamwork, a little bit different with DevOps, you vote with code, you are your code, right? So there is much more of a personal social angle with DevOps. Yeah, it's interesting. One of my passions is benchmarking high performers. And so in 2012, we benchmarked 4,200 organizations with Puppet Labs. And our goal was to really find out what high performer's doing and what causes high performers. And so in year two of the benchmarking, we benchmarked 9,600 organizations. And one of the single best predictors of performance, performance is defined by, you know, deploys per day, lead time, you know, how quickly can you go from code committed to running in production, change access rates, meantime to pair. The single best predictor of performance was, is there a high trust, you know, is it a high trust organization or low trust? In other words, is it a culture of fear or is it a culture of genuine innovation and high trust? And that one question, you know, was the most effective predictor of IT performance. So it really is true, right? It is all about the softer side of being working in teams. Gene, great to talk with you because I really believe I've always said on the queue when we love to pound the DevOps message, it's a lot of different things, but it's also a cultural and now mind shift, mindset and a cultural shift. But we're still back to software engineer. So I want to get your take on Dev Nation. You've been leading that, you've been out there talking with the folks out there. What's going on at Dev Nation? What's the big news conversations, discussions out of Dev Nation? Yeah, I guess there were two themes that I just loved endlessly. One was, you know, the increasing adoption of, you know, DevOps practices in more mainstream development projects. And the other thing was everything around platform as a service, Docker, where it really does start changing, you know, what development produces. Whereas before, you know, we would just hand off our executable code. Now the goal is to, you know, hand off something that operations can immediately put into production and deploy. Right, and so in my mind, this is the, it's almost like in manufacturing when the plant engineers realized their end customer was not the person who was driving the car. It was actually the plant manufacturers working on the plant floor. And so I think how that transformed manufacturing is exactly what's happening in the software engineering space as well. Good vibe over there? Ah, it's awesome. Yeah, it's been a great two days. Dev apps guys, I always say, eat glass and spit nails. It's like, they do stuff that you'd like, wow. But that's becoming more mainstream in large enterprises. How does a guy who works at a company you mentioned doing some old things, how do they become a DevOps guy? Or is it just a new title called CloudOps? Is there, do you see something shifting there? I mean, how does someone become a DevOps guy? You know. Superheroes of coding. Can you be taught? Yeah, of course, of course. In fact, I would say this, what would be my three tips to any developer who wants to join the DevOps tribe? I think one is read the book, Jez Humphels book, Continuous Delivery. Because it really, from a developer's perspective, describes what does the product owner, dev, test, and operations, what do we have to do differently in order to facilitate fast flow? The second thing is, you know, I would recommend going to any DevOps days, the Velocity Conference is one of my favorites. In fact, we're now holding a conference we're calling a DevOps Enterprise, where the goal is to really cast, oh, it's actually, the department committee is like John Willis, and Adrian Cockcroft, and Damon Edwards, Dominic DeGrantis. The smartest people I know, our goal is to really help create a different narrative of DevOps, where it's not about Etsy and Amazon and Google, instead it's Macy's, and Disney, and General Motors, describing how they've transformed. And if there were a third one. Is that scheduled, or is that? Oh yes, in fact, I'll send you the information, it's going to be October 21st to October 23rd. Here? In San Francisco, yes. Great, okay, just make sure to get that out there, get a quick plug for it. So basically that's the conference of getting it less out of the geeky, one-offs, hyper-scale, web-hyperscale dudes, to mainstream. And in fact, there's actually one other thing that I would recommend any developer do. I think it's now common practice, that every developer should watch their customers' user code for at least a couple hours. And for me, I remember when I did that in 2006, I almost threw up. I felt there was a one routine operation that we expected everybody to do, and it took 62 clicks. And any decent human being would feel so guilty for that. I think in a DevOps context, what I would recommend every developer to do is not just watch the user's user code, but watch the deployment process, and see what the operations people have to do in order to put it into production. And I think watching that will change people's mindsets just as watching them run their code. Okay, we're here with Gene Kim. Final word I'll give to you on this segment is, what are you doing next? Share with the folks what's going on in your world? What are you working on? New book, new code, new event, obviously we just heard. What are you working on? What's next for you? So the Phoenix project came out one year ago January, so that's been one of the most fun adventures I've ever been on. Right now we're in the final stages of trying to get the DevOps cookbook out. So whereas the Phoenix project was a novel about IT, DevOps, and helping our organizations win, the DevOps cookbook is really meant to be the prescriptive guide. So if I want to do DevOps, here's a step-by-step set of principles and the step-by-step patterns that organizations can actually put into place to replicate the transformation that's described in the Phoenix project. Okay, we are here inside the Cube at the Red Hat Summit, always talking all the best people can find, sharing the knowledge and sharing it with you on the Cube. We'll be right back with our next guest after this short break, talking DevOps, open source, operating systems, all kinds of greatness here. So we'll be right back after this short break. Thank you.