>> Narrator: Live from the Computer History Museum in Mountain View, California. It's theCUBE, covering DevNet Create 2018, brought to you by Cisco. >> 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 Launch Darkly. 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 intricate testing with user groups or we sometimes use it, 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. >> So is it software as a service? Is it cloud-based? >> Yes >> It is 100 percent cloud-based. >> So, subscriptions, free? >> We charge by developer seat, and all we are saying is, go ahead and use it, we have the capacity to handle it. We're handling about 25 billion flags a day right now. >> So it's a great tool, so it's not like a big over the top feature cost. >> Oh, no. >> It's like nice lightweight usability, the more you use it, the better utility. >> Yeah, it's very light. It's a couple SDKs and then a code snippet about this long, depending on your language. The 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. 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, right? 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 on the original kind of DevOps ethos, really was kind of coming in late in the 2007 time frame, the real hardcore DevOps were building their own stuff. So we're 10 years into what I would call the true DevOps, maybe earlier. You could argue a little bit earlier when Amazon hit the table, but can you tell about the kinds 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 there? What are some of the key things? 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 have 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 is aware of what's going on all the time, and you can just have one through-line in your code and not have people spoiling off into branches that are unproductive. >> And how you do you manage that? So your tool manages that, or is it more of a philosophy discipline? >> No, 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 test it in production. 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 those 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 in open source, because if someone's got all this open source information going on, let's just say hypothetically, they got the trunk thing going on, but a lot of open source is driving this, so there's some discipline involved, there's some psychology, counseling, as you mentioned, so how do you pull it off? 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 were 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, 'cause 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, just the politics, whether it's politics or lobbying to get something in, a feature built, 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 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. >> And Heidi, the other thing I think is interesting with what you guys are doing is that, this whole event here at DevNet Create, and all the other events that are, I call cutting edge developer events, the vendors who sell stuff, like Cisco, whether they're big, and 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-creations 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. Well, not pure DevOps, I mean an environment that's going to be facilitating creativity, risk-taking, >> Yes. >> experimentation, building concepts, not, "Oh, I'm constrained, because this psychologically 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 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 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. >> Yeah, it's disruptive, too, to operations. You want to be just enough disruptive. Alright, I want to get your thoughts on something that I've been thinking about for a while, been talking about on theCUBE, and that is, I come from the old, when I was growing into the business, it was all waterfall-based software development, Agile comes along and it 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, you prayed. Now, with Agile, that got de-risked, so you, you're shipping code, you're iterating, but I'm arguing that the craftmanship has kind of gone out of it, because you're constantly programming, and so, that's kind of my opinion. Some people will debate that, but, now we're seeing a move towards, with the Agile Methodology, which I love, and a role of craftmanship, where cloud is kind of going to the next level, you're starting to see people think about crafting the product. So, as Agile goes to the next level, what's your opinion, view, of crafting process, now the user experience has gone beyond just look and feel and being good, mission-based applications, you're seeing new kinds of psychology of how people use things. So diversity becomes important, but the role of crafting and the methodology, is there a spot for that? How does that fit in? I mean, if you're constantly shipping code, push, push, push, are you crafting it? Is there, what do think, 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 we'll 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, "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. 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 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 have seen this in DC and outside of the US, where mission-driven enterprises 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 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 componentized feature. >> Yeah, a componentized feature, 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. It's a solved problem. Buy it and snap it together in a way that serves your customer. >> Jim Zemlin said this at the Open Source Summit in LA last year, he called it the open source sandwich, only 10% of the solutions are a unique IP, 90% of it is the bread that's from open source. So, to your point, this has already kind of going there, 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, it's happening now. Your thoughts on open source, you mentioned that you could be a crisis counselor (laughing), a therapist, or whatever, I mean, there's a lot going on that's now tier one, it's multi-generational now, it's not the old days, renegade second-tier citizen, 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 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 revealing everything that we're doing is an excellent value, even if we're not necessarily licensing it. You can go and look at all of Launch Darkly's APIs. We have them out there, but we're not an open source company, we're just-- >> Transparent. >> 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. >> Well, congratulations, it's great to have you on. Great conversation. >> Thank you! >> Love the futuristic view, riffing on some concepts we've been thinking about, also. Got a great service, making possible to operate at scale, get new features tested and fire those capabilities. Appreciate it. >> Alright! >> Thanks for coming on theCUBE. >> Thank you! >> Thanks! >> 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.