 Live from Las Vegas, it's theCUBE! Covering AWS re-invent 2019. Brought to you by Amazon Web Services and Intel, along with its ecosystem partners. Well, welcome back live in Las Vegas. We're here on theCUBE. Continue our coverage here. Day two of AWS Re-Invent 2019. In fact, it took me to the last interview over the second day to be paired up with my guys, Stu Miniman, Stu, what happened? This is the first interview we've done this week. Well, John, you know, I've not been out playing golf, so. And I wouldn't mind if I was, it'd be all right. Brandon, you play golf? Brandon Young? I do, I play college golf, so. Oh, you did? And I have, you can't see them, but I have some trousers that might match. They're improved that I have done a few times. Pain syrup would be proud. Yes, he would be very proud. Brandon's a VP of alliances at GitLab. Where'd you play college golf, by the way? I spent some time in Oklahoma and down at Rice down in Houston. Yeah, OU? OU, yes. Wow, be a sooner, how about that? Yes, yes, so. They have some pretty good golfers there. They do. First off, let's talk about VP of alliances. Sure. And GitLab, what do you do? So what does that encompass? What's that all about? It covers a bunch of pieces, covers all of the big key partnerships with us, so that's going to be obviously Amazon, the other big cloud providers, a lot of strategic technology partnerships, and then all your system integrators, man-service providers, resellers, and then, functionally, anything else that comes in. So also, we are big in the open-source space, so lead a lot of our open-source engagement as well. What kind of customer base we're talking about here? I mean, for you guys, sorry, because it's pretty significant. It is, so in the space, we've got roughly two to three million users that use GitLab and count on it for building, deploying, and securing their code, and somewhere between 100,000 and 200,000 companies that GitLab is being used at. Brennan, you're not only with GitLab, you're also on the board for the Linux Foundation, and we're getting close to 2020, so I even, I saw some people looking back at where open-sources come in the last decade, and Git, of course, is one of the predominant drivers for the proliferation of open-source. So tell us a little bit about what your customers come to, why GitLab is so critical to what they're doing. Sure, yeah, if we look at history, it kind of makes, naturally, in GitLab, we're Git, so that was where our base was when we started 2012, 2013, as it's evolved, so, and Git continues to be that core piece you need, so whether you're doing GitOps, infrastructure as code, application development, you've got to have state, you've got to store your issues, you've got to take care of that, that's just one-on-one in software development or infrastructure management, so that's kind of where we started, and then a couple years later, we picked up and did a bunch of stuff in the CI-CD space. Initially, we had them separate, and customers kept saying, ah, these might work well together, and to the Linux world has always been single-tool, very sharp, very narrow, so we held off on that for a long time, finally said, oh, we're going to give it a go, shipped them together, and that's kind of led to where we are now, which is we think of GitLab as a single-tool for the entire DevOps life cycle, and that makes it easy for someone to get started, to build it, secure it, ship it, all of that from idea to production in the shortest possible time, and so that's kind of how it evolved, and yeah, we've grown up with the open-source world ever since, and it's an awesome place. All right, so you've got the alliances, and we're here at the biggest cloud show there, so help us connect the dots, GitLab, AWS. Yeah, perfect, so if we kind of look back and we go, look at the keynote, right? So Andy talked a whole bunch, front keynote, Goldman Sachs, big talk with Verizon, a lot around the services, new stuff with ARM, new chips, new, a lot of new databases, all of that rolled out. Those are services as Amazon looks at it. Our goal, our job is to get those customers onto the Amazon services. We're the tool that helps them develop and deploy those applications. Goldman, huge customer, Verizon, huge customer, so the majority of the keynotes use GitLab to get to Amazon, so we're that tool that does the application security deployment and lets those devs really take advantage of the great services that Amazon delivers. You know, when you talk about security, is it, and obviously it's increased in terms of its importance, we recognize, we've seen how vulnerable apps can be and these invasion points. Is that being reflected in budgets? Are we seeing that? Are people making these kinds of investments or is there still some lip service being paid to it and maybe they need a little more money where their mouth is? There's not a shortage of dollars, so I'll be real straightforward. That is for us, the big growth area is application security in a pipeline, the notion of shift left. And it's actually one of the easier conversations because the CISOs really want to make sure that every piece of code is tested, be it static code, dynamic code, license scanning, all the above. The way they've had to do that and traditionally done it is at the end of a pipeline and they make every dev unhappy because they throw it all the way back to the front with the dev and it's like, ah, thank you so much. I did that two weeks ago and now I have to go back. Yeah, why don't we do it on the front side instead of the back side? Yeah, you kill the most important thing which is cycle time, right? Cycle time is time from idea to chip. So by shifting it left, there's plenty of money and the CISOs love it because. It's just when you spend it. It's where they spend it, right? And so now they get all the code tested, the devs love it because they get feedback instead of the CISOs saying this is broken. The two old, the second they hit commit a couple minutes later, oh, it's broken. They go fix it, make another commit. They're going to move way faster, much. So that's really what we get at. Yeah, but no shortage of dollars. The security still don't. But it's about when the spend happens. You're saying it's on the front side instead of the back side. Yeah, yeah, and try and get full coverage. So a lot of times, otherwise, if you're trying to do security after someone's developed it, you're not sure, like are you getting every code, all the piece of code that was developed? Are you getting just a lot of it as you talk about web apps, a lot of it's a focus. Oh, the web apps, because that's the front end. But intrusion, once it passed the front end, it's a soft interior. You've got to do every single piece of code has to be tested. Yeah, it's Brandon. So what I've heard, especially from my peers in the security industry, security needs to be considered the entire way. Security is everyone's job, chair's responsibility. I need to think about it. But the other thing that really has changed for people is you talk about CICD, I need to move fast. Well, hold on, the security team's got to review everything. One of the core principles of DevOps is you want to bake it in the process. You need to get them involved. And then there's DevSecOps, which pulls all of these pieces together. So tell us how those trends are going and that speed and security actually go together not opposed. And it's how you measure the speed. Because I think sometimes the question is all back to what is it from, it's a life cycle. And if that's what you're measuring, being able to do the security earlier is so much faster because you're not having to iterate later. But it continues to increase. Devs are getting more and more, say that's not going to change any time soon. Empowering those devs to own the security, empowering those devs through the pipeline to be able to deploy into Lambda, into Fargate. They love that. And if you can give that and give the security, the visibility, the dashboarding, the understanding of what just went in, what code they're using, what the licenses are, that visibility's huge. And that allows you to move fast because of trust. I mean, actually, I love the researchers at Dora, do the annual survey on DevOps. And they said, actually, if you are a company that tends to deploy less often, it tends to take you much longer to recover and you're not geared to be able to do it. My background is networking and you think about security is one of those things like, well, wait, I want to keep my things stable and not change it for a while, but that means you're less and less secure because I need to be on the latest patch. I need to be able to update things there. So CICD, I think, should lead to greater security. Do you have some stats around that for your customer as to how they measure that? I mean, we have some pretty good velocity. So Goldman went with us, and this is real public, because they started with us and went from about a two week release cycle down to 10, 20, 100 times a day. I mean, that's a company that does a great job on Dev, but it can also be smaller companies like Wag Labs that we talked to you through earlier. And they, same kind of thing. They went often from a week down to, they were doing, they typically do 20 to 30 deployments a day. And again, it just makes you break the pieces smaller, less likely that you're going to introduce dependencies that break something, and all that process builds on each other as the door is stuffed. If you haven't read, you've read it obviously, but if the users have a great place to get started and understand how this works. No. Has testing changed, or is testing changing in terms of when you establish a criteria, what you're looking for in terms of, I guess you have a lot of new capabilities. So you've got to change. I assume your criteria up front to have a little proper, a little more accurate evaluation. Is that environment? It's changed some, but I mean testing, in application testing, it is pretty specific to every company. So tools continue to get better. Ways of review have gotten a lot better. So there's now a lot of capabilities that at the point that you're going to go into deployment. One of the harder pieces is doing your user acceptance testing, is like, oh, am I going to see the same thing that a user will? And a lot of these have gotten to a point, we have one click at the end to deploy a review app. Anyone in the company can look at exactly, rebuild everything you're going to about to deploy. So there's some tools that make it faster. But in terms of what you're load balancing, in terms of your user acceptance testing, a lot of those principles continue to be pretty good. Same drill, yeah. One of the big things we heard from Andy Jassy is talking about transformation. And he said, you can't just do it incrementally and you need clear leadership and commitment. I want to hear how you're hearing about this from your customers. How is GitLab helping customers along those transformation journeys? Sure, so totally agree that, I mean, it's a cultural piece without question. I think there's a couple of places. There's obviously the tool piece and just getting everyone on the same page. And we all know this intuitively is we've seen when you go from a word doc to a Google doc and everyone can edit at the same time. That's transformation because you know what everyone's working on and you're not duplicating effort. And that's really, in many ways, that's what GitLab is doing, is just helping the front end product manager know exactly what's going on the infrastructure side and you communicate in a similar language. The other piece that we are working a lot in is because GitLab operates an extremely open culture. So we publish how we run the company in a handbook that's 2,500 pages. We're always updating it. So we do reviews every time we release, we release every single month for the last 120 months in a row. We go through, here's what the release is going to be. It's on YouTube, everyone can see it. When things go wrong, we publish it. So we have an outage, we have live broadcast how we get back out from an outage and we publish all of it for someone to understand. And so one of the other things is a lot of our customers are getting started on that journey. There's one thing for a doc that says, here's what you do for your transformation for your company. It's another thing when you can literally jump in on Monday morning onto the GitLab call and watch GitLab go through a post-mortem of when we had a small outage. Oh, that's what a no blame looks like. Okay, now I understand that. Hey, what didn't we release that we could have done better? And those are processes that, you can have it on a piece of paper, but it's a different thing when you can walk through that with a company. And it's even better when you're watching the company that's doing the same product, the same tool that you're using. So that's a cultural decision. I mean, it's got to be, right? And it takes, I love the no blame, right? Because you're saying instead of figure pointing or castigating, we're going to learn from this. And how do you think, what impact does that have on a customer when they see you in real time solving your problems? They know that if they have a question for us, that we both take it seriously and that we're going to do it in a way that they know when it's going to be resolved. And that doesn't mean that we always deliver at the time that a customer asks, but that level of transparency breeds both a trust. And it also helps a customer quantify what do they want? Helps a huge amount of communication because they know what we're prioritizing and they understand why. And that isn't something that is typical to a company. It's always typically very hard unless you're broadcast everything like we do to know, well, why are they making that decision? And so that's one of the real big reasons that our customers work with us. That's where we get 10,000 plus additional contributors to GitLab as an open source project. And that helps massively, of course, to the velocity is because there's no difference between the 1,000 GitLabbers in 64 countries or any one of the 10,000 contributors or our biggest competitors that regularly make contributions to our landscape. So we have a landscape that's, how does DevOps work? Who does stuff well? Hey, have no shame. If they delivered something better, I want to know that. Make that commit, we will share it with the world that we are not good at that and you are better at it. And you know what? We'll get better. Right, it's a winning formula. It's been good for you. It's been working really well. Appreciate the time, Brandon. Good seeing you. Thank you. And again, love the slacks. Wish we could show them. But next time. Thanks for having us. All right, you're watching coverage here of AWS FreeInfinite 2019 on theCUBE.