 Live from Austin, Texas, it's theCUBE. Covering DockerCon 2017, brought to you by Docker and support from its ecosystem partners. Welcome back to theCUBE. I'm Stu Miniman. We're here at DockerCon 2017 in beautiful Austin, Texas. Had a great party down on Rainy Street last night, 5,500 people and many of them, a good majority of them made it to the keynote this morning but we're digging in with a lot of guests here. Happy to welcome on to the program. I've got a returning guest in a new role and I have a new guest. So both of you from Puppet, Deepak, Geary Thera Gopal, who's the CTO and Omri Ghazit, who's the Chief Product Officer. We caught up with you at a previous cloud role that you've had. Deepak, since first time on the program, you've been with Puppet for a while now but can you give our audience a little bit about your background and your role? Sure, so I've, software guy, have been programming forever, done a bunch of different startups. I actually lived in Austin and was part of the Austin startup scene for quite some time. So I lived, I went to school here, so I've been here for maybe 15 years. Is that a hook of horns or is that a hook of horns? Yeah, yeah. Absolutely. So, UT computer science. And also, fellow Texan, you know, not UT, but from RISE, so. That's right. There you go. Owls are okay too. But yeah, I've been working here for a while. Previous startup I was at did a lot of email archival and stuff like that so I was an early engineer there. We ended up getting acquired by Dell but that was during an era where we charge people based on storage. So the more we could store, the more money we could make but that was really early on into how you use software to scale out a bunch of systems and things like that. So that's how I got involved with Puppet for projects before I actually joined the company. So I ended up using a lot of that stuff to build out all the systems that we had. You know, maintained a lot of relationships with the community, had a lot of patches inside of Puppet Core. So eventually joined the company. So now I've been there for about six years. CTO and Chief Architect. So I'm responsible for all the ones and zeros, I guess. And overall technical strategy. All right. So Omri, how long ago did you find Puppet? And tell us about your role. Absolutely, seven weeks ago. So, you know, fresh, brand new but very excited about this new role. As Deepak said, I'm also a fellow Texan. I went to school with the Crosstown rival and maybe the different city rival at Rice, but we've never, I don't think we've ever beat UT in football. Maybe once. So I don't even know what the Rice equivalent of, you know, hook and horns is. I spent many years at big companies like Microsoft where I helped start.net and was really deeply involved in Azure as well. As well as HP where I ended up being the general manager and vice president for the healing on platform. Before that, I did a number of startups including one here in Texas in Houston that ended up going public. And, you know, the fun thing about coming back to Texas, I was, the last time I was here was OpenStack Summit in Austin. It's always going to get great Tex-Mex. So really enjoyed that last night as well. All right. So Deepak, you've been with Puppet long enough that, you know, there was no docker in there. I mean, containers did exist. Can you walk us through it? You have an architect role. How does containers impact, you know, your product and how your customers are using you? I mean, I think it's, there's a lot of interest. I think there's almost not a, I don't think there's a single customer or really user that I go and talk to. And I talked to a lot of them that are unaware of containerization, right? Like they know it's a thing. I do think though that a lot of them are trying to fit it into their brains. And I think that's kind of the main role, I think, that we kind of play because the products that we build and all the projects that we have, the open source or commercial stuff, you know, it's all about helping people automate, deploy, manage all the software that they've got, no matter what kind of software it is. So containerization to a lot of these folks, they come to us kind of asking, okay, well, I've heard a lot about it or I'm getting a lot of pressure from development teams to start deploying stuff using it. How do we adopt that kind of technology in a way that comports with all the rest of our practices for managing our software, right? Which for a lot of customers, they're still in the process of evolving because a lot of the people we talk to, they come to us to kind of move from more of the older way of managing, deploying and automating their stuff into more of a DevOps kind of mindset where rapid iteration, continuous delivery. So the technology is definitely a big part of it. The processes are also a big part of it, but ultimately I think they come to us saying, this is really cool. It seems very different than virtualization. So how do we actually deal with that? How do we enforce security policies on all these things? How do we deploy it? Can we share code? How do we stand up the container infrastructure itself? I don't know anything about software defined networking. Now I have to. How do I get that expertise and how do I configure that, manage it and the applications themselves that are containerized now, they're just architected and built in many cases fundamentally different ways than software of previous generations and that requires a lot of uplift of the rest of an organization in order to make that stuff possible. So it's happening, but I think there's definitely a gulf between the kind of leading edge and a lot of the stuff that we've seen here in the keynotes today, which has been awesome. There's a ton of great stuff they've announced for systems builders and things like that. I can build custom kernels and all kinds of stuff. That's great, but there's a huge gulf between the bleeding edge tech like that and that tool chain and what I think most enterprises can fit into their heads, what they understand, what they have established practices around and we have to meet in the middle. Obviously we can't bring all the new tech and make it snap to this line of how we used to do things because that's not going to work, but simultaneously we can't just shift everybody over to doing absolutely everything brand new because they have this thing called paying customers and revenue generating software that's already running. So how do you bridge that gap and that's where I view our role is being that bridge to the future. Absolutely, one of the things I liked in the keynote, they said it would be great if we just had this kind of easy button that we do things, but I think as you said, it was you help customers, take what they have, help move them forward, help that make it easier. Maybe when we talk about, you joined the company, why is it exciting at Puppet these days? How do things like containerization fit into your thoughts going forward? Absolutely. I'm super excited to be at the company. I have worked most of my career really serving the developer customer, the developer constituency. And one of the things that I saw working in the container ecosystem over the last few years is that there really is a lot of excitement from development in organizations around effectively packaging microservices in a new way. And the advantages here are real. There is a lot of acceleration that you get, but the larger movement of DevOps is actually how you get that agility, that velocity that Ben was talking about in his keynote today. There's only one mode and that is quick. And that resonated strongly with me because we saw that exactly at large companies like HP and obviously at Puppet now, where at the core of the value that we bring to our customers is helping them transform, helping them do things in a more kind of cross-functional way in a way where they can accelerate delivery from taking months to taking days or even hours. And Puppet's point of view largely comes from the ops part of DevOps and our customers are asking us, what's our role? What's our evolving role in this new world? And that's exactly why it's so exciting to be part of a company that is actually bringing that unique point of view. And most of our customers are asking, great, containers, now what? What about all the things that we have to worry about? What about security? What about compliance? What about reporting? What about kind of having visibility into my entire state of things? That doesn't change just because you go from running things on bare metal to running things in VMs. With containers, you have another order of magnitude increase of the number of things you're managing. And so the management challenges just become larger. And our job, the way that we see our job is to really help our customers transition, employ these accelerant technologies like Docker, like containerization, and the container platforms, but doing it in a way that, make sure that these operators continue to be able to do their jobs to get the visibility and the control they need to make sure that they deliver on the objectives of the business as well. Yeah, I had an interesting conversation with Solomon Hikes earlier on theCUBE here. And he said, his background was actually on the operations side. And when they built Docker, it was with the developers as their customer. What I throw it out to the both of you is to kind of that developer operator and then kind of your enterprise buyer. How's that dynamic changing? We've watched the whole DevOps discussion for many years as to kind of, who do you sell to? Who's actually got budget? Who makes decisions? Is it some C-level management that said, oh, I read about this and do it? Or the developers bubbling things up? Where are things today? What are you seeing? Well, I definitely think the sort of, the era of you have one or two really high-level buyers that make all these decisions about how everything is going to be architected. It's all going to be built in this way. It's all going to work in this way. This is how operationally it's going to work. Security is going to be enforced this way mostly by just saying no to things. The way we make things stable in production is to say no to making changes. If IT of the late 90s was a political party or the 2000s was a political party, the motto would be no we can't. Which doesn't make any sense anymore. So I think in 2017, I view, especially with respect to containerization, I think the big change is around empowerment. And I think the DevOps movement in many ways is about fostering collaboration and empowerment. So you don't want to have a separate security function that just puts, I'm going to secure this application at the very end of the assembly line. That doesn't work. Just like it never worked for quality assurance or anything like that. We'll make it work. We'll put QAN at the very end. Ideally, you want all of that baked in as early as possible. And I think stuff like containers has come, I think the rise of containerization has enabled developers to feel more empowered over a larger swath of the stack than they previously maybe had the ability to be. So if you believe in the idea of a container as being the unit of delivery of software in the future, I mean, that's a pretty powerful abstraction. So if I'm a developer at my laptop, I can put all kinds of stuff into this black box and the power is I have all the autonomy inside that box. I can do whatever I want with it. And that's really, that's very empowering. That's a lot of responsibility. I think the flip side though, and I think something that we've learned as part of the DevOps movement as well is that it can't just be about developer empowerment. It has to also be about operational empowerment. It has to be about security empowerment. If you think about it, there is, I think there's a future. I hope this isn't the one we actually get, but I think there is a future where for example, all developers are building everything with containers or like, great, I can put all the stuff I want in this black box and then here you go. Here you go operations team. Here's this black box and you can do anything you want with it. I mean, that's kind of a 2017 tech version of throwing it over the wall, right? Because the people with the page still have to care about what's inside that black box. And now if you have a hundred development teams doing thousands of containers all the time, that's way more black boxes that you have to manage. So if you're an IT director or a CIO or something like that, and you have to deal with your entire estate of stuff, that's a pretty gnarly problem. And then you have to combine that with all the previous generations of software that you still have and you still have to maintain. So I understand why our customers come to us a lot of times and ask us, is there a unified way that we can kind of model and manage all the stuff that we've got? How do we see inside a lot of these things that are opaque and they are black boxes? So I'm aiming more for a future where the container is used as that unit of delivery for software, but it's used as a coordination point where it's not just developers putting whatever they want in a Docker file. That's developers and ops staff coordinating to figure out how do we stitch these containers together into a proper application? How do we secure it? Does it meet all of our standards and things like that and that's pretty great. Like I'm very optimistic about that. That's a place I want to be in. I just amplify a little bit. It's great to be at a company where the users love the software. I mean, our selling motion typically is a bunch of practitioners that a company really love using our software. And then we get a call from the CIO saying, hey, we have thousands of nodes under management. We would like to have a deeper relationship with you. Let's go have a conversation about that. So that's a fantastic validation of the value of the product as a tool of empowerment. And I would say that, just to echo Deepak's point, it's all about end to end velocity. If you're just making the devs go faster, you're not necessarily relieving the right bottlenecks. And we've seen that even in our own development, as I've come up to speed on how Puppet does things, some of the impressive pieces of focus really are on our own value stream, the technology value stream, in terms of how we get ideas to our customers. We always think about inserting operations folks, security folks, QA, development, product management, project management all together and collaborating from the beginning of a project or beginning of a sprint. And that, in effect, speeds up everything. So again, to echo Deepak's point, if you just make the life of the dev better or faster, you may not actually be solving for total velocity. Great point about why you guys are sticky, why your customers love you. Omri, I'm sure you've got a great viewpoint, but Deepak, feel free to chime in. The cloud providers themselves, I look at the platforms out there, I mean Docker is a platform provider, Amazon, Microsoft, Google, others out there, some of your previous employers build platforms and they're trying to simplify and add automation and do this thing. Why are you guys, is this a big opportunity for you guys? Where do you guys become relevant or even more relevant as time goes on with these platforms? You want to start Omri? Yeah. Absolutely. So the cloud is the big platform disruption of our time in our industry and you're either going to write it or get washed over by it. And the most important thing that brought me to a company like Puppet is just this huge opportunity as our customers are moving to cloud platforms with more and more of their workloads, the ability to manage a more heterogeneous set of things becomes even more imperative, right? The more complexity you have, the more you need tools to help you manage through that complexity. And so as we see our customers start managing nodes in the cloud, our job is to make that friction free for them. So make it as easy as possible to adopt Puppet in AWS or in Azure or in any of these cloud platforms. And on top of that, I would say, we are also moving our entire portfolio to the cloud, to become cloud native, to deliver in a way that, again, takes a lot of the burden off of our customers' hands because if you see the move to cloud, one of the most attractive pieces of it for enterprises is that they can give up some or perhaps most or even all of the operations burden to another vendor. And that's an incredible kind of efficiency gainer for these enterprises. They don't want to run software anymore. Now, the vast majority of our customers still run software, not just our software, a whole bunch of other software, but their aspiration long term is to be able to hand some of that or maybe most of that management burden to their vendors, and that's exactly the journey that we're also on. So that's why I'm super excited to be at a company that sees that opportunity, that vision, and the expansion of market that gives us. I agree 100%. I think the big change for people that build applications or manage applications, if they want to put them on the cloud is at the amusement park, they have the sign where you have to be this tall to ride. If you want to have your stuff work in the cloud, you have to be this automated to ride. You just have to because otherwise there's no point. I mean, what's the point of putting your stuff on EC2 and I can elastically bring up a zillion instances of something if I have to provision them by hand or if I have to reconfigure them by hand. It just becomes a really expensive, absurdly expensive way to run a traditional workload that isn't ready for something like the cloud. So that's why I'm really optimistic about kind of our role and our customers are really, we have a huge amount of coordination and involvement with them trying to get them that automated so that they can take advantage of a lot of this technology. I also think that just the idea of being able to, for a lot of our customers and users, moving stuff onto the cloud itself is that's challenging. I don't think it's as easy. I mean, I know there are plenty of people that have tools that do these kinds of things but I just don't find it that easy to simply say, yep, you can just forklift your thing and now it's a cloud app. There's more stuff you've got to do. And in my mind, I think step one, if you have an app and you have a workload and you want to move it to somewhere else, step one is you've got to model what that workload actually looks, how that works. You have to have an understanding of how that's supposed to behave. That way after you move it, ideally automation helps you move it. That's where stuff like us, that's where our software comes in. But at a minimum, if you've got an understanding of how it worked before, now after you've transplanted it, you can actually validate it works the way that you want it to work. So I think automation is non-negotiable. You have to have that. And if you're not using a platform that lets you do that, then I don't know, you're going to have a really hard time. And unless you're planning on having all of your infrastructure, 100% of your estate with a single vendor in the cloud, you're going to need a platform that works across everything that you've got from your mainframe, processing all your trillions of dollars of currency transactions or something like that all the way to the app you built a year ago that you thought was Ocarant. Maybe before you picked up a book on containers and the stuff that you're going to build tomorrow that's going to be cloud native. And you don't want 18 different tools from 18 different vendors managing stuff in 18 different ways. Because that's not really, I don't see that as a path to scaling out what you can do. Yeah, reminds me of another quote that Ben used in the keynote is you need to be past and future-proof. So we're going to have to leave it there at TPAC and Omri. Thank you so much for joining us. And thank you for watching theCUBE. Thanks. Thank you very much. In the queue.