 Live from the Computer History Museum in Mountain View, California. It's theCUBE, covering DevNet Create 2018. Brought to you by Cisco. Okay, welcome back everyone. This is theCUBE's live coverage here in Mountain View, California for Cisco's DevNet Create. It's their cloud native developer ecosystem. A new initiative, only year and a half old. Great cloud native DevOps oriented. I'm John Furrier, your host with my co-host, our next guest is Damon Edwards, Chief Product Officer of Rundeck. Welcome to theCUBE, good to see you again. Yeah, good to see you again. So, you're just on stage giving a talk. I was. About ops, dev ops. I was bumming people out. That's what I was doing. So a lot of all the Cisco early stuff was about new products and new toys and new awesome stuff. And then my talk was about how silos and tickets ruin everything, right? That we've got all these great advances on the dev side of the house and delivery side of the house and the new technologies we've got and everything's high flying and going to be perfect until it all hits operations and things tend to go wrong. So I walked through a bunch of kind of names or chains to hide the not so innocent. We went through some incidents and just sort of the tales of woe and how the disconnects and the basically the siloed way of working. Number one, kind of we group like with like and operations very siloed. But also number two, that we run our lives through these ticket driven request queues, right? And request queues or queues in general, if you look on the product side and then the sort of the physics, the queuing, the queuing theory behind it, queues are economically very expensive things. You know, they add a lot of delays, they create a lot of bottlenecks. They, everyone's, you're, I asked you to do something and I write it down. You take it off the queue, you know, a week later, the context is all different, right? So we have all kinds of bottlenecks, all kinds of quality problems, all kinds of delays. And it's just an expensive way to work, yet that has become the de facto way that we run our lives. And instead of using tickets for what they're good at, which is handling problems, we use tickets as the general work permission system for the entire operations organization. And it's, you know, no surprise that silos and ticket driven request queues that we get what we get. And so what we talked was about how to say, well, how can we get, stop using tickets as the primary way of doing things. How do we read, how do we kind of look at the organization and remove the need for handoffs, right, between those silos, and then replace where we can't get rid of the handoffs with self-service, right? Pole-based self-service interfaces where people can get what they need to get done, do those operational tasks for themselves, and then move on, right? That's what it's all about. So tell us a little bit about what your company does and how you're solving this problem. Cause it's definitely a problem that's out there right now. And people aren't talking about it a whole lot cause it's kind of the ugly underbelly of development knobs, you know, they're trying to solve it, but they don't really want to talk about it. It's less sexy because you get a promotion for delivering the next big project, right? Saying you fixed kind of how operations work, it generally doesn't, you know, the board of directors doesn't know your name. So that's kind of problem number one. But how Rundek factors into this is we make tools for SREs and systems administrators to number one, organize all their scripts and tools, connect all the scripts and tools that the platforms they currently have across those silos, create standard operating procedures. And then probably most importantly, use the access control features to start to give access to people who are traditionally outside of those operational boundaries. Let developers participate in operations. Let QA participate in operations. Let business analysts participate in operations. All those requests they normally have of operations create those services, let them, you know, let them do them. By doing that, you're creating more capacity in operations to focus on issues that you really need to be solved. And you're making everybody else happy because you're staying out of their way. They can move faster, have fast feedback, higher quality, all that stuff. You know, we've done a lot of crowd chats and we've had the questions come up. Is it the culture or is it the tooling? Or is it the people? Look at all the above culture. Everyone goes to the, that's low hander. Yeah, the culture got to be there. You guys are doing tooling. Can you talk about some of the things that you've seen that works? How does someone go, hey, first it's self-awareness. We got to change this. And so if someone's into that mindset, I want to move to the new model to be more agile. To actually streamline those silos and that ticket system. What tooling do they need to use? What are you guys providing? Where's the steps? What's the sequence of tooling and adoption and picks and shovels? Number one, use what you have, right? So this idea that, oh, okay, we're going to solve this problem. We're going to teach everybody to use this one tool. Because everyone's got to learn this DSL or this kind of language. This never works. I mean, you know, three years ago was one tool. We all know the name. A couple years ago was another tool. We all know the name. You know, these configuration management tools. Now we're on to the new container world. They're like, I don't know if we need that or not. Everyone wants to do what they need to do. So let them do what they need to do. It's a very lean idea. Focus on how to connect those things. Focus on how to orchestrate and organize what you've got already. And then from there, focus on how do we do two things? Limit those handoffs. So that kind of is more of an organizational issue. And number two, all those handoff points. Anything I need something from you, John. Like, you know, are you Lauren? I don't want to have to say, do this for me. You do this for me. And I'm going to wait. And you've got five other things you're working on. You should create services that I can pull from. I need something from you. I need something you would normally do. Hit an automated service. Sort of like, don't do the old sort of savage managed service, you know, way of doing things. Do it the Amazon way, right? Which is, I can hit an API and get what I want when I want it. And most importantly, it's not just a one way button I can push, but I can actually create those buttons myself, right? So I can give the thing that I need to do. You can look at it and say, yeah, that's going to work. Give me back permission to go and run it. Everybody's happy. You guys get more, the scenario, get more capacity. And I get what I want without having to wait. So is microservices going to impact operations in a way? Because what you're getting at is more of a microservices. More of the primitives are going to be in the ops side. So there's a development mindset anyway. Is that standard dev ops now is ops? Well, you need to handle the operational concerns as early in the life cycle as possible. Meaning developers have to build from, it's kind of like in the car world, you build a car for manufacturability. You have to build the services for operability. And so that's number one. And with the new kind of microservices decoupled world, you have to move to this model of operations. Because the old monolithic work balances across these silos, it just doesn't work in this decoupled world. It makes everything kind of grind to, back to a lump in mass of who knows what. So if you want to let the organization decouple, you have to be able to decouple your operations to match that. So how long is it taking for customers to kind of realize the value of your solutions that you bring to the table? And how much time is it saving them? Yeah, I mean, for Rundex specifically, because it doesn't force you to learn new languages, you can start with what you've got today. So literally, it's days, right? Start plugging in things that you have. You can set up the access control. You can set up kind of the options, the interface. The next thing you know, I've got this self-service interface and I can turn around and let somebody use it. So Rundex doesn't do the culture and the organization change for you. It just becomes a tool that greases that. It makes it a lot easier to get that to get that done. What specifically in the tool that works for customers that's resonating in your tool? What's the big impact when people engage with you guys? When do they know when to bring you in for the tool? Sure. Let's just say that the guru's coming in. Hey, here's the culture. You know, you do some yoga or whatever you got to do and then culture-wise, you make that happen. You come in, what do you do? So for us, we're kind of, I guess, more the bottom up, right? It's usually a team that says, hey, we're getting overrun with these requests. Or it's this team that's saying, we've got to get, you know, like it can be as simple as our restarts are a mess. There's too many ways to do things across all these tools. And then it's, hey, these people keep bugging us to do this. Or that team keeps bugging us to refresh this environment. Or this team, we need to give them access and something goes wrong in production to run some health checks to see what's happening. So really those kind of operational support type of use cases is generally at the team level being brought in to solve these different problems. And then where really the gas gets poured on is when the upper management is following all the DevOps and SRE conversations and realizes things need to change. Then they usually see Rundeck ask, ooh, we can use that, right? That's going to help us unlock things. And let's do more of that. And it spreads from team to team. So you're really not trying to come in and boil the ocean over. You come in on a very specific, you know, entry point and then get momentum and scales. I mean, we get organizations that aren't touching their culture at all. It's literally just, we're doing things, the old classic off-shored, kind of application operations call center model. And we're just going to get better at that and use Rundeck to create more capacity, standardize things, bring some more people into this process. And that's it. And they're very successful as that. And then, but the really exciting ones is when the code gets caught up into the larger organizational transformation. You mentioned SRE, site reliability engineers. Google used that term. So I got to ask you, we talked before we came on camera about NoOps, you know, having a NoOps culture because DevOps is more developer. And we were kind of poo-pooing that and you were kind of more aggressive. I won't say, well, you said to me, because, you know, children's show here. Yes, I'm sure a lot of children are watching the queue. The ops guy. No, pun intended. So Google is really hardcore on this. Do you have an opinion on this? Ops, NoOps, DevOps, roll-of-ops. Ops happens, right? I mean, Ops, every day, you know, John Allspot was formerly Dead Sea and now he's kind of a researcher, does this thing at Confidence where he says, everybody raise your hand. If I locked everybody out, so hands off the keyboard, you can't do anything. How many of your companies would still be in business tomorrow, or in a week, or in a month, or in a year? And people's hands kind of going, going too much, you know, a day in a week, you know? And the reality is operations happens, right? And these are complex, you know, moving systems, interacting with complex things in the world. And you have to be able to operate them. So, you know, the original NoOps idea was, oh, I don't want to have a separate thing called operations. I want to distribute to operations where it makes sense to have engineers everywhere. Google has an interesting view, which is, no, we have a distinct organization, but they call it SRE, and they use more software engineering discipline to do. They have a whole kind of methodology behind it, but they're very much proving you can still have a separate engineering and operations organization and do it right. And then there's folks like Netflix and, you know, in Amazon or more like, no, no, we're going to distribute it within these cross-functional teams and new organizations. I mean, it's still, no matter how you slice that, but here's the thing. I mean, my observation, people get confused with automation and operations. So just because you're automating something doesn't mean it goes away, right? You might, you know, automate some tasks and things. Or it can make it worse. Yeah, so talk about that pull, push, that tug between that, because it's attention that's positive, because you want to automate things that you're doing multiple repetitive tasks on, but you just eliminate some tasks, but you're still operating. Talk about that, Daniel. Well, I mean, there's certain things computers are very good at. Repetitive, knowing tasks, computers are great at. When it takes human creativity or sort of the super kind of complex connecting the dots, humans are good at that. So how do you automate as much of the things as possible that the computers are good at? And that gives you the time and the cognitive bandwidth to focus on the creative things, creative in building things, creative in, oh crap, we got to solve this, right? And the tool should be there to support that. The idea that you can automate all of that away, it just, it's not, it's just not that well. Give an example of that. If you look forward five years, I think about how we're moving fast with the evolution of the cloud, everything else that's happening, Kubernetes, IoT, AI, all this great stuff's happening. You got blockchain, you got crypto, and a lot of things going on that are super positive that it also could be detrimental. Where does the human piece come in? Where will always be the pieces where human creativity, human intuition, human judgment, where is it always going to shine? What specific things do you see never going away? I think that's what you said, the intuition and the judgment, right? In the day-to-day work activities, you need to use that intuition and judgment to get things done, to see the different signals and understand what they mean, to create new solutions on how to kind of solve these new challenges. That is where the human beings are needed. So it's both in the delivery time and in the idea of operations. You think of like an airplane, right? You know, there's still pilots. You think of a nuclear power plant. There's still operators. Tons of automation, tons of alarms, tons of things to assist them, but it still comes down to the things that human brains are good at. So there's always a role for- So categorically, obviously security, latency is the one, multi-cloud workload movement, is the areas that you start to see the categorical areas that are never going to go away, right? Yeah, and at a certain point, you're going to things where the platforms get better, and you kind of climb the stack. And more things that only human being could do in the past, you can start to use, you know, to automate things. Like deployment. Deployment used to be human task. Now we start to standardize things, have standard parts, have virtualization, now the cloud, now, you know, now all the cloud-native technologies, that allows you to say, okay, we standardize these things and built the right tooling. Now we can focus the humans on more important problems and move at a higher velocity with better quality. Great. Awesome. Well, I mean, great stuff. Okay, what's going on for you? What are you up to now these days? What events are you going to? What are you working on? What are the cool things you're excited about right now? Cool and excited about. The DevOps Enterprise Summit, you know, I've been involved that number of years. That is the best collection of, I think, enterprise, you know, big corporation thinking around a whole kind of sphere of transformation. And it's growing too, so just, right? Yeah. Give a quick plug-on. Yeah, yeah, that's growing. It's because there's one now, there's one in London, there's one now, it can be in Las Vegas. You know, 1,000 to 2,000 people. I thought SREcon, SRE is the, it's like a specialized implementation of all this DevOps thinking. I think that's another great place to be. And then, you know, DevOps days, velocity, all the kind of traditional conferences in these. Great community, got to say, being involved in the DevOps on day one, watching the pioneers, and a few with arrows in their back, but now going mainstream, it's super exciting. I think Kubernetes brings, you know, that mainstream highlights everything. That's that platform, let's talk about that. A lot of the concerns that human beings had to struggle with on a day-to-day basis are now being put into the orchestration and scheduling and, you know, the containerization of things. Producing, producing. David, great work. Congratulations on all the work you've done. Been a real contribution to the industry. Oh, thank you. And good luck with the business. Thanks for coming on theCUBE. Yeah, thanks for having me. All right, this CUBE live coverage here, Mountain View for Cisco's DevNet Create. Really the Cisco's foray into cloud native, really getting at that DevOps culture once solving big problems, programming the network. Cisco's bringing that together with their communities. Of course, CUBE's here covering it. More live coverage after this short break.