>> Narrator: Live from Austin, Texas, it's theCUBE covering KubeCon and CloudNativeCon 2017. Brought to you by Red Hat, the Linux Foundation and theCUBE's ecosystem partners. >> Welcome back, I'm Stu Miniman and you're watching SiliconANGLE Media's Flychip Production of theCUBE. We're here at CloudNativeCon and KubeCon here in Austin, Texas. Happy to welcome back to the program, a many-time alum Tom Joyce, who is now the CEO of Pensa. Tom, great to see ya. >> Great to see you too. >> Alright, so Tom, we've had you on, so many different ecosystems, so many different waves of technology. Talk about Pensa, how it fits into this whole cloud native space that we're looking at this channel. >> Great, yeah, and like you said, you and I we've known each other a long time, we've seen a lot of revolutions in technology, and we're in the middle a number of them right now, and at this event you've got the Cloud-native folks and you've got the folks that are tackling connectainers and Kubernetes orchestration. You know, it's interesting, this crowd here is so young, and so creative. The last few days, I was at the Gartner Data Center Infrastructure show, and-- >> Stu: Not so young there? >> Not so young, but the same problems, right? Two different communities trying to solve the same problems. Which are how do we deal with insane complexity? How do we deal with an environment that's now not just three public clouds and some hybrid clouds, but a growing list of specialty clouds. How do we manage all of that? And what Pensa is trying to do, is be a part of solving that problem, using intelligent automation technology. Especially in managing the underlay complexity, the infrastructure layer. It's kind of funny we've gone through a period of time when the whole discussion has been, hey, containers are going to be at Pensa, and infrastructure doesn't matter, and infrastructure is going away. I think there's some truth to how that is evolving, but it still matters especially when you get down to having to deliver services to customers. >> Tom first of all, Dan Cone got on stage from the CNCF, and he said, "It is exciting times for boring infrastructure." >> Tom: Yeah. >> Maybe too exciting. I love that line, because every wave comes out, it was like, Tom you remember, virtualization, I'm not going to have to worry about things like that. >> It's been the biggest revolution, and it is the biggest wave of infrastructure ever. >> We spent a decade fixing that. Containers came out, oh, once again we're extracted away and it's going to take that. So, what do you see as that role, between the infrastructure layer and that cloud native? What are the big challenges? What are your customers seeing, and how Pensa have an effect? >> Well, I think what we're seeing, in my opinion, is we're going from operations running everything to DevOps, to now their starting to talk about NoOps. How do we get to a point where-- >> Ah, we might have argued over the terminology. We need Ops, obviously. >> Here's what I think, I think it's going to be less Ops and more architecture. I think the challenge becomes around, how do you do the design, how do you architect these systems so that they'll work and not fail. It's a lot like one metaphor I heard somebody use and I'm going to steal is we went from drafting on a sketch pad, using CAD technology, to using 3D CAD technology, to automated CAD technology, to now servers providing it. Right? And what happened? Everybody got smarter about architecture being the important part, not the actual physical plugging together. I think the role of the architect, in a cloud native environment, in a Kubernetes environment, in a VM environment, is frankly more important than ever. Somebody needs to know how the tools work, to make sure the the service levels actually deliver. I have sat in a lot of these meetings where people say, "Look, just put your old app in a container "and you can run it anywhere, it'll be fine." Somebody needs to think about the architecture. We want to provide intelligent technology that helps them do that. Like AutoCAD and like some of these things that came along in that ecosystem. >> One of the things I've been poking at, you know, most of this year and coming into this show especially, is people say, "Ah, it's too complicated." The response really is, "Well apologizes, it's never going to get simple." What we need is, I need proper tooling, things like automation to be able to help because humans alone will not be able to fix that. I really need to have the combination of the tooling, proper architecture, as you said. What are you seeing, how's that playing out in the customer environment? >> I think what we're seeing is folks figuring out that number one it's cross domain and cross cloud. So whatever you design needs to work in multiple different environments that are going to end up having different capabilities. Nobody really has deep expertise and everything about networking, everything about containers, everything about compute and storage, but all those things still matter. What folks are asking for is a layer of technology that kind of arbitrates between the underlying infrastructure and the upper level applications, they're actually trying to deliver. And that's where this automation layer, that's submerging comes in. Part of that orchestration, and part of it's what we do. What we're focusing on is design, validate complex designs, build them and deploy them, using tools that help people do that a lot faster and get it right every time. So mistakes don't transpire. >> Yeah, Tom, I want you to help explain to our audience this whole SDN wave, kind of it played out, and sure Vmware NSX and Cisco ACI, they're doing okay, but for a lot of the industry, SDN equals still does nothing. Yet networking critically important, heavily involved in both the container and all this cloud native discussion. How are we fixing networking, how is it being set up for this type of environment versus what we we're trying to do with SDN? >> I think this is a good point, I think you've got SDN and the enterprise. You also have network functions virtualization and the service providers and often overlook that in the enterprise you're going through cloud native and DevOps transitions. And surge providers are going through a revolution of their own. Going from being telcos, becoming digital service providers. The problems are similar that technologies are different. My observation is this, is the hype cycle's real. We've gone through five years of talking about SDN, talking about open stack, talking about network functions virtualization. All of a sudden now, what I've seen in this job is that there's real money getting spent and the technology's being used. NSX's being used in a whole variety of ways that people didn't anticipate. We're seeing in everyone of these service providers, whether they're a classic telcos, they're wired, or they're wireless, or they're cloud. They're investing in technologies to revolutionize how that core of that network works, and how the edged network works. I think the first signs of that are really NSX and SDN. SDN has now gone mainstream because customers have seen that there's a real used case for it. That's kind of your first broadly applicable network function. And I think through the next couple of years, it will be one after another. Those problems are going to get knocked down. Frankly in our business, we started focusing on a lot of these enterprise problems with NSX and VSAN and software defined data center technologies around VMware. We're working on containers, but frankly the biggest area of growth for us is probably going to be these large service providers. It's like a trillion dollar business and it's going to be revolutionized over five years. We're getting involved in a lot of these network functions virtualization conversations. I wouldn't say it does nothing, it does a lot, but getting there, it's been a really hard technology to figure out. >> It took a little bit while to mature. The other thing you've got some strong background on, the management monitoring in this type of environment. What's new? How does that change in the networking space, when we have all microservices and all of these various pieces there? What are you seeing there? >> The short answer is I have a little bit of a controversial view on that. It's not unique but I think-- >> John Ferrer would say, we love controversy here on theCUBE. >> I think monitoring goes away. Monitoring the way it's been done for the last 30 years goes away. I think when we had mainframes, we had client servers, we had internet, and now we have this set of technologies we're working with in virtualization. Every time that transition has happened, there's been a whole bunch of monitoring companies. I think classic monitoring is eventually going to go away. Ultimately, there is a lot of complexity, and the machine needs to manage it, right? The machines going to need to manage it. The eyeballs watching the problem and remediating it to a greater and greater extent, are going to be automation technologies. Versus throwing out more and more alerts in front of a human that says, "I'm just going to turn them off "because I don't know what this means." I think automation technologies are going to replace classic monitoring. Again, you go around this event here, the folks that are doing cloud native, they don't want to have a bunch of monitoring alerts. They're not going to tolerate that. They just want to deliver an application service. They don't want to deal with operations, they don't want to deal with monitoring, they don't want to deal with problems, they want the problems to take care of themselves. That's hard, but I think that's coming. >> Tom, the end users whether it be enterprise, service providers, there's a lot of technology out there, there's a lot of things happening out there. When do they know to call Pensa? Give us some of the big value problems that they should knowing that say, "Oh hey", "Yes that makes sense to me, I need to give you guys a call" >> You can boil it down very simply, we deal with two kinds of people, and they're really the architects. Think about that CAD analogy. We're dealing with people that are doing complex designs in two areas. One is typically software defined data center. So people that are bringing all of these technologies together and need to deliver a working system, maybe a really complex proof of concept or big systems where they're using VMwear, as an example. We help them get that job done, do it fast. That's what the automation systems we provide do. The other is, in large scale service providers. Folks that are dealing with onboarding VNF's, building complex networks and have been grappling with that, with open stack in some of these early technologies for a number of years. We have a revolutionary way to onboard those VNF's, validate designs, deliver designs and do it in a way that integrates with all the open source technologies people are using. To be honest with you, I don't which of those is going to be more important to us, but their two big areas, and our technology applies to both. >> Tom, you've been CEO at a couple of companies now. I want to get your view point, just being the CEO for a startup in today's landscape, what's it like? What advice do you give your peers? When you guys are grabbing a drink at the bar, what are some of the biggest challenges and biggest things that excite you? >> We are to tired to grab a drink at the bar. I'll tell you that I love this. It is a great mental challenge, because again I've been like you, I've been doing this for over 30 years. It forces you to learn and learn and learn and question what you know. And that's what I really like, the opportunity to engage with the leading edge of technology. Frankly all the folks here are young and creative and it's forced me to become better at what I do. There are a lot more unknowns than working for a big company. With a big company, a lot of what you have to do is laid out before you. In this job, I have to constantly force myself to question what I know, to listen to the customer, to learn new things, and it can be tiring, but it's a good kind of tiring. >> Alright, last question I have for you. What are you most proud, what you've done since you've joined Pensa? And give us a little bit of outlook for 2018, for those that are watching, what should we be looking for, kind of miles stone deliverables or other items. >> I think what I'm most proud of, this sounds like a silly statement, but I'm proud of what the team has accomplished. I didn't do anything, right? I don't write the code. We have a bunch of engineers that are actually delivering the product. I think we've been really fortunate to keep all those people and get them focused on some big problems. I'm proud of delivering Pensa Lab to market, and I'm proud of the customers we've signed up, since we launched that just at the beginning of October. I'm proud of what we're doing with Nokia on large scale networking in the NFP area. And frankly I'm proud of the ability of this team to constantly engage and learn and try new things and take risks and screw up and try again. It's that whole experience, it's good to work with good people that you like. >> Alright and 2018? >> 2018 I think is going to be surprising for the people in terms of the kind of the reemergence of open stack. I think open stack is coming back. >> Don't let them hear that Tom, the wolves will come out. Why? >> Well because I think it's reaching at a point where the economics of certain kinds of cloud models, and frankly the economics of the Mware are forcing people to reconsider. But it especially around digital service providers. These large companies have been grappling with "How do we revolutionize our poor networks" for five years dealing with open stack. And they kind of got a lot of the stuff to work now. I think that is another sort of controversial statement. When I got into this job, I was like "Yeah open stack is dead". I was involved with Helion at Hewlett-Packard, and I was like "That's never coming back". Well guess what, it's coming back. I think the other thing is, we're going to see a lot more money being spent on revolutionizing the core networks, and these telcos and digital service providers. That's what I think the big things going to be. >> Absolutely, we've been at the open stack show for any years. The networking component especially for the telco and service providers, absolutely a strong area of focus. Your average enterprise, might not be looking for open stack. >> There might be pockets. >> Internationally there's some pockets, but absolutely. Tom Joyce, always a pleasure to catch up with you. Looking forward to seeing you the next time. And well be back with lots more coverage here from theCUBE at KubeCon. In Austin Texas, you're watching theCUBE.

>> Announcer: From Hell's Kitchen in New York City, it's theCUBE, on the ground at Serverlessconf. Brought to you by Silicon Angle Media. >> Hi, I'm Stu Miniman with theCUBE, here at Serverless Conference in Hell's Kitchen in New York City. Happy to welcome back to the program. keynote speaker at the event, and a guest that we've had on a couple times before, John Willis, who's the vice president of DevOps and digital practices at Eastray Technologies. John. >> In Hell's Kitchen. >> Stu: In Hell's Kitchen, and go Yankees. >> Yeah, man. I was at the game last night, the other night. Yeah. You'll see tonight. Yeah. Thank you. Glad to be here. >> Great to see you. So look, you've been talking to audiences about DevOps for as long as I can remember, as long as I've known you, definitely. Tell us, what's so important about serverless and how that fits into the world of the developer these days. >> Yeah, I mean, my interest, you know, I was invited to do a keynote, and my interest is to break down the tribal nature of new things. And I sound like a hypocrite because I'm the DevOps tribe, but I prefer to stop calling it DevOps, because there are super patterns that exist, and as I watch serverless, I spend a lot of time having these conversations around that yeah, we don't need that DevOps anymore, because we got serverless. It was the same reason like we didn't need any of the infrastructure stuff because we got cloud. And like, we keep throwing the baby out with the bathwater, and my presentation this morning was like, it's not about the technology, stupid. Like the principles of business value, how you understand value stream, how you inject the governance, the policy, the security, the values and the outcomes that you want. I know those sound like platitudes, like I get a sense that we're making the same mistake over again, and hey, sorry folks, Serverless is just another form of compute. Sorry to get you all wound up and then let you down. It's just compute, folks. And so all the core principles that we've really learned about high-performance organizations apply, they apply differently. Monitoring is differently. How do we deliver? But the principles stay the same. And that was my core message today. >> Yeah, no, very passionate, definitely came through in the keynote. I just have to ask you just on the tech for a second, I mean you were heavily involved in containers, you were part of a company that got acquired by Docker, you were a big proponent of unikernels, now it's serverless, how do you kind of paint that picture >> I think it's amazing tech, and more these days. So I left Docker and I'm going back to something I did 10 years ago, which is kind of consulting but transformation type consulting. It sounds platitudish, but like, I'm back in the mode of looking at things at bigger scale. How do you change an organization to think differently about things? So I've kind of taken a little bit of my tech hat off. I mean, I love containers and minimal delivery, right, I've been yacking about that for like the last two or three years, right? About how minimal delivery models work. And serverless is like, amazing too, like unikernels was an interesting model of function as a service. I think serverless will eat up a good portion, you know I've said this, and I don't know, I may have to modify it. You know, I would say four years ago, three years ago, and you guys been a big part of this discussion. The world went to most companies would say we're a cloud-first organization. I've been saying for the last couple of years, I think most organizations should now thinking that they're a container-first organization. So that doesn't say everything, it just means, and I think the world now should be kind of still container first, and I know that might sound horrible to serverless people, but then look at serverless functions as a place where it fits in the architecture, repeatability, and containers. And there's actually kind of a.. >> Is that just from a maturity standpoint, you know, containers a little bit more mature than serverless? >> I don't know that it's, I think there are like, there are models of architecture, right, and I don't know that, I mean I know there's a lot of successful startups in certain value streams and enterprises that are all serverless. I know a couple of friends that have built complete infrastructure on Amazon Lambda. It works. I just don't know that all value stream delivery of services will go complete serverless. I'm pretty certain that today, almost all applications can run on containers. So I'm not creating a division of war. I'm just saying that I think, and I could be dead wrong on this, but I think in this future like placeholder where we're container first, it's going to be, give me an exception of why it can't be containers left, like it has to be cloud, or it has to be bare metal, or it has to be (mumbles) and the right side is about mapping reusable functionality in functions. So I think you have like a container-first world assumes that smart architecture mandates repeatable functions in a function-like world. Does that make sense? >> Yeah, it does. So I think back on my career, there's so many times we said like, oh, we've got this new way to really simplify the environment and get rid of things you don't need to worry about. You know, I lived through the whole virtualization, oh wait, networking storage took us a decade to fix that. >> Yeah, yeah, yeah, yeah. >> Containers, oh we're going to just focus on the application. Oh wait, networking really important, you worked on a whole company focused specifically on that. >> DevOps for networking, yeah. >> Serverless, the question is, what's the rule of operations when it comes to serverless? >> Again, that's my thoughts on serverless and if it ain't right that's secondary to my real passion right now, which is when I hear the word NoOps for serverless, I cringe. Like this idea that you don't... I mean it's different. Do you need observability and telemetry in a serverless world? I ask you. Of course you do. Do you need to have repeatable patterns of delivery to make sure you don't have vulnerabilities in your code? Of course you do. That's Ops folks. And it's about supply chain and building repeatable, structured delivery with all the gates and the checks and the units, and none of that I believe goes away with serverless. Just like it didn't go away with cloud, just the way it didn't go with virtualization, right? So I think you know, we make a big mistake to think serverless means we don't need operations now. Does it mean that our providers, we have a different relationship with our providers? We don't own the server anymore. So we can't run detrace or those kind of things in that environment. But we still own the service. So who's the site reliability engineer for the service that's running on Lambda? Or functions of serverless, right? If it ain't, I mean if you don't got one, like you're going to have a bad service. >> Yeah, what are you hearing organizationally, what's happening in companies that you're talking to? You know, I was a at a show recently, I think it was Kelsey Hightower I think, it was like DevOps is a given at this point. So do you see that, you know, where's the line from what you've seen? >> Well the curse and the blessing of DevOps, the curse is we've never had a clear definition of it. I say we, you know, everybody, but. And the blessing is we've never had a clear definition. Like it's always emerged. And the problem is, I will tell you what my definition of DevOps is, it has really very little to do with technology. It has to do with human capital and how you create high-performing organizations and the principles and practices that lead to that. The DevOps handbook, if you will, is a lot about, that I co-authored with Gene and Patrick and Jez. Those things, that's my definition of DevOps, but the problem is, when you hear people have discussion about DevOps in lieu of a good definition, you can't really get upset when somebody thinks DevOps is like Jenkins and Sheffer Puppet and Ansable, and like oh no, you're wrong, right, like that's their view. So the problem that you run into then is, if your definition is that it's pure technology and it's tied to kind of cloud, and it's something like infrastructure is code, then in your world and your definition, serverless is going to make all that obsolete, or a good portion obsolete. But if your definition is more about how you create patterns and practices around humans who deliver services a certain way, then nothing about serverless makes any of that obsolete. >> All right, Jon, want to give you final word. What do you think people, that you know, just hearing about serverless first time, where do they start, what kind of things should they look at, or you know, if there's other things you think they should probably look at first? >> You know, I think you're asking the wrong guy for that really. I think there's far better people that you've interviewed take care of that. I mean I would go with Peters Brook, the founder of this conference. That was a book I read, he gave me a copy, it made sense to me, I was able to do some labs and then you know, as they say, the rest, Bob's your uncle, you know, there's a ton of stuff out there to figure out how to navigate. >> Anything, any commentary you'd make on the community for here, a couple of people just you know, it's new but very vibrant, reminds me a lot of the emerging tech where, you know, a lot of help from the community, it's pretty easy to get started. >> So yeah, so in the technology, yes. A lot of vendors, a lot of good stuff, great conversations, and I was actually pleasantly surprised there was less discussion about NoOps or you don't need operations, and I got kind of a little bit of a cheer when I mentioned that this morning. So it seems like there are some good lessons learned that I think the message loud and clear is that operations still exist, it just has to be thought about. The keynote yesterday, the gentleman in the keynote yesterday said, day one, closing keynote, said serverless things are different, in some case easier, but harder in other things, and that was through a cloud. Cloud was much easier from getting infrastructure but we ran into a whole lot of operational issues around how to match this cloud to scale. So serverless is easy to create a function, get it set up, cost-effective, but we're starting to learn all of the complex operational issues of MTTR, how do you restore stuff, what does SRE look like, I mean this is why we get paid the big bucks, dammit man. >> All right, John Willis, always a pleasure to catch up with you. I'm Stu Miniman, thank you so much for watching theCUBE.

>> 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 ...