 Live from the Computer History Museum in the heart of Silicon Valley, it's theCUBE. Covering OpenStack Silicon Valley 2016. Brought to you by Morantis. Now, here are your hosts, John Furrier and Lisa Martin. Okay, welcome back everyone. We are here live in Silicon Valley for OpenStack SV for Silicon Valley. This is theCUBE SiliconANGLE Media's flagship program. We go out to the events and extract the signal from noise. I'm John Furrier, my co-host. Lisa Martin, our next guest is Luke Canines, who's the CEO of Puppet, formerly Puppet Labs. Yes. Now Puppet, welcome back to theCUBE. Good to see you. Thank you, John and Lisa. So, I love what you guys have been doing and following you guys, obviously Chef and Puppet, you guys, I'm not a competitor, but also you guys were early on. Back in the days when the Cloud or Roddy, whatever people want to call it back at the time, was a small handful of, I won't say radicals, but really guys who understood the Cloud. And at that time it was really much the same kind of conversations. How do you configure stuff, make it seamless? How do you get the app guys? And that was DevOps, the beginning of the DevOps movement. So congratulations for being there. Thank you. And having a great company. Thank you. Yeah, it's all about how do you, how do you make operations directly to deliver business value? Well, you've got to connect it to the applications teams, you've got to connect it to the business, and you've got to get people moving faster, being more effective. So it's been a long slog, been 11 years in, but it's great to see how much the industry and the landscape have changed, and how many, when I started, one of the reasons I started Puppet was it felt like no one was ever going to start a company in this space. You weren't seeing people like me, you weren't seeing operations people start companies, and now you look around the market and so many of the great companies, the interesting companies are started by operators, not just by applications people. So it's really changed a lot in 11 years. And it's interesting too, because Amazon just celebrated their 10th anniversary, 10th birth, Amazon Web Services, I mean not Amazon, Amazon Web Services. But at that time, people were just spinning up EC2 and S3 and really weird URLs, you had RightScale, and you had all this kind of stuff, just kind of building your own, but now we look today, Docker madness. Kubernetes has grown like a weed. So you're starting to see the application developers that dream of infrastructure as code play out. Absolutely. So how did you guys spin into that, because you guys have been riding that wave, where are you guys today? What's the update on Puppet? Things are going really well. So last year we had still more than 70% growth as a business. We as a company, we're now more than 460 people around the world. We've got offices in, I think, five countries. And so the company I think is doing really well. The technology is really interesting. We've been doing this long enough now that we really understand the problems we're trying to solve, the customers we're trying to solve them for, and how to take those solutions to market, because it's one thing to solve. Solving a problem for Uber is different than solving a problem for Bank of America. It's different from solving a problem for that same bank, but in a different country, right? If you're working with a bank in Germany or in Australia, again, there's a different set of problems you have to work with solving. How about the problem that you guys are solving today? Because the problems of, it's a moving train, right? It's bigger and more complex at a larger scale, you mentioned Uber, I can imagine. It's massive configuration, automation, orchestration, all those challenges, going back from where you guys came from. What are the problems now that you're solving? What's the core problem? At a very high level, we break it down into two categories. First is, we help our customers acquire situational awareness. What do we have? How is it working? What's going on? Who made what changes to what environments for what reason? So there's a lot of understanding that most people are just missing about their environments, especially going to large enterprise. We've got 10,000, 50,000 machines, 10,000 production applications. Getting just an understanding of what's happening is really valuable and we really help people do that. And then the second piece is, we want you to get control. We want you to not just see it, but really be able to control. I want to be able to, when I deploy, I want it to happen now and I want to know that it happened and I want to know it happened securely and I want to know it happened according to all the rules, but I don't want the fact that I'm following the rules to slow me down, right? So if I've got auditors, if I've got regulators that I'm worried about, if I've got security concerns, which we all do, how can I fit all that into my story but still move really quickly? And that's what we do at a high level. Now what that translates to is every organization has different sets of technology stacks and applications they built. So if I go into one organization and say we manage exactly this for you, that works great for them, but if I say that same stack that same solution to other company, it's not going to quite work. So if we look at the ways we solve problems for retail companies, for example, and retail companies essentially have a different data center in every retail office around the country, around the world. So they've got a very distributed, a very complex application. Flying hands organizations on the other hand tend to be very centralized in a couple of really big data centers. So we've always been really good at helping you manage whatever it is that you have with a common platform, a common language, a common tool chain. As we look at bringing in containers, as we look at bringing in Kubernetes, as we look at bringing in, if you're a large enterprise in the US today, you're now pushing heavily into the public cloud. You've been dabbling with it for a couple of years, but now you're saying, all right, it's time to really put production workloads into the public cloud. You're not going to get rid of all your own premise infrastructure. You've still got a thousand, 5,000 production applications. So what you want is a choice, a technology platform that says, I want to get control of that. I want to understand it. I want to invest in it. But I want those investments to also help me move into the cloud, and I want them to be still relevant in the cloud. And that's what we help people do. And what that translates to in the individual technology layer ends up not being that important for us, because no matter what you pick, we want to say yes, right? If you walk in and say, look, I'm all physical, it's all bare metal. I want to be super efficient, but really, really fast. We can help you do that. If you say, I want to own zero servers. I want to have average lifetime of my servers. I want to be measured in hours or minutes, not days. We can help you do that too. So flexibility is key for the customer. Flexibility and heterogeneity, right? So we want to manage everything. It's not just about, because no mature enterprise, none have one technology platform, none of them, right? And even if you start that way, then you go by another company and they made the exact opposite technology choices you do. But you can't say, oh, well, we'll just leave it alone, right? You've got to integrate it all. What we were saying yesterday, you know, automation is the holy grail. Automating is the goal, right? You want to automate stuff, but you can't automate what you don't understand. If you don't understand it, you want to automate bad things and bad things scale. Just as good things scale. So that really is interesting dynamic, right? You can't just jump to automation. And that's why the situational awareness aspect is such a critical part of the value we provide. And we hear customers say, you know, we kind of walk in and we say, oh, we're going to help you, we're going to help you automate. And they go, you know what, actually, just for the first six months, can I just get the agent on there and just let our reports so I can see what's going on? And we've been hearing from things, hearing things like somebody is saying, if I ask a question of that team today, it takes me six weeks to get an answer. But if I've got Puppet running on that machine, I can get an answer in five seconds. The exact same question. And just skipping past all the organizational dynamics. Skipping past. It's a building blocks to have that management piece built in fundamentally into the fabric. Yeah, absolutely. So first, I enjoyed your keynote this morning. Thank you. And secondly, I saw that on your website you've got. In fact, you talked about it this morning in the keynote, over 30,000 organizations running Puppet. Yeah. As well as you have over 20 dogs in your office. Is it that few? That sounds right. Oh, is it a few? Oh, that's- I think we had like 13 puppies there the other day. Wow, man. You're going to skew the numbers. Oh, we've got no work done. So talking about- It is. We make them bring the puppies in on lunch breaks because otherwise, the office shuts down. No one gets any work done. Oh, exactly. That would be me. So looking at the successes that you've had, you're a production first company. You just talked about really enabling customers, wanting to say yes. Enabling them to get that insight, enabling them to have control. I looked at New York Stock Exchange staples. Talk to us 65% of the Fortune 100 companies using Puppet. Share with us some of the successes that a Staples is having versus some of the smaller companies that you're working with. What's similar and how are you really helping them to become software driven? It's a great question. And the angle you're taking of targeting, you look at Staples and say, is Staples a software company? Is New York Stock Exchange a software company? Obviously you can look at it at multiple angles, but the challenge they're all seeing is, my success as a business, my customer's happiness, is really reliant on my ability to continually improve the software experience I deliver. The value of the software I provide to them. And Staples, you're not providing software, but your software is what gets the right part to the right place at the right time for the right price. So unfortunately, I can't go into a lot of detail about the individual companies, but with the large companies, retail is a great example. So retail and finance are our two largest segments. And retail, what we tend to be very good at is there are two related problems in retail. And one is we've got a large data center with a huge amount of really important data that we use to make decisions about what goes where and stocking, delivering, people, all those pieces. So what we help them do is, how do you, again, get control of this, understand what's happening, and then how do you improve, improve all of this as quickly as possible, but never sacrifice reliability, compliance, security, things like that. And security ends up being a really big area where we can help, where somebody finds out, we've got a new vulnerability, when Heartbleed came out a couple of years ago, we found a lot of our customers use Puppet because they could fix every vulnerability on their entire 10,000, 15,000 machines in literal minutes. And being able to respond across your entire organization, if you're a retail company, if you can close a zero day vulnerability in 30 minutes, it's massively, massively powerful. So that's an angle that retail companies tend to take and tend to be really important for them. And what's the cultural impact? How are you helping companies as an enabler to really evoke the kind of cultural shift that they need to in order to be able to deliver anytime, anywhere, any place? Culture is certainly a huge part of both the success of adopting Puppet in tools like Puppet, but it certainly is also part of the barrier because you're asking people to change, right? You're asking people to show up tomorrow to be a different person than they were today. And change is hard. It is, and a lot of that cultural change is connecting the role of operations and the role of infrastructure to the value the customer provides. And a lot of organizations, you can go to a network engineer, you can go to a system engineer and say, connect, help me understand how what you do helps your customers. And in some organizations, they're very clear, and in some organizations they'll say, I don't really see how that's related to, you know, that's not my job. So that cultural change, it's a big lift for some organizations, but the value you get once you take that step, and this is what my keynote talk through today is, here are a lot of reasons why people don't invest in DevOps and the cost of that cultural change, their perceived cost, relative to the perceived value, is one of those big barriers. But what we find so often is, once you can connect the teams together, once you can connect it directly to business value, that's where you start to see those deploying 200 times more frequently than your peers. You start to see 2,000 times faster from idea to production, right? Or from your customer's discovered or problem, or is experiencing some sort of pain in using your software to fixing it. So if you've got an operational improvement and you're in a large retail company, how quickly can you propagate that improvement across your whole platform, dramatically more quickly, once you get the alignment in place? And the value, both the value and the cost of that change are really directly related, I think, to the lessons we learned in lean manufacturing, where the companies that got really good at lean manufacturing were fundamentally different from traditional Sunday line manufacturing. But everyone switched to it today, right? It took some companies decades to do it, but everyone does it now because it's just that much better a means of operating. So you're really helping a lot of companies dispel the myths of DevOps and help them understand the realities and the opportunities for their business and the impact of their customers at the same time. Absolutely, and the DevOps report, which we've done them for the last five years, surveyed more than 25,000 people, has helped to show here's the value you get from adopting it, and then our one-to-one engagement when we work with customers, whether it's in the pre-sale side, we help them understand here's what you can get and here's what it'll take to succeed or once you've decided to work with us to really make sure you do succeed, a lot of that work is helping them see, okay, how do we drive that change and what's the value we're going to provide, deciding which direction do I take in the beginning? Do I go first to my production infrastructure? Do I go first to Greenfield? We really see a lot of people want to start with Greenfield strategic projects, but we actually recommend peanut butter a little bit across your entire platform. You get that situational awareness across your entire organization, and they realize that they don't have to start by automating everything. They can start with just a little bit, small experiments, small risks. You get returns quickly, you get experience, you get credibility, and then once you want us to take a big step and a big risk, it's easier to do that. It's easier to justify that, and we like it because- And that peanut butter increases the surface area of data from watching, from getting that monitoring. Exactly. So we'll get a comment on the Twitter here. I want to get your thoughts on it. It was tweeted that you said 97% to 98% is still legacy environments. DevOps can be relevant. Quoting you earlier as we use out there. I want to just go in the direction of kind of where we've come from, where we are, kind of where we're going. Test Dev has always been one of the biggest cloud use case. Oh, a low-hanging fruit, Test Dev. You know that world. But now production is really now on the table, moving very fast. So interesting conversation we had in our crowd chat with our team, with these testers. So there's a little bit of a religious thing going on with testers, with cloud native and cloud environment. The legacy environments, they have certain test things that they do, yet the agile philosophy of what we're living in cloud is interesting. So Test Dev is a dynamic. Can you share your thoughts on this? Because it seems to be kind of a, I won't say controversial, but certainly highly debated. What is the test methodologies? How should people be testing in a DevOps agile market? Yeah. Especially cloud native too, with mobile apps. To me, the most important thing about any test or development environments is can you honestly say a passing test in this environment is remotely relevant? Because in so many situations, we've seen development environments and test environment environments that are built and managed entirely differently from production. So the fact that it all passes green in test may be completely irrelevant to you, right? And then you go to deploy, you find it's Saturday night at 10 p.m., the deployment entirely failed and now you've got 24 hours to back out this complicated deployment. Your site's been down for a day, everyone's really upset, exactly. That doesn't work. So the first priority has to be, are my environments sufficiently similar that my promises are high quality, right? I think it will work in production. So, and if you have a development environment, if you have a test environment, you have to automate it because there's no other way to guarantee equality in the environments. And when you automate it, you have to automate using the same platforms, the same code, the same tools. When you promote your code, you have to promote your automation, right? So if you say, hey, I'm going to move the application itself from dev to prod, you need to move the automation that deploys that application from dev to prod. So you've got to have consistency platform. So, and to end deployment. You've got to have it. Test to dev. Right. I mean, to test, up dev to production. Exactly. Now, if you look about, if you look at answering the question, how does testing fit into an agile world? Again, going back to lean manufacturing, the way they talk about this is moving quality to the left, right? We all remember Chevrolet's from the 70s. The way Chevrolet tended to build cars, the way American companies tended to build cars a few decades ago, was you build as many cars as possible as quickly as possible. And at the end you go, are they high quality? Let's check. And the ones that weren't high quality, they would fix. They would go, okay, well, that door's not on right, that seat's not attached right. We'll go fix that and then we'll ship it. Lean manufacturing says, if you have a quality problem, you want to fix that and find it as early as possible. You want to move it to the left. And what that means is, A, you integrate your quality management and your execution at the same time, right? So you put quality in and development right next to each other. And B, so you don't go through separate stages, right? You don't separate the experience or the people. So lifecycle of development has total quality built in? It needs to, right? And this is the direction that everyone has to be going. Now, you can look up, you can look at an environment that does that really successfully and you could convince yourself, oh, they don't do tests or they don't do that kind of environment. That's not really what it turns out, right? The fact that you can't see a separate environment doesn't mean they aren't doing testing. It doesn't mean they aren't doing, they don't have a development environment. It means that that way of working is directly integrated in the flow from idea into production. And this is the other piece that we talk about a lot is it's not enough to say, we're really good at this or really good at that. You have to be able to understand, measure and optimize for the entire end-to-end software production lifecycle, right? From idea or bug or outage through to your customer generating value from the product, you have to optimize that entire thing. And how much of the challenge is, if you will, is cultural versus technology? In terms of testing and getting in that new workflow, that new work stream concept that you're mentioning, is it more cultural? Is it more people just got to get over the old school testing or is it? There is a lot of culture. Because you got to remember that everything that a company has today works. They didn't, nobody walks into organizations and says, let's do something stupid that will make everybody angry. What organizations have evolved is a system that works for them and their people and their customers. And then reality changes and you go, oh no, there's a better way. How quickly can you change your solutions to that better way, right? And when we talk about cultural change, it's almost unfair because what it sounds like is, culture sucks. Everyone realizes that this is the right answer and you just refuse to change. But what you're really saying is, you have to convince people that a better right answer is available. And that's the cultural change that you're talking about, is people have to give up the success they've experienced, the proof that they already have and go into an uncertain world that they haven't yet experienced. And that often gets confused as dogma. Exactly. And that's where the conflict kind of comes in. Interesting. Final word here. I want to get your thoughts on OpenStack. Obviously, key noting here. Your thoughts on the community, about the Thrive, certainly survived, really well, developer community here, has zigged and zagged as we said yesterday in a great way, but now it seems that the thriving part is right upon us with all the goodness with the other orchestration stuff. I'm really excited about what's going on in the infrastructure world. Again, when I started the company, there was a very boring world of infrastructure and management, and I think it's really interesting right now. And I think especially what appears to be a lot of really good crossover between OpenStack and Kubernetes and the other interesting platforms that are showing up, the teams are beginning to see how they don't have to be competitive, they can learn from each other, they can get value from each other. And it's clear that OpenStack solves a problem that was really, really important for our enterprise workloads, but it's also clear that there's more to do beyond that, right? You can't walk in and say, this is the answer. I really believe that we're part of a decades long software evolution. We're not a decade away and then you're going to look up in 2020 and like, eh, we're kind of done. I think in 2025, things will be changing just as fast. You know, there's, I think it kind of like a Moore's law of software where there's, it's not- It's not like your company journey. Yeah, it's just moving so fast. People say, oh, it's accelerating. I don't think it's accelerating. It just doubles every year or two. You know, it's a flat curve, but compound change is so compelling and the human mind can't get around exponential change like that. And you put together the amount of complexity that Kubernetes and OpenStack and all the other tool chains today can help you manage the kinds of applications you can build right now that you couldn't conceive of without 500 engineers, without building an entire tool chain around it. It's really impressive. It's really compelling and I'm really excited to see how much it's been moving. It's going to continue to be a boom and really appreciate you spending the time with us on theCUBE. Appreciate it, Luke. Thanks for having me. Yeah, thank you for having me. Share here. Formerly Puppet Labs out of Portland. Great startup. 11 years old, doing a lot of great stuff here in the OpenStack community and beyond. This is theCUBE live from Silicon Valley right back with more coverage after this short break.