 Hello and welcome to commit at KubeCon DevOps here on a day zero of KubeCon North America. We're very excited you're here and we have an exciting day lined up of content and community and interaction. My name is William Chia. I serve on the product marketing team here at GitLab. And you can find me a couple of places online. If you tweet at all during today's presentation or talks, I would be happy to tweet back at you and connect with you in those places. So what exactly is commit at KubeCon? Well, commit is GitLab's annual user conference. We've been running this since 2019. We've done it in person. We've done it virtual. And this is really where we gather together. GitLab's community, community of contributors, users, developers, engineers, and folks that are interested in all things DevOps to talk about what's the latest happenings, hear stories of how things are changing and hear about best practices, all these kind of things. So we are excited to have this event today and be with you as well. Our theme for this year at commit has been innovate together. And really for us as an open source company, we have an open core product. A lot of the success of GitLab is because we have such a great community that it's not just our engineering team that's building GitLab, but we get to build GitLab together with everybody. And what we've realized is that DevOps and software as a whole is really like this. The innovations and the way things change, it happens when we do that together. And this is our theme that you'll hear throughout our talks today. Before we jump into today's content, today's agenda, I would love to set the stage and the background for a lot of the content within that realm of innovating together. We want to talk about the next iteration of DevOps, and in particular, the DevOps platform. So if you think about the landscape of software development, it's always shifting. It's always changing. The ground is always moving. Once upon a time, we delivered, you know, waterfall style software and honestly for a lot of folks that are in the chat and online right now, your org is maybe still doing some waterfall development, even though other parts of your org are doing the latest things with Cloud Native. And what's very interesting is as we've encountered different problems, we've come up with solutions, agile, DevOps, Cloud Native, and these shifts have come about because of the change in user expectations. And so today, every single user, whenever they interact with software, especially consumer software, but even in today's day and age, even business software, the user expectation that it's always on, it's available from any device, anywhere in the world. And in order to meet that type of demand, we have that software is being built by distributed engineering forces that are working remotely now from all over the globe. And those software teams, they are trying to increase the speed at which they develop software, increase the reliability of those systems, and importantly, increase the security. And so within this modern landscape, as we're trying to serve these users and we're trying to improve our software practices, how is it that a lot of businesses are going about tackling that problem? Well, when it comes to DevOps, we've seen phases that the industry has gone through. And what we tend to see a lot is that as businesses that go from not having any DevOps at all, and they begin to start to adopt DevOps, they end up having to get more and more tools, right? So they might start with some source code management and they have a store their source code in a tool, and then they might get some CI and they store their CI in a tool. And you'll hear this in some of the talks today of this kind of journey of, OK, and then we got this tool, and then we got this tool. And it just grew and grew and grew in complexity. But the problem, of course, especially here at KUKON, is that now the architecture of delivering applications is changing as well in order to meet the needs of our users and the market demand. And so modern microservices architectures are just increasing the number of projects. So no longer is it just a few projects that I need to DevOps, now you just have this massive proliferation of projects. And each of those DevOps tools needs to interface with each of those microservice projects. And what you end up having is this exponential leap in complexity because the interface between each service and each tool alone that adds complexity, but then multiplied against each other, it becomes completely unmanageable, untenable over time. What is intended to speed us along and improve things and break silos, DevOps, actually ends up slowing us down and building silos. And so these are the stages, the four phases that when GitLab looks at the industry, when we talk to customers, when we talk to users, when we're at conferences like this, like right now, there are several of you that are hanging out, you're in the chat. Maybe you have some thoughts on your DevOps journey that you could share right now. And so we listen to those, and this is what we've heard from you and from other users and customers is that at first, when DevOps first starts in the org, it tends to be, maybe folks just grab whatever tools available. And each local team optimizes for themselves, like bring your own DevOps. Nobody's talking to each other. There's not a lot of communication across teams or across functions. People are just trying to grab something to meet their localized need. Well, pretty soon they realize, hey, that doesn't work. We, you know, especially like if I'm planning on this planning tool and you're planning on that planning tool, we're planning in two or three or four different tools or source code is in two or three different tools. And folks start to realize that they need to consolidate and they need to get on the same page. So they go to a best, well, maybe a best in class phase. A lot of folks will talk about this like, I want to shop for best in class, but is best in class really the best for your org? What we hear from a lot of folks is that it actually isn't because the problem is, is you just you standardize on a single tool to do a single thing, but really those tools aren't talking to each other, right? So you're still siloed, you're still disconnected, you're not really doing DevOps or you're just doing a very immature version of DevOps. And so the next stage is organizations tend to say, like, hey, we really need to cobble these things together. We need to build some lines between these two. This is where we get to the DIY DevOps, right? The final vision, the final thing that organizations and developers and SREs and sysadmins and everybody in the org really wants is a unified system that works together where you have visibility where things are working cohesively. But what ends up happening is when you take a bunch of disparate parts, things that were never designed to go together and you try to put the puzzle pieces together, they don't necessarily fit because they weren't cut out that way. So in this DIY tool chain where you do it yourself with the tool chain, you kind of have all these problems. If you want to know what's happening across your DevOps, it's very, very hard to see what is happening. If you need to do an audit, you need to pull data from all kinds of different tools and normalize that data. It's a huge pain. And so not every organization goes through these phases. Some folks, when they adopt DevOps, they just start out with the DIY tool chain or some folks have started out with saying, okay, we want to select the best in class. But all of these have kind of fallen short. And what we're seeing more and more in the market today is that the current phase of DevOps, the current level of maturity where the market is going and where the market is today is the concept of the DevOps platform. It's more and more about fundamentally changing the way that we approach DevOps. In this final phase of the evolution, we get into the DevOps platform era where you have a single application with a logical set of DevOps capabilities that replaces the overhead and the confusion and the silos of those disparate tools and provides visibility and control throughout every part of the DevOps lifecycle. And so this is what we have designed at GitLab and what we are building for the industry. And when we think about building DevOps together and innovating on DevOps together, this is how we think about it. There's so many different personas, so many different types of people and different roles. Because ultimately this all comes down to people, right? And folks like you and me, folks that are working every day to get things done, they all want to work together. And so when you have, rather than point solutions that are DIY together, you have a single platform, all of a sudden all kinds of different people from all around the org can all work together. And this, you get all kinds of benefits. So not only can now you have visibility across what's happening, not only when you need to audit and you need to pull from what's happening, you have a single store of data or not, even if it's stored in multiple places, you have a unified view of that data. You have a single unified data model and you have a single place in a single interface for folks to engage. And now all of a sudden the walls can come down and now folks even from different parts of the org can collaborate together. And so this is how we've engineered and designed GitLab. But what's really interesting is we're not the only ones that are seeing this change. In fact, there are folks, industry experts like Gartner where they agree and they are seeing the same thing happen. For example, out of Gartner, they have talked about the need to consolidate tooling to move off of tool chains and into platform, into DevOps value stream delivery platforms. And their predictor is that by today, there's less than 10% of enterprise organizations that are taking advantage of full DevOps platform. But that number will grow quickly till where 40% of organizations will be doing that by 2023. And so this is the growth phase, this is the way the market is moving and this is the way DevOps is shifting. It's something that we are excited to be a part of. And that's why we've designed GitLab as the DevOps platform, as an all-in-one platform and one partner for all of your different DevOps capabilities from starting out and planning your software to source code management, CICD, built-in security, that's a first-class object that is a forethought and not an afterthought that is about not just shifting left security, which yes needs to happen, but it should be securing your entire supply chain of software and being able to operate and manage your software and monitor it and improve it over time on another same platform. What's great is that even though GitLab believes in the true DevOps platform that one platform can help organizations run efficiently, GitLab doesn't do everything in the software world. In fact, we partner with many great services and companies to complete the DevOps journey. So we have a lot of great partners and there are a lot of great ways that you can use GitLab together with other tooling and with other services and we're excited to be a part of that ecosystem. And then the next thing I tend to hear is when folks say, wow, this platform sounds amazing, but I just spent six months or a year or two years building my DIY tool chain, I did do it myself and I built that and it took a long time and I cannot imagine throwing that all away and all of a sudden just having to rip and replace for everything. And the good news is almost nobody does that. In fact, what's pretty cool about GitLab is that you can start where you need to. And so most folks, most organizations, they start usually with our create stage of DevOps or the verify stage of DevOps or you're doing source code management and CI. Those are fundamentals, those are the most mature parts of GitLab. And then as they grow and they adopt other parts, maybe they start using GitLab for agile planning, maybe they start using GitLab for security and for deployment and for package management. And the more parts of that platform that they adopt, the more benefits they tend to see. And this is why we're proud of, how many leading organizations, how many robust and sophisticated software teams are using GitLab today and are taking advantage of the DevOps platform. And so today, throughout the talks, we, you will be hearing about the DevOps platform, this new, the latest era in DevOps, where the industry is going and how things are shifting and we're proud to be part of it. So we have a great array of speakers lined up for you today, covering topics from the era of platforms to how to do CI at massive scale and even talking about how to run from legacy technology like ZOS and how do we do that? So a lot of great topics are on the way with a lot of great speakers. And I do want to remind you to head over to the GitLab commit virtual2021.com site slash KubeCon head to the KubeCon section of the site and the SCED is right there embedded in the page or you can go to the SCED for this commit at KubeCon event and want to encourage everyone to sign up for a SCED account and after each of the talks, please go and rate them. We look at and we use those ratings to determine which speakers we invite back, which talks you like, how to get more talks like that. And so we really want this to be an interactive event. Like I said, say hello in the chat, talk to the speakers while the talks are going on. This is a unique part of being at a virtual event where while a speaker is speaking, you can actually talk to them in chat and well at the same time. And so take advantage of that, chat with each other, share stories with each other and please do rate every talk as we move forward throughout the day and all of us can innovate together. Thank you.