>> Announcer: Live from the Computer History Museum, in Mountain View, California, it's the Cube. Covering DevNet Create 2018, brought to you by Cisco. >> Hey, welcome back everyone, this is the Cube's live coverage here in Mountain View, Califonia, for Cisco's DevNet Create. It's their cloud native developer ecosystem. A new initiative, only a year and a half old, great, cloud native dev ops oriented. I'm John Furrier, your cost with my co-host Lauren Cooney, our next guest is Damon Edwards, Chief Product Officer of Rundeck. Welcome to the Cube, good to see you again. >> Yeah good to see you again as well. >> So, you were just on stage giving a talk. >> I was. >> About ops, dev ops. >> I was bumming people out, that's what I was doing, so all of the Cisco early stuff was about new products, new toys, 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 names we changed to hide the not-so-innocent, we went through some incidents and tales of woe and how the disconnects, and basically the siloed way of working, number one, group like with like in 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 physics of 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. I ask you to do something, I write it down, you take it off the queue, you know, a week later, the context is all different, right? So you have all kinds of bottlenecks, all kinds of quality problems, all kinds of delays, and it's an expensive way to work. Yet that has become the defacto way that we run our lives. And studies and 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 no surprise that silos and ticket-driven request queues, that we get what we get. And so the talk was about how to say, well how can we stop using tickets as the primary way of doing things? How do we look at the organization and remove the need for hand-offs between the silos, and then replace, where we can't get rid of the hand-offs, with self-service, right? Pull-based self-service interfaces where people can get what they need to get done, do those operational tasks themselves, and then move on >> Lauren: Great. >> That's what it's all about. >> 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 because it's kind of the ugly underbelly of development ops. 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 fix 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 Rundeck factors into this is that we make tools for SREs and systems administrators to, number one, organize all their scripts and tools, connect all their scripts and tools, 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 the 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 do them. By doing that, you're creating more capacity in operations to focus on issues you really need to be solved, and you're making everyone else happy because you're staying out of their way. They can move faster, have fast feedback, higher quality, all of that stuff. >> You know we've done a lot of crowd chats and we had the questions come up, Is it the culture, or is it the tooling, or is it the people? Thinking all of the above, culture, everyone goes to the (mumbles), yeah the culture's going 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." 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 tool do they need to use? What are you guys providing? Where is 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, okay we're going to solve this problem, we're going to teach everybody to use this one tool, so everyone's going to learn this DSL or this language, it just never works. I mean, you know, three years ago it was one tool, we all know the name. Couple of years ago is was another tool, we all know the name, you know, these configuration management tools. Now we're on to the new container world, 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, you know, how do we two things? Limit those hand-offs, so that kind of is more of an organizational issue. And number two, all those hand-off points, Anything I need something from you John, you know, or you Lauren, I don't want to have to say, "do this for me, and you do this for me." 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 normally do. Hit an automated service, sort of like, don't do the old Savist managed service 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. 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 of the scenario, get more capacity and I get what I want without having- >> So is microservices going to impact operations in a way? Cause then 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 manufactureability. You have to build the services for operability, and so that's number one. And with the new microservices decoupled world, you have to move to this model of operations because the old model that did work balances across these silos, it just doesn't work in this decoupled world. It makes everything kind of grind back to a lumpen 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. >> So how long is it taking for customers to realize the value of your solutions that you bring to the table? And how much time is it saving them? >> Yeah, I mean, for Rundeck specifically, because it doesn't force you to learn new languages, you can start with what you've got today. So literally it takes days, right? Start plugging in things that you have. You can set up the access control. You can set up the options interface, and next thing you know, I've got this self-service interface and I can turn around and let somebody use it. So, you know, Rundeck doesn't do the culture and the organization change for you. This becomes a tool that greases that, makes it a lot easier to get that. >> 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? Let's just say that the gurus can... hey, here's the culture, you know, you do some yoga, whatever you got to do culture-wise, make that happen. You come in, what do you do? >> Sure, so for us, we're kind of more the bottom-up, right? It's usually a team that says, "hey we're getting overrun with these requests." Or it's a team that's saying, we've got to get like- it could 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 to something that goes wrong in production, to run some health checks and see what's happening. Really, those kind of operational, support-type use cases. It's generally at the team-level, be 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 dev ops and SREs conversations and realize that things need to change, then they usually see Rundeck as, 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 entry point, and then get momentum and scales. >> Yeah, we get organizations that aren't touching their culture at all. It's literally just, we're doing things the old, classic, off-shore, 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, the really exciting ones is when the coder gets caught up into larger organizational transformation. >> You mentioned SRE, site reliability engineers. Google uses that term. So I've got to ask you, we talked before we came on camera about "no ops", having a no ops culture because dev ops is more developer. And we were kind of pooh-poohing that, and you were kind of more aggressive. I won't say what you said to me because it's a children's show here. >> Damon: Yes I'm sure a lot of children watch the Cube. (laughs) >> The ops guys, no pun intended. So, Google is really hardcore on this. Do you have an opinion on this? Ops, no ops, dev ops, the role of ops? >> I mean it's ridiculous, ops happens, right? I mean, ops everyday. John Alspot was a formerly dexy, and now he's kind of a researcher, does this thing at conferences 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... You know, a day and a week, you know? And the reality is operations happens, right? These are complex, moving systems, interacting with complex things in the world, and you have to be able to operate them. So, you know, the original no ops idea was, oh I don't want to have a separate thing called operations, I want to distribute operations where it makes sense, 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. We have a whole 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 Amazon who are more like, no no we're going to distribute it within these cross-functional teams and organizations. >> And they're still ops no matter how you slice them. But here's the thing, my observation... People get confused automation and operations. Just because you're automating something doesn't mean it goes away. >> Damon: Right. >> You might automate some tasks and things- >> Damon: Or it could make it worse. >> Yeah so talk about that pull-push, that tug between that. Because it's the tension that's positive, because you want to automate things that you're doing multiple repetitive tasks on. But that eliminates some tasks but you're still operating. Talk about that dynamic. >> Well, there's certain things computers are very good at. Repetitive, no-end tasks, computers are great at. But it takes human creativity, or sort of the super 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. That's creative in building things, creative in "oh crap, we've 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 is not- >> Give me an example, if you look four or five years and think about how we're moving fast with the evolution with the cloud and everything else happening. (mumbles) IOG, AO, all this great stuff's happening. You got blog chain, you got cryptocurrent, a lot of things going on. That is super positive, 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? >> It'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 solve these new challenges. You know, that is where the human beings are needed. So, it's both in the delivery time, and in the idea of operations. If you think of an airplane, 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- >> So categorically, how you see security, latency is one, multi-cloud, workload movement, is the areas that you start to see the categorical areas that are never going to go away. >> Yeah, and at a certain point you're going to have things where the platforms get better, and you kind of climb the stack, and more things that only human beings can do in the past you can start to automate things. Like deployment, deployment used to be a human task, now we start to standardize things, have standard parts, have virtualization, now the cloud, now the cloud native technology. That allows you to... Okay, you've standardized things, you've build the right tooling, now you can focus the humans on more important problems, and move at a higher velocity and better quality. >> Lauren: Great. >> 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? >> What am I excited about? The dev ops enterprise summit, I've been involved with that for a number of years, that is the best collection of enterprise, big corporation thinking around the whole sphere of transformation. >> John: And it's growing too. >> Yeah, it's growing. There's one now in London, one now going to be in Las Vegas, you know, 1000 to 2000 people. SREcon. SRE is a... It's like a specialized implementation of all the dev ops thinking. I think that's another great place to be. And then devopsdays, Velocity, all the traditional conferences. >> Great community. You've got to say being involved in the dev ops from day one, watching the pioneers, a few with arrows in their back, but now have gone mainstream, super exciting. I think Cooper Netties brings that mainstream, just highlights everything. >> Yeah, that's that platform I was talking about. 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 the containerization of things. >> Damon, great work. Congratulations on all the work you've done. You've been a real contribution to the industry. >> Thank you. >> Good luck with the business. Thanks for coming on the Cube. >> Yeah, thanks for having me. >> Alright, this Cube live coverage here in Mountain View for Cisco's DEVNET Create. Really the Cisco's foray into cloud native. Really getting at that dev ops culture, solving big problems, programming the networks. Cisco's bringing that together with their communities. Of course, Cube's here covering it. More live coverage after this short break. (electronic music)

>> Voiceover: Live from San Francisco, it's The Cube covering DevNet Create 2017, brought to you by Cisco. >> Welcome back everyone. We're live here in San Francisco, The Cube's exclusive coverage of Cisco's inaugural event DevNet Create. I'm John Furrier with SiliconANGLE. My cohost Peter Burris, general manager of wikibon.com research. Next guest is Damon Edwards, co-founder of Rundeck. He's been on the crowd chats and does event DevOps and the enterprise, the content chair, co-founder of Rundeck, welcome to The Cube. >> Thank you. >> Great to meet you. >> First and we've >> Good to be here. been in line chatting away. Quick though from you, Cisco getting into DevOps, the conversation's pretty straight forward. We think it's awesome that they're doing this. >> Damon: Yeah. >> Good direction, right in line with DevOps, things looking good, middle of the fairway. What do you do next? >> Damon: Yeah, I mean ... >> Where does Cisco take the ball from here and take it home? >> You know, I think it's just more of the same. I think that you can't underestimate the split that's happened in the DevOps have and have nots, that sounds kind of odd, but a lot that we talk about are the unicorns, the high flying special built organizations that really grew up with this in the last five to 10 years. I think where Cisco really plays is in the other 99% of commerce of the world, which is the core classic enterprises. DevOps really hasn't made that deep of a dent yet into that, I guess we call it dark IT, right? The rest of the world the people have to deal with 30 years of, in some places, different technology, skills, acquisitions, mismatches, all the legacy, all the bureaucracy of large organizations, and Cisco has a path into that and a voice of authority into that. So happy to see they're putting such emphasis on these DevOps and Agile ideas and help to drive them into that. >> And they got the app dynamics things going down too, that big acquisition. Their slogan is Where Apps Meet Infrastructure. We always just talk about infrastructure as code. They're talking about programmable networking, which is the same thing. We want more programmable. >> Damon: Right. So how do they make that transition to this new operational model? I mean, networks used to be very fragile, set in stone. >> Damon: Yeah. Someone used to joke, "Hey, they're called NoOps," because they would say no to everything from a developer standpoint. >> Damon: Sure. >> How do they transition from NoOps to a new operational model that's agile and adding value? >> The bigger issue here is that Ops is getting squeezed, right, so it's an existential crisis for them. The reason why they were always the no folks is because they're always spending their time protecting that capacity because they're overrun, they're always outnumbered, first of all, then they're being overrun with all these tickets of new stuff coming in plus incidents happening in the middle, the capacity has always been an issue. Now with this new DevOps, and really digital transformation inspired pressure, it's go, go, go faster, open things up. At the same time the same business folks are saying from the other direction lock things down, don't be the next hack. Don't be the next breach. Don't be the next major outage, right? >> John: It's really a lot of pressure It's a pressure cooker. >> Right. >> So they're squeezed. So the biggest with crisis, how do we relieve that, how do we relieve that pressure? And the key technique is to be able to actually allow other people to participate in what traditionally was only operations tasks. If you allow me to go one step ... >> John: Democratization of operations in a way. >> It is, and what they're doing, you see the organizations that really nailed this, they're dividing up the idea of an operations procedure. It used to be everything was in operations. You defined it, you ran it, and you have all security and management audit control over it. In these new ways what they're doing is they're breaking it up into three pieces to say the ability to define these automated procedures, the ability to execute them, and the ability to have that management control and oversight, let's make those in three discrete parts and let's move that to where the labor capacity makes the most sense. By doing that, operations can free up those bottlenecks, start to decouple more, allow the rest of the organization to move a lot quicker and not be in that horrible position of being squeezed to death and having to tell everybody no. >> There's a number of reasons why it's happening. Sorry. One of the key ones is that, and it brings us back to the Cisco conversation we're asking about this, is that is used to be that operations was tied to a particular asset. The server more often than not. And so a single individual could pool all those things together because a single individual, or single group, had control over virtually all the resources >> Damon: Right. >> that were a part of that. Now we're talking about applications that are inherently distributed, and so we can't look at the process of operations in the same way. This comes back to Cisco. Does the world need to think more discreetly about these new highly distributed, deeply distributed, applications differently, and is that going to catalyze the diffusion of more of these high quality DevOps principals? What do you think? >> Yeah, it has to. If you look at the business driver, which is this digital transformation, a lot of people scoff at because it's like wait, is this 1999? You need a website? What are we talking about, right? But you realize what it is is saying all these disparate systems we used to have, right. I could get my cable bill, but it's just online, it's just a PDF of what they send to the printers, right. But now on it, everything I could do when I call up the customer service agent, I want to do it through my phone or I want to do it on my laptop, and that means all those formerly distinct systems that lived in different windows on a customer service agents desktop and after the little things to check the router status blew up, well I'll just talk past it, right. But now it's really going to matter in this digital world. The business is driving that integration, so where things don't live in isolation anymore, and because of that the complexity and this distributed nature of these services is rising. >> John: Yeah. >> And when that that happens, that makes the operations inherently more difficult and just contributes to that squeeze even more and we got to find a way to relieve that. >> Great point and great analysis. That just picked off what we were talking about on our intro package of the redefinition of what a full stacked developer is. >> Damon: Yeah. >> Now full stack implies you're talking about a distributed application model where there's no isolation anymore so you could almost argue that that's going to be obsolete. It's a full horizontal developer. >> Well logic used to be full stack, but how they connect will be different. >> Which just brings up the notion of, okay, things were in isolation >> Right. >> built to the database, now I go down the network, now a whole new developer category potentially is emerging. Do you feel the same way? >> Damon: Yeah. >> I mean, we're speculating. We don't actually know. >> Sure. I mean, if you are Netflix, who prides itself on it's ability to go out, pay top of market, which means they are the top of market, and attract the best talent, only one can win that game. For everybody else in the world, this idea of we're going to have these polyglot, super human, I-know-everything engineers, it's never going to happen. We have to find a way to use our systems and our processes to allow that kind of integration to happen, and allow those people to define the control procedures and policies for the things that they know about, and then allow that all to integrate to where then we can have other folks operate it and run it. Again, that idea of moving those part around to where we can best take advantage of the labor, otherwise you're just ... You're never going to find it. Go to any conference, NASA DevOps Conference, and ask people how many LinkedIn spam messages do you get a day because the word DevOps is in your profile? >> Yeah. >> Everybody just laughs because it's dozens. You're never going to have that idea so you have to build the systems to recreate that full stack capability. >> And have people that have access to be one, rather than super human that becomes democratized at that level. >> Damon: Yeah. >> It's interesting. One of the things that you guys did at the DevOps Enterprise Summit, I know you were in the content chair. >> Damon: Sure. >> I made a note here for my ... Make sure I get this question to you, was I like this thing you guys touched upon. Is DevOps best left to grow organically or is there a growing need slash desire for an agile manifesto? (laughs) The top down, do the manifesto, or organic ... Thoughts? >> Yeah, I'd say no, because what DevOps is is a series of problem state- It's an umbrella over a bunch of problem statements and a bunch of solutions that keeps evolving. This is why the Devs conferences are so interesting because it's practitioners talking about what's worked for them. I feel like at the highest level, if you really need to have a definition, go ahead and read the Phoenix project or the DevOps handbook. They've done a great job of collating all of that, but at the end of the day it's not one thing. It's not a single practice. There's no single thing you can do to say I'm going to transform a major global financial services company into a fast, nimble operation. There is no one thing. It's a series of things that you have to try over and over again. Look at DevOps as a movement where you can learn from practitioners, apply it to your own organization, see what happens, report back, try some new stuff, and so on and so forth. >> So you could basically have a manifesto, but it's really just more of marching orders. Organically, it has to form on its own. That's basically the same. >> I think there already is. >> You could say hey we have a manifesto, but it's not like this is the playbook. You can get >> Damon: There is >> the handbook to learn. >> no playbook. >> Exactly. Okay, cool. Well, appreciate the insight. Let's talk about your business. What do you guys do? >> Damon: Sure. >> What are some of the things that Rundeck's doing that you're the co-founder of? Share a little bit about the company. >> Yeah, Rundeck is at the what is it, it's an orchestration and scheduling platform and it's used by operations organizations. Generally from large startups, but also large DevBox unicorns, but also a lot of large enterprises. What they're using it for is for defining and improving their operations procedures. What happens after deployment? Where do we define all the procedures to manage all these disparate systems, all these islands of automation. Chef and Puppet was the hottest thing around three years ago and now it's Docker and Kubernetes and everything else, and now we still have our old power shelf stuff, our late logic over there, some OpSquare stuff over there, so what are we going to do? We need a way to define the procedures, expand all those and allow people to participate in that operations world so they can relieve that crunch. We see a lot for automating the creative standard operating procedures like classic Runbook automation, with a next generation twist, we'll say, but we also see a lot of self service operations, meaning that let's let other people participate. Let's let developers define these procedures as Rundeck jobs, and then let operations vet them ... >> That's where you're talking about the operational being relieved a bit. >> Yeah, you have to. You can't just say there's one little group here that's going to deploy and run all of these things in this world. We have to let other people participate in that. Not just for deployment, which is big in the DevOps world, but for what happens after deployment that nobody wants to talk about. All the escalations, all the interruptions, all those problems, Rundeck really plays in that area help people to get that under control. >> Damon, thanks so much for sharing your insight. Congratulations on your startup and great to meet you in person. >> Yeah. >> We've had great chats in our crowd chat. You guys have been awesome with Gene Kim and the community that you're involved with with DevOps for the Enterprise Summit, practitioners sharing. That's a great ethos >> Damon: It's a pretty >> That really aligns >> awesome bet, yeah. >> with what's going on in the industry. Congratulations. More Cube coverage here exclusive of Cisco's inaugural event called DevNet Create, an extension of their DevNet core classic network and developer systems at Cisco. This is an open source one. This is out in the community. Not all Cisco, all part of the community. And of course we're bringing it to you with live coverage. I'm John for Peter Burris. Stay with us. (upbeat music) >> Hi. I'm April Mitchell, and I'm the senior director ...