 from the Computer History Museum in Mountain View, California. It's theCUBE, covering DevNet Create 2018. Brought to you by Cisco. Hey, welcome back everyone, live here in Silicon Valley in Mountain View, California, it's theCUBE, coverage of DevNet Create. This is Cisco's cloud developer DevOps, cloud native developer environment. This is different from DevNet, that's their Cisco developer conference, so we're here covering it. This is where all the action in Kubernetes, DevOps and a lot more. I'm John Furrier with my co-host, Lauren Cooney. Our next guest is Heidi Waterhouse, developer advocate for LaunchDarkly. Welcome to theCUBE. Hi, thank you, I'm glad to be here. Thanks for coming on. So first of all, take a minute to talk about what you guys do as a company. Then we'll talk about some specific DevOps questions that we have for you. Excellent, so what we do as a company is, I summarize it as feature flags as a service. We are giving people a control surface to be able to deploy their code safely in the daytime so nobody has to stay up on a deploy bridge and then control who sees it very precisely and roll out individually or do work to do like intricate testing with user groups or we sometimes use it like imagine if sales could turn on a feature, a test feature for one client without needing to go to development and get approval for all of that. So it gives us the ability to let people be richer in their expression of software. Is it software as a service? Is it cloud-based? It is 100% cloud-based. We charge by developer seat and all we are saying is like go ahead and use it. We have the capacity to handle it. We're handling about 25 billion flags a day right now. Yeah, so it's a great tool. So it's not like a big over the top feature cost. It's like a nice lightweight usability. The more you use it, the better utility. Yeah, it's very light. It's like a couple SDKs and then a code snippet about this long, depending on your language. Java one's a little longer. And what it gives people is the ability to do feature flags which lots of people are already doing in a manageable way with a structured API so that people can keep track of what's happening and make sure that they are only allowing the right people to turn flags on because you don't want everybody to be able to hit the kill switch. Like you want a kill switch on the feature if it starts spitting out garbage but you don't want it to be universally accessible. I think you also want it to be consistent in that environment and those environments where the developers are trying to understand what that looks like. Right, and auditable. We give you the ability to see every change that's happened to a flag and who made it. So DevOps is going on almost a 10 year run now. If you look back at the original kind of DevOps ethos, it really was kind of coming in late in the 2007 timeframe, real hardcore DevOps were building their own stuff. So we're 10 years into what I would call the true DevOps. Maybe early, you could argue a little bit earlier when Amazon hit the table, but you're talking about the kind of things that you guys are doing is really large DevOps environments where you want agility, you want real time, push code all the time, but be reliable. This is more of a mature looking dev team. How has that evolved and what are some of the key things is this is kind of probably an indicator of where everything else is going. What are some of the developer concerns? Is it A, B testing? That's kind of a trivial example but I often imagine all kinds of new software methodologies are coming out of this. What are you seeing? So what we're seeing is for 20 years we've been teaching and preaching branch based development. But it turns out the very largest software organizations like Google are doing trunk based development because branches are just a way to cry. Once you try and merge something back in you find out that you have conflicts and then you have to have more discussions about who gets cherry picked and it's catastrophic. I've said for a long time that maybe my second career is just going to be a trauma therapist specializing in GitHub. And I think I can make money at that. So we have this inherent belief that branches are just how we code. And what we've been seeing is people are pulling back more and more into trunk based development so that everybody's aware of what's going on all the time and you can just have one through line in your code and not have people squirreling off into branches that are unproductive. And how do you manage that? So your tool manages that or is it more of a philosophy? It is a side effect of our tool because the reason we have branches is because we don't want to show people our work in process. But if you can hide it behind a feature flag and only deploy it, only activate it when you're ready it gives you a good chance to like test it in production. Like there's nothing that says you can't build your feature, test it in production at full scale with all your microservices distributed, all of the data flow, everything. But you're the only one who sees it. And being able to target that is really important. It's going to give you a lot of capacity to test things. Yeah, and we've seen that too all the time where people are saying, hey, you know what? I want to test it before I invest in it. That's a big thing. Yeah, it is. And internally being able to test things is going to give you a lot of capacity. So we find that it is not our, we're not enforcing anything on anyone. That's not our role or our goal. What we're trying to do is offer people a tool that helps facilitate the best of what they're doing. Yeah, and when you look at developer tools, I think that's absolutely critical in bringing that to the table for different environments and things along those lines. And one of the things I was going to ask you is when you look at the developer environment, is the developer environments in your mind in a spot where people can do this? In other words, will they be able to pull it off and open source? Because if someone's got all this open source information going on, let's just say hypothetically that you have the trunk thing going on, but you've got a lot of open sources driving this. So there's some discipline involved. There's some psychology counseling, as you mentioned. So how do you pull it off? And what's the best use case? You have to make it advantageous. You have to make it work for them because people aren't going to do things that don't work for them. I teach a workshop, I was doing a workshop here about documentation and people are like, how do you get developers to document? I'm like, well, have you ever fired a developer for not documenting something? Have you ever given them a raise for documenting something? If you haven't, you don't actually care about them doing documentation. In the same way, moving culture means that we have to incentivize doing the right thing. We have to make the barrier to entry low and we have to make it possible for people to just do the right thing more easily than the wrong thing. The other thing that I was thinking about too is this is just kind of my personal opinion. Because the things you mentioned are really important and that is that doing testing at scale is a big deal because if you think about all the wasted time that goes into like just putting just the politics, whether it's politics or lobbying to get something in a feature bill. I mean, you're talking about months, weeks. I mean, it's a nightmare. So imagine a capability to say, and this is the promise of DevOps. This is ultimately why this is so awesome. So this is like move fast and don't break things very much. And I like to think of every plane you get on is a little bit broken. It has an error budget and if it exceeds the error budget in any direction, even if it's like an overhead latch bin, they ground the plane. But our organizations also need to be that resilient. We need to have that flexibility. And I think the way we can do that is by being able to instrument our features and turn them off if they're causing problems or turn them down if we're getting flooded or whatever it is we need to do, we can need to do it at a finer grain than we've currently been doing. I don't ever want to have blackouts, like maybe a brownout. You know, Heidi, the other thing that I think is interesting what you guys are doing is that this whole event here at DevNet Korea and all the other events that are, I call cutting edge developer events, the vendors who sell stuff, like Sicily, whether they're big or new vendors, the old model of preaching and jamming solutions down your throat is not the way it works anymore. All the enablements has to be there, but the co-creation's happening really from the people who are building their own stuff. So that's kind of going to have to be a dynamic, creative environment. So you need to have a really pure DevOps environment. Yeah. What not pure DevOps? I mean, an environment that's going to be facilitating creativity, risk-taking, experimentation, building concepts, not, oh, I'm constrained because this circulation doesn't support. Yeah. It's hard to do advanced thinking when you are not psychologically safe, but I do think that you don't have to be like operating in the purest of DevOps in order to be taking in some of these tools and techniques and using them effectively. I think there are a lot of people who have, for instance, taken up blameless post-mortems, even if they're not doing anything else in the DevOps sphere. They're like, oh wait, we could talk about root causes that weren't like people screwed up. And I want us to say, like whatever you can do, that's going to improve your environment. I don't want people to feel like they have to absolutely transform everything because that's too big an ask. Yes. It's disruptive too. To operations. Do you want to be just enough disruptive? All right, I want to get your thoughts on something that I've been thinking about for a while, but talking about in the queue. And that is, I come from the old ball. When I was growing into the business, it was all waterfall-based. Software development. Agile comes along and de-risks everything. Because the old days was you created a product, you crafted it, you shipped it, and you don't know if it was going to work or not, right? And you did QA, all that, and you prayed. Now with Agile, that's got de-risks. So now when you're shipping code, you're iterating, but I'm arguing that the craftsmanship has kind of gone out of it because you're constantly programming. And so that's kind of my opinion. Simple debate that. But now we're seeing a move towards with the Agile methodology, which I love, and a role of craftsmanship, where cloud is kind of going to the next level. You start to see people think about crafting the products. So as Agile goes to the next level, what's your opinion, view of crafting processes? Now the user experience has gone beyond just looking to feel and being good. Mission-based application, just seeing new kinds of psychology of how people use things. So diversity becomes important. The role of crafting in the methodology. Is there a spot for that? How does that fit in? If you're constantly shipping code, push, push, push. Are you crafting it? Is there an art? Where's the artistry of it? Where is the artistry? Well, artistry isn't replicable. So this is sort of a problem because what we really want is consistency. So I think eventually it will become sort of like novelty ice cube molds. There's somebody who carves the original novelty ice cube mold and then we all use it to make novelty ice cubes that fill our heart with delight. There is an artistry, but we're going to have to pay people to do it and currently we're only paying them to cool our drinks. And until we really make some time to say like it is saving me time, it is saving me money to have a well-crafted product, we're not going to change. And I think that's an interesting thing about serverless and function as a service is it really pays to have a super well-constructed system. Like those microseconds do count there in a way that they haven't in the age of eternal storage and basically all the bandwidth we can consume. And I'd like to see that applied backward toward people who have very low bandwidth. I would love it if like one day a month, everybody dialed down their corporate internet to the speed that rural America is getting and see how they feel about their apps then. Because there's a lot of people out there who do not have our big fat pipes. And also outside of the United States too. Again, I'm not saying that there's not good software. I'm just kind of seeing a trend where certainly I've seen this in DC and outside of the US where mission-driven enterprises are have completely different criteria for the product. And so I'm just trying to, I'm seeing some early signals around that the software methodology might not shift, but it just feels like it's some action there. And I always kind of keep an eye on that. So the thing that I think is going to happen, and this is my like weird futurist hat, is I think we are going to have more and more modular snap-together assemblies and the product manager is going to rise from the ash heap and be the person who says, look, these are all the things that we need to assemble. Please go find the parts so that we can build this that we want in a way that we haven't prioritized in a realm where we're like, well developers tell me how to do this. So componentize future. Componentize future, I see us really moving strongly toward that, I think that's a lot of what we're doing with serverless and software as a service is like, why build it yourself if somebody has already done it? Like please don't roll your own. Don't roll your own authentication. Don't roll your own LDAP. Like it's a solved problem. Buy it and snap it together in the way that serves your customer. Well, Jim Zemlin said this at the open source summit in LA last year, he said, you call it the open source sandwich. Only 10% of the solutions are unique IP. 90% of it is the bread that's from open source. So you don't, to your point, this is already kind of going there. So the exponential growth in open source is becoming significant. So with that in mind, that's going to play a part in that futuristic view that's happening now. Your thoughts on open source, you mentioned that you could be a crisis counselor, a therapist or whatever. I mean, there's a lot going on. It's now tier one, it's multi-generational now. It's not the old days renegade second tier citizen. It's open source is powering the world. Your thoughts on the current state of open source. I think open source is a fascinating example of doing what we need and how it helps other people. And so almost all open source projects even now start with personal pain and then we expand them to other people. And I would like us to remember that the reason it's open is because we care about other people's pain. And it's really easy as we like corporatize open source to forget that that's where we came from. And it's community driven and it's done in the open. Yeah, exactly. And like revealing everything that we're doing is an excellent value even if we're not necessarily licensing it. Like you can go and look at all of LaunchDarkly's APIs, we have them out there, but we're not an open source company. We're just like, those are values that we have that we want to be able, we want people to trust us so we're going to show them. Yeah. Well, congratulations. It's great to have you on a great conversation. Love the future of you riffing on some concepts we've been thinking about also got a great service and making possible to operate at scale, get new features tested and buy those capabilities. Appreciate it. Thanks for coming on theCUBE. Thank you. We're here at DevNet, Create, Cisco's Cloud DevOps developer, get together. I'm John Furrier, we'll be back with more coverage after this short break.