 Live from San Francisco, it's theCUBE. Covering Google Cloud Next 2018. Brought to you by Google Cloud and its ecosystem partners. Welcome back everyone. This is theCUBE's live coverage in San Francisco of Google Cloud's big conference, Google Next 2018. Hashtag Google Next 18. I'm John Furrier with Jeff Frick bringing live coverage. Melody McFessel, Vice President of Cloud Engineering at Google, she's here in theCUBE. She leads a lot of the managing 40,000 plus engineers and making them happy and creating great code and friendly environment, doing great work. Just featured her and her story we did about the power women in Google Cloud. Melody, great to see you. Thanks for coming on. Thank you so much for having me. It's great to be here. Today is about developer announcements. We saw a lot of community discussions, new code, you guys talk cloud build. What are some of the news that you guys are announcing? Let's get that out of the way. What's been announced? What's going on here at Google Cloud Next? Great, very excited to announce and demo today. And it was a live demo. I don't know if you saw that. So we had some dramatic excitement, waiting for the actual build. Yeah, we're very excited to announce cloud build, which is a fully managed continuous integration and delivery platform. It lets developers build and test their applications in the cloud at any scale. And it's based on a lot of the lessons learned that we had within Google, iterating over the last two decades with developer and operator tools. Google does some crazy scale internally, and we're really excited to bring that automation and scale out to our customers. We had a chance to meet a couple of weeks ago. We went deep dive on developers. You have a job focused at really to kind of keep the developers productive, happy. And there's a lot of them at Google and they're a tough customer. They want to be coding. They don't want any distractions. They don't want any toil. We've been using a lot and hearing a lot here. And so there's techniques that you guys have done within Google. And this seems to be the theme of Google Next. Taking the best of Google and trying to make it consumable for customers, in this case developers. What is the state of the art to keeping developers happy, making them productive, more cohesive in their work? What are some of the things that you guys are doing? I know there's a lot going on. Google Cloud Build is one. What are some of the things that you guys do to keep developers productive and happy? Yeah, that's a really good question. What we found is that there's a tremendous amount of value of automating away. You've said toil, the things that developers want to do. So some of the research, industry research that we've done, developers want to write code, they want to do design, they want to work on requirements. They don't want to take care of the plumbing and the pipeline of how their build test and release happens. So we showed some pretty amazing features today around automated canary analysis. So it's almost in a way, we want these tools and the automation to have the developer and the operators backs. Because we know, we've learned at Google, that when we do that, they take more risks. And they move quickly because they know that the DevOps tools are going to catch the breakages for them. And I showed a couple of things today around running tests to identify if there are vulnerability scans, trying to find vulnerability scans before they get pushed out to production. We're trying to move as much as we can in the front part of the pipeline. So what makes developers happy? Well, one thing is give them the automation so that they can focus on code. The second thing is the culture to support and empower them. We found that 65% of developers believe they have the ability to choose their own tools. So GCP, we want to make that easier for them. Not forced them to do it. Well, you mentioned something earlier, I want to get, what's a canary? Explain what that is. Because a lot of people know what it is, but some people might not know this canary concept. So essentially what you're trying to do is take the release that you've built and test, make sure it's secure. Now you want to start routing traffic to it. So you take that, you release it to a small set of production instances, you start routing traffic to it, you look at error rates, you look at traces, you sort of see what's going on. If it's good, then you slowly deploy it out to all your production instances. So it's a really safe way. It reduces your risk, right? You want to catch the errors before they get out. Yeah, there you go. No, it's going to break. So it's a great agile way to push code and test, or not push code, push users to code. That's right. And get a feel for it with a break. Yes, yes. And the breaks you pull back. Yes, and we want to find things ahead of time. I know you were talking to Dave Resin. You know, the alignment of having shared goals between developers and operators is really important culturally because when you're incented toward minimizing the, we call it the MTTR, right? The minimum time to respond, right? So when you do things like canary analysis, you're finding the issues before they roll out and impact your user community. It's super valuable. I mean, but it sounds so easy. Why don't we just roll it out to like our top users or the ones who won't leave the platform and then pull it back? I mean, this is a DevOps principle. It is. If done right, works great. Yes. It's hard to do. How hard is it to do it if you didn't have all these tools? I mean, think about, you got to push code, pull the servers back, repush the new code. Yeah, you don't want to do that. Explain how hard it is. Human error. You know automation without these tools, how hard is it? It's very difficult and time consuming and we know as humans, we're prone to error, right? So it was really fun to show a live demo today of a Spinnaker pipeline, showing the canary, pushing it out to production and then going back to the website and seeing the impact of the code fixes that we put in place. Well, I just saw on the culture side, because you've been at Google for a while. Yeah. And you know, we still think of Google. I feel as a new, you know, the kind of a supersized startup that you guys have been at for a while. You've been there 13 years on LinkedIn. The company's 20 years old. How do you maintain kind of that cool, the colored bikes, the grade food, you know, go play volleyball outside in the middle of the day? Kind of culture as the company just grows and you have so many new people. How do you maintain that baseline culture that's been there and made Google what it is today? You know, we have a very strong culture within Google, a very strong engineering community and that engineering community really comes from and I think this has been consistent for the almost 14 years I've been there, using data to guide our decisions, right? Now, you know, we've also put things in place to help enable the trust between the humans, which when I talk to customers, this is a challenge. Throw it over the wall to the operators, the operate, you know, they don't trust each other. We've had blameless postmortems within the engineering culture for decades. We've abstracted away, you know, it's about learning, it's about continuous improvement. We're a software company and everyone's a software company now. How do you accept and learn from failure? But when you create this shared goals, use the data, not someone's opinion or someone's title and then ground and like, we're learning, we're always learning, we're always making it better. People, that inspires people, right? To have that impact together. Now, the culture, the benefits, you know, I'm working on writing code, building products. I don't know the last time I played volleyball, but it's awesome to see it. It's a beautiful course, though. Yeah, and it certainly looks good when you come in the building. You're the second, Dave also mentioned this blameless postmortem. I'd love to dig a little bit more because obviously that must be an institutionalized thing that you guys do. How do you do it without hurting feelings? Because it's still people and even if it's data-based, you know, you still kind of risk of hurting people. To have you institutionalized, it's the data. It's not you and we're actually trying to use this to learn and grow, not necessarily, you know, get on that particular person or that team for something that didn't work. Well, you know, I love this quote, it comes from SRE. If your SLO target is perfection, it's the wrong target, right? So we know in software development and systems that things break and as humans, we're writing the code. We are writing the services. So we're going to make mistakes. And I think that tolerance and that understanding, I mean, we have some structure, right? We track to-dos that came out of the outage. We make sure that they get closed. We don't have the outage again. But when you obstruct that away and know that, you know, maybe I made the mistake this week and maybe someone else on my team is going to make the mistake next week, but how we learn from it and how we come together as a team is what's important. Blameless postmortems is a great concept. Most people think postmortem, something bad happened. Someone needs to be charged with a crime. Oh my God, bad things. You're learning, blameless postmortems, it's just an iteration of learning. Continuous improvement. So this is a culture that now, let's take that to open source because one of the things that's happening here, that's, I mean, front and center, I mean, it's just natural for you guys, but the importance of open source. Software development's getting more power. You mentioned the stats and some of the psychographics. They can choose any tool that they want. That's the challenge for companies. Retaining them, keeping them employed, because they can get a job anywhere. They get more power. Open source seems to be this balance in the force, if you will. You know, it's kind of like open source is now operationalized for, that's where recruiting happens. That's where social activity happens. Conferences. How important is open source and how are you guys organizing around it as you build the cloud out? What's the vision? I have been so inspired by Google's increased contributions and collaboration in open source. I think we had over, I hope I get these stats right, we were contributing over 30,000 repos last year. 1% of the total contributions in 2017 on GitHub came from Googlers. We're committed to it and we really believe that Google Cloud Platform is living the open cloud and we do that through open APIs. We do that through collaboration around open source tooling and by creating this abundance and community and ecosystem around it. And if you think about, throughout another stat, 70% of developers feel a connection with each other. That's how they get inspired. That's how they learn. You think about Stack Overflow. You think about GitHub. You think about contributing to a product that you're going to make better. It's incredibly inspiring. Co-creation creates a bond. Yeah, it does. It's a connection. So if you look in the DevOps space, we've made some commitments with Bazel, which is Google's open source. We've open sourced our build system. If you look at the contributions in the Go community in terms of Go working really well on cloud. And then I showed Spinnaker, which is actually a project that Netflix started with their workloads. And we staffed up an engineering team to contribute to that, to make it work for multi-cloud, right? It's the right thing to do for developers to have these tools that they can use in different, you know, irrespective of where they're deploying. Now we know Google Cloud Platform is the best platform to deploy to. But choice is really important. But it's another piece of the puzzle that you contribute to keeping them happy, right? Their participation in open source while they still have their day job and the accolades and kind of the peer feedback that comes from that's an important piece. So to be able to do that while still having a day job has got to be a big piece of what keeps them at Google keeps them happy. It is. You look at the community aspect around Kubernetes and TensorFlow and the ecosystem is having such a huge effect on the innovation that's happening. And we all get to be a part of that. That's what's inspiring around Cloud. Open's the new competitive advantage, certainly from a retention standpoint of recruiting and productivity. Yeah, and productivity, absolutely. We believe in open content. We're co-creating content here at Google Next with the best minds at Google. Melody, thanks for coming on theCUBE. We really appreciate your time. It's great to see you. Thank you so much, great to see you again. It's theCUBE out in the open here on the floor at Google Next. We'll be back with more coverage. Stay with us after this short break.