>> Narrator: Live from Austin, Texas, it's theCUBE, covering DockerCon 2017, brought to you by Docker and support from it's 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, 5500 people and many of them, a good majority of them made it to keynote this morning, but we're checking in with a lot of guests here, happy to welcome onto 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 Giridharagopal, who's the CTO and Omari Gazitt, who's the Chief Product Officer. We caught up with you at a previous cloud role that you had had. Deepak, since it's your first time on the program, you've been with Puppet for awhile now, can you give our audience a little bit about your background and your role? >> Sure, so, I've, software guy, I've been programming forever, done a bunch of different start-ups, actually lived in Austin and was part of the Austin start-up scene for quite some time, so I went to school here. So, I've been here for maybe 15 years, something like that. >> Is that a Hook'em Horns or is that a? >> It's Hook'em Horns, yeah, absolutely. So, UT computer science and also, fellow Texan, not UT but from Rice so, there you go. >> That's right. >> Owl's are okay too. But yeah, I've been working here for awhile, previous start-up 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 charged 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 the project 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, maintained a lot of relationships with the community, have a lot of patches inside of Puppet core, so eventually joined the company. So now I've been there for about six years, I'm CTO and Chief Architect, so I'm responsible for all the ones and zeros, I guess and overall technical strategy. >> Alright, 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 at the cross-town rival, maybe the different city rival at Rice but, I don't think we've ever beat UT in football, maybe once. So, I don't even know what the Rice equivalent of Hook'em Horns is. I spent many years at bit 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 Helium platform. For that I did a number of start-ups, including one here in Texas, in Houston that ended up going public and the fun thing about coming back to Texas. The last time I was here was Open Stack Summit in Austin. It's always going to get great Tex Mex, so really enjoyed that last night as well. >> Alright, so Deepak, you've been with Puppet long enough that you know, there was no Docker in there. >> That's true. >> Containers did exist, can you walk us through, you have an architect role, how does containers impact 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, I don't think there's a single customer or really user that I go and talk to and I talk to a lot of them that are unaware of containerization. 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 that we kind of play because the products that we build and all the projects that we have, the open source or commercial stuff, 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, 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, you know, 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, and 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, you know, kind of leading edge and a lot of the stuff that we've seen here in the keynotes today, which have 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 leading 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 you know, 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, 'cause 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. >> Actually 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, you help customers take what they have, move them forward, help make it easier. 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've worked most of my career really serving the developer customer, the developer constinuency, and one of the things that I saw working in the container ecostystem 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, right, and that resonated strongly with me because we saw, we saw that exactly in 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 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 estate of things? That doesn't change just because you go from running things on bare metal to running things in VM's, with containers, we 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 accelerate technologies like Docker, like containerization, and the container platforms, but do it in a way that, make sure that these operators continue to be able to their jobs, to get the visibility and the control they need to make sure that they deliver on the Dev of the business as well. >> Yeah, I had an interesting conversation with Soloman Hikes earlier on theCUBE here and he said his background was actually on the operations side and when they built Docker it was the developers as their customer, want to throw it out to the both of you, is to kind of that, 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 of two really high level buyers that make all these decisions about 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 '90's was a political party or the 2000's was a political party, it 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 QA in at the very end, ideally you want all of that baked in as early as possible and I think stuff like containers, I think the rise of containerization has enabled developers to feel more empowered over a large swath of the staff then 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 could 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 very empowering, that's a lot of responsibility. I think the flip side though and I think something that we learned as part of the DevOps movement as well is that it can just be about developer empowerment. It has to also be about operation empowerment. It has to be about security empowerment. If you think about it, I think there's a future, I hope this isn't the one that we actually get, but I think there's a future where, for example, all developers are building everything with containers are 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 that 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 pager 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 containers uses 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, it's developers and Op 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. I'm very optimistic about that. That's a place I want to be in. >> I, just to amplify a little bit, it's great to be at a company where the users love the software. Our selling motion typically is a bunch of practitioners at 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 dev's 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 steam, how 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 altogether and collaborating from the beginning of a project or beginning of a sprint and that, in effect, speeds up everything. 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 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? >> Absolutely, so, the cloud is the big platform disruption of our time, in our industry and you're either going to ride 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 those 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 of 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 customer's 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 of 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 and 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 it's super exciting 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 like 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 way I'm really optimistic about 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, that's challenging. I don't think it's as easy. 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 if you have a workload and you want to move it to somewhere else, step one is you 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 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, it's 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 over 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 oh current, 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 for 18 different vendors managing stuff in 18 different ways 'cause that's not really, I don't see that as a path to scaling out what you can do. >> Yeah, it reminds me of another quote that Ben used in a keynote is you need to be past and future proof, so yeah, we're going to have to leave it there, Deepak and Omri, thank you so much for joining us and thank you for watching theCUBE. >> Omri: Thanks. >> Deepak: Thank you very much. (upbeat electronic music)