 Live from the Julia Morgan Ballroom in San Francisco, extracting the signal from the noise, it's theCUBE, covering Structure 2015. Now your host, George Gilbert. This is George Gilbert, we're back, we're at the Julia Morgan Ballroom in downtown San Francisco. Structure 2015, we have with us Luke Kines, who's CEO of Puppet, for those of you who I guess have been hiding out for a couple years. Puppet is a configuration management software company and one with big ambitions. Absolutely. So I had just been asking off camera, Luke, about something that's near and dear to our hearts. And that is when we have ever more sophisticated applications where we're building on systems of record and we're building analytic applications on top of those so we have incredibly complicated configurations, the applications themselves are sort of constantly evolving. How do you help hold that together? Well, a critical part of what we do is to make sure that the way that you want the systems to be configured is how they're actually configured. I often, to the layman, I describe Puppet as you bought these servers for a reason and we're here to make them do what you told them to do. And at small scale, keeping your systems configured appropriately is relatively straightforward. But when you're talking thousands or tens of thousands of servers, it's quite complicated to make sure that it's all working. And it's not just about the servers, it's about the storage, it's about the network devices and now you've got platforms like Amazon and Salesforce that are a critical part of the work that you do and they have to all be configured correctly too. So it's getting it working in the first place, it's rolling out changes to those things and then it's coming back tomorrow and saying, is it still configured correctly? So that's exactly what we do for our customers. Okay, and so from an admin point of view, how do you make their job specifically easier? I mean, I can imagine there's code that has to be written, there's blueprints that have to be compared to, how does that work? Yeah, the admin's job is pretty complicated. Studies show that on average, an assistant administrator has interrupted every 20 minutes and different studies show that usually when you've been interrupted it takes about 30 minutes to recover from being interrupted. So one of the big things we do is we help admins especially but people in general really spend less time of firefighting and doing menial repetitive work and more time shipping rates offered to their customers. And some of that is about having automation in place so that when I do a thing once, it can be done by the system on the rest of the world. Some of that's about lower error rate. So humans are really, really good at decision making, they're really good at fast decision making. They're really bad at doing the exact same thing a thousand times. Computers are often not that great at decision making but they're very good at doing really boring tasks without getting bored. So really building tools to the assist admin to say, look, go do that over there and I'm going to do the interesting work over here. And that allows the operations teams to be more focused on the strategic needs of the business and allows the software to really take the repetitive menial stuff and not just do that so that the people don't have to do it but do it more consistently, more reliably and a lot, lot faster. So one thing I hear about is configuration drift. What causes that? And then how do you fix that without breaking what's running? Configuration drift is caused by a lot of things. Sometimes it's just rot. Something changes and you don't really know why. Is that as in bit rot? As in bit rot, right? And it might literally be bit rot. You might have a corrupted file in some ways. Things change because people change them. Usually it's a thing that a person did. A person goes in and says, something's broken. Let me make a change and see if it fixes it. Oh, it didn't fix it. I'm going to go try the next thing. Then they were changed that configuration back again. Then you reboot the server for whatever reason you find out tomorrow. Oh wow, this is actually a serious problem. So part of what we do is the way you told it to be configured a week ago, let's make sure it's still configured that way. And again, in a small scale, this isn't that complicated. At the scale of hundreds, thousands of machines, when I was talking to somebody today, they've got 4,000 applications. They've got 40,000 developers spread across tens of thousands of machines. How do you make sure that in every situation you've got everything configured correctly without slowing you down, right? Without using spreadsheets and manual check-offs because when you do that, you look up and you can't get anything done. But take that as an example. It would sound like to make sure configurations are correct before an operation executes, you want to validate the configuration and the scope of that configuration, I don't know how big it is, but that would seem to have a lot of overhead introduced. In general, people don't think about it as a prerequisite to performing operations per se. They think about it as, there's kind of two or three usual processes. So one is go configure it correctly in the first place. So this is a deployment or a provisioning process, a delivery process even. And this process is really not one time, you won't do it every second. You'll do it maybe a couple times a day, 10 times a day, but more likely less frequently than that. Then you've got a validation process. And for our tool people run the validation process about twice an hour. And the service will be running all the time. If the validation process finds those are problem, then it'll go correct that and do anything it needs to do to make that work. So usually you wouldn't say, before I run this database job, let's go validate everything. But certainly that's an opportunity, if that's something that's critical for your business, it's certainly something you can do. So let's look a couple of years out. What would you like your product line, or what are you planning your product line to look like? How, and how will it change the role of the systems administrator? So much of the role today is defined by the tension between the really interesting new technology that's coming down the pipe, and that everyone wants it to take advantage of. And the reality of brownfield infrastructure, that's, I mean, there's another, what everyone else calls legacy, our customers call production. And you can't just ignore if it works. Right, exactly, the stuff that makes me money today. And to come to them and say, hey, I know, let's do all this new stuff over here, and just ignore that, right? You can't do that. So we're really good at providing that intersection, providing the tools that work in the new world and work fantastically in that new world, but also really work well in the old world. So whether you're talking physical, virtual, public, private, you're talking containers, virtual machines, physical, we can do all of that. And we can scale from the compute, although network storage, et cetera. So what I really see is, right now, 15% of the market uses any kind of automation. The challenge in front of us is, how do we build an application that makes it so 50% of the world can be automated? And the automation is, it's about reducing friction. It's about allowing people to move faster. It's about increasing reliability. And it's especially about having a better view on what you actually have and whether it's configured correctly. Because one of the things most people don't know today, right, you kind of go, well how many servers do you have and are they configured correctly? People go, you know, I have a rough idea. So it's not just doing the work. It's knowing whether you've done the work. And the tools we have, we have great technology. We've got, we've got, you know, 400 employees. We've got 30,000 companies using our product. We've got 1,000 paying customers. We've got about 100 customers who are above six figure size customers. So we've done very well as a business, but we're just this little teeny part of the world. And we've got to find a way to build up that new reality. So as you're talking about this, it occurs to me that when people talk about hybrid clouds, besides the sort of virtualization or container technology, the bigger issue is the processes to keep them in, you know, in sync or to achieve the operational efficiencies in private cloud. Can you span those two environments and help? Absolutely. And not only that, in a lot of cases, our customers don't tend to talk too much about hybrid clouds because it's not, it's not that different. We've had customers who've taken more than 50,000 servers, move them from the public cloud to private and back to public again. Because once you've got great automation in place, once you've got the right abstractions in place, and once it's not a question of manual work and, you know, literal effort, but it's a question of business decisions translated directly into technology that it all becomes pretty straightforward. So in other words, hybrid cloud doesn't mean the Amazon virtual private cloud, you know, virtual, whatever, private network. It means having a configuration management policy in place that works across the two sort of infrastructures. That's been the case for us, right? And especially, we're obviously in a period of transition. So knowing what the world's going to look like in three years or five years, I'm not a person who's fond of predictions, but in terms of understanding how do people use it today? And in a lot of cases, they have certain workloads that make a lot of sense in a more static environment and certain workloads that are really dynamic and are really built around bursting and changing and lots of turnover. And to say, well, we should have one technology for one and another technology for the other one, it doesn't make sense. What you want is unified school skill sets, unified code bases so that I can say, you know, look, solving a problem in this world, but also solve it in that world. And because Puppet works well in both of those worlds, it ends up being a great solution to solve one problem one time across all of your environments and get the benefit of scale and the benefit of the organizational scale. So yeah, it is one tool, one platform, one language across all of your environments. Okay. Luke, we're going to leave it at that. Thanks for joining us. George Gilbert, we're at 2015 structure, Julia Morgan ballroom downtown and we'll be back in a minute. Thanks. Thank you very much.