 OK, morning, everybody. Wanted to introduce Josh Lambert. He's a product manager on the product management team. He's kindly given us his time this morning to talk about GitLab and Kubernetes. A very important part of our go to market strategy is working with the container schedulers of the world. Kubernetes being what we deem as the one that's winning the race right now. So I appreciate your time, Josh. I'll kick it over to you, mate. All right, thanks, Hayden, and hello, everyone. Happy to be here and to help talk a little about Kubernetes and GitLab and Cloud Native in general. So I'll go ahead and share my screen here. Hit the Play button. So hopefully you can see my slides. If not, just let me know because I can't see folks anymore. But yeah, so again, want to chat about CI, Kubernetes, Cloud Native in general. And wanted to start off with a quick, brief review for some folks who might not be aware of containers, why they're great schedulers, what they are, and why they exist. And then move into why we've picked Kubernetes as the platform of choice, or really our first priority when considering containers and developing features, and then also why GitLab and Cloud Native computing and development go so well together. So let's go ahead and talk a little bit about containers. So to do that, we'll talk a little about how applications used to be deployed, and then move into why people felt these are important and a good thing to build. So in the past, a while ago, we used to simply have bare metal servers. You would run the operating system on them. You'd then install your applications, and you'd run them. And life was good, but there were a few problems. Number one is that if you had an application installed, there were really no protections. They all kind of shared the same pool, if you will. Everyone was all on board. And so if you had someone behaving badly, it could impact the operating system, or it could also impact another application on the system. It was also hard to upgrade independently and to remove and potentially reload a different application or workload, because things didn't always clean up appropriately. And again, they could impact each other. They could share dependency, for example. And so this made things hard. And so people came up with virtualization. And so with this, you actually had a small, minimal hypervisor running. And you could then run a brand new, essentially, mini machine inside of it virtually. And you could do this a number of times. And this was great. You had a really strong security protection around every single virtual machine. And you could run a ton of operating systems as well. And so it could do flexibility. And it gave the ability to kind of move these around and start and stop them as needed. But the problem here is, as you can see, you're running multiple copies of the operating system. And so this is pretty heavy. Took a lot of memory. Took a lot of disk. And it wasn't that efficient. It could take minutes, for example, to spin up a new VM. And so enter containers, which try to take the best of both worlds here. So you can see it looks a lot like the bare metal situation, where you have a single copy of the operating system. And you have applications running as well. But we have some protections around them to help them run securely, like you saw before with a virtual machine, and allow you to swap them out as needed without impacting other containers or the operating system. And so again, this tries to have the best of both worlds. And it looks like a little about this in more detail here. So number one, the operating system itself isolates the containers from each other. And so rather than running a kind of virtual machine that boots new operations each time, the operating system, in this case, instead, provides the protection. They are much more efficient than virtual machines. So they have less RAM use, because they're running multiple copies of the operating system, less CPU, and a lot less disk overhead. And because they aren't starting a stopping operating system each time, they also start and stop in seconds rather than minutes. So it's very, very easy to go ahead and just scale these dynamically. They also still retain the same repeatability factor of virtual machines. So you can, for example, take down the version control container, which live in essentially the version control system for containers, the registry. You can pull down a certain version, run it, and it will run the same time every time you manifest your laptop or if it's running off in the Google container engine, for example. And again, they're also version controlled. And so you can see, move between them, upgrade them very seamlessly. Docker, of course, is the most popular container engine. There also is one called Rocket. That's less popular, but it's kind of the second on the container engine side. So we'll talk about what's about Docker here, since that's primarily what people are using. So for example, now I've got my Docker engine running. That's my wheel. And I can now run, say, for example, Redis in the container, Postgres in the container, and GitLab in the container on my laptop or on my server. And life is good. I can go ahead and upgrade Postgres, be confident it's not going to impact anything else. I can go ahead and swap these out. And things are good. Life is good. I'm already offered this to my customers, my developers, and let them begin coding. And this is great. But what happens when I'm not trying to run three containers? I'm trying to run 2,000 containers. And I don't have one laptop or one server. I have thousands. How does this now scale? I need a system to help me coordinate these, to manage these, to figure out where to run them. How does this work when I have something at the scale of this, for example, which is a port in China with tons and tons of containers? And so if you can imagine this as Google or Amazon or some of the large other software providers, you need a system to help make this work. And schedulers and orchestrators are the system that helps to make this work and to take that complexity and to make it easy to use for developers. And so what they do is they go ahead and they write a simple description of a service. And we've done this with their IDP demo if you look up the YAML files and outputs. So you simply say, I want to run these containers. I want them to talk to each other this way on the network. And I need these storage requirements. And that's it. That's all I have to do. I can then give that simple file to the orchestrator and scheduler. We'll go ahead and pull the containers down, figure out the best places to run them, and then map in the storage and map in the networking. And it's all extremely seamless. So all that complexity of where these are running across thousands of computers isn't really surface to me. I don't have to worry about that. The container orchestrator takes care of all of it. And they do it to help efficiently deploy on the cluster. And so it helps to try and avoid things like where you might have a really, really memory intensive task. And you don't want to try and have too many those on the same machine because then the machine in CPU is completely unloaded. And so it tries to actually intelligently pack containers onto these, if you will, ships or servers. And so you're completely utilizing the full resources and getting the most out of your servers, making you more efficient. And also, of course, making it easy for developers to not have to worry about these details. All they do is simply say, I want to run these things. They need to talk like this. I need some storage, make it happen. And the container scheduler just makes it happen. It makes it happen in seconds. So that's the real value of these schedulers. They obfuscate a lot of that complexity away. And so why Kubernetes? So why have we chosen this as the first platform we choose to support when developing some new features? Well, number one is supported by all major cloud providers. So Amazon, Google, Azure, they all have a container engine. But it also has the highest momentum. You can see here this chart is from Google Trends. And so this is search popularity. And you can see Kubernetes is far ahead of Docker Swarm, which is sort of number two. And this is not unique. So if you look at job postings, if you look at Stack Overflow questions, the same general trend applies. And really, Kubernetes just has a different trajectory, as you can see, from Docker Swarm. And so why is this? Well, Kubernetes was spawned out of Google. For a number of years, Google, of course, had this problem being one of the largest runners of data centers and software out there at huge scale. And so they had this challenge for a long time. It's trying to make it easy for developers to have to worry about all that massive complexity. And so they developed this thing called Borg, which was their attempt to help, again, solve these needs. And they did that for a long time. And out of that experience, they have kind of developing, running, and using Borg for years at massive scale, they developed Kubernetes. And so it has all that kind of knowledge already baked into it. And so it tends to have the best fault tolerance and the best scaling features as well. Things do move quickly here. So they do month releases. And so things change. But in general, Kubernetes is a little more flexible, a little more reliable, and has features like, for example, it can detect if a container is no longer functioning appropriately and automatically restart it and get things back running again. And so it helps abide some guidance there around ensuring you have a minimum number of containers running appropriately as one example. Now that said, it is not as easy to use as Docker Swarm. Docker Swarm behaves the same way on your laptop when you're just using Docker Engine on a single machine as it does when you're running it at scale on a container engine. And so it's easier to use. It's faster to get started. In other words, they're already sort of familiar with it, but it doesn't have quite the same flexibility as Kubernetes does. And so that's, we're backing really, Google. And so that tends to be why Kubernetes is really taking off. And you can see, again, examples here. So that's a bit on containers and schedulers and Kubernetes in general and why we're going with that. And again, more broadly, the market is embracing Kubernetes as well here, as you can see. So let's talk about why GitLab is the best solution for cloud-native companies. So cloud-native companies are ones who are embracing CICD. They're embracing DevOps. They're embracing containers. And they're also, again, trying to really iterate quickly and really move from idea introduction to faster. So this is all of these things trying to work together to try and accomplish. Containers start and stop quickly. They're easily trans-uncomposable. There's DevOps is all about collaboration and reducing them on time. It takes to deploy. CICD works towards the same goals. So all of these things work together to try and allow them to be agile and to deploy more quickly, more confidently. And so that really aligns nicely with our core vision here as well, which is to move faster for my data production, whether it's from a bug fix to a new feature to a whole new product. Our goal is to try to allow companies to do this. And we do it by a fully integrated seems experience. And we also try to shorten feedback cycles and reducing the time to market. So as at a high level, we're very much aligned with the goals of the cloud-needed company. And so let's take it a little step deeper and look into why that's the case. Well, first off, I think developers spend less time waiting and more time coding with GitLab CI. And so why is that? Well, number one, we have auto-scaling of runners. This means that I can go from having one runner running a simple workload to having 1,000 runners, all processing pipelines. And so we can do this by leveraging Kubernetes and containers. And if we can simply spin them up, they start very quickly, they stop very quickly, and so it's very elastic. And so we can adjust the demand as needed and scale out appropriately. Without having to run, for example, concurrent servers, pay for them or not using them, then have limits like that, like Travis CI does. And so that doesn't really work very well for a lot of developers. And it ends up having a lot of queues which can slow things down. And this allows you, this kind of elastic nature allows you to paralyze your pipeline execution. So for example, in a screenshot, you can see GitLab CE. We have a whole lot of tests to make sure GitLab is running correctly any time that it could code change. And what we've done is we've actually broken those into a number of very, very small chunks. And because we're elastic, we can run those all parallel. And so rather than having one or two or three very long running kind of testing jobs to ensure things are good, we can break it up, run 100 at the same time. And rather than waiting for all the 100 to complete or kind of in serial fashion, we can wait for just as long as the longest single job to run completes, and then you can get your answer. So it's much faster to turn things around with this elastic nature than some of the other solutions that have concurrent limits. And so developers can spend less time waiting, more time coding, and iterate more quickly on their code. So that's really important to make effective use of your development team. One second, my laptop seems to be beach balling here. Come on. All right, so from there, we also allow you to collaborate really effectively across teams with some key features. Number one is our review application features, right? So these are our living validation environment that I started at branch creation. So a student developer goes out and starts their job or starts to work on a new feature, they always create a new branch. And as soon as you create a new branch, we now have a new application running, a new container of it running, for example, overarching communities. And that can then serve as a living validation environment, right? So the first time they make their code change, the first time they commit their first changes, they can go to design or product or marketing and say, hey, you know what, can you take a look at this? Because sometimes you have your designs, they don't always translate perfectly. Or maybe you find out that when you're actually using it, it might be a lot better to perhaps design it this way or change it from a radio button to a dropdown. And so you can kind of get these learnings really early in the cycle because developers, as soon as they commit their first code change, can actually see a live running environment and share with the coworkers. Without this, you have to like try and bring someone your laptop, you have to try and ask for a server from some kind of IT person and then load your code onto there. It's all very expensive and very time consuming and really can delay how soon you can try and get feedback, which is really important because if you do it early, you do it often, you can adjust quickly when it's cheap, early on the cycle because you haven't gotten a lot of code done. And also, again, early in the cycle is a lot less risky because you're not trying to make changes one or two weeks before the release. And so these are really game-changing features for collaboration among team members. Also, of course, DevOps is all about collaboration as well between developers and operations folks trying to make sure the stuff runs effectively on their production service. And deploy boards and monitoring really helped try and fosh us communication because developers with deploy boards, they can see how the code is deploying, if there's any problems, they can see that live as it goes through within the same tool they use to develop and monitoring helps to encourage them to look at and see how the code is performing. Not just in production, where there could be potential real problems, but hopefully earlier, right? So as they make their code changes, they can take a look at it and tell them, hey, you know what? Your code change has caused memory to increase by 15%. Maybe you have a poorly optimized SQL query that is eating up CPU time. This is important to know early before it gets into production or before it gets into staging, where it can be, again, harder to fix and more time consuming. So these really helped to foster collaboration and then have a shared responsibility for the health of the service amongst developers and operations people. You also can deploy confidently and frequently with a few key features. Number one, we have CSV pipelines that are version-controlled, and so as our product grows and changes, your tests grow and change along with it, and they're committed right back in the same repository. So if you check out an older version, maybe to make a bug fix or maybe to try and see if a feature still works or was working back then, you can run the same tests that were built back at that point in time because they're version-controlled and that's accurate for that version. You're not trying to run new tests that came in later that are going to, of course, fail. So it's important to make sure you can have that consistency. But also the canary deploys are also really important because kind of building on top of deploy boards, the goal is to try and deploy quickly but also responsibly, and you wanna try and do that to reduce the risk and impact of any issues, right? Because as you're trying to deploy, say, every week or every day, it is possible for issues to get in, and it's important to fix them quickly but also to reduce the impact to the user base when something does get in. And canary deploys are a great way of doing that. They're coming in 9.1 here, you have a great example down below of what they look like. So what you can do is you can actually go ahead and deploy to production but only deploy, in this case, two, for example, canary pods, those yellow pods with the yellow dots. And this allows you to get some real-world testing in production of your code changes and get some real traffic but only limited to 1%, 2%, 5% of the user base. And so you can see how it performs, see if there's performance problems at scale, see if there's problems running in that environment but at a minimal impact. And so if you see a problem, you can correct it quickly or you can simply revert back to the previous version of the container in case it's a more severe issue. So that allows you to, again, deploy quickly but still reduce the impact of your issues. So it's a great feature to have kind of first-class support for in our product. And finally, I would say GitLab is also very microservice-friendly. We have subgroups for architecting your product in an intelligent way without having everything in one big repo. We have a built-in container registry which most other folks don't have. Container registry, again, is that version control system for containers. You have to bring your own for other systems. And we also have cross-project pipelines. And so as you're stringing together these microservices, they all have dependencies. They all talk to each other, right? And so if you're working on a very fundamental API, for example, and you're making some changes, you need to make sure that not just that project's test pass, but you also want to make sure that the tests of any consumers of that API also still pass. And so with cross-project pipelines and for our next release, that's a key feature there where you can go ahead and actually kick off additional projects and make sure those tests continue to pass and things continue to function across a microservice kind of architected application. So some key advantages there and some key features. And we can take a look at some of these and how they compare to a sampling of competitors, right? So I took Travis CI as a common GitHub CI system and BitBucket Cloud. And you can see for these kind of key features we've largely talked about here, we are way ahead of these folks for a cloud-native development environment, right? So container registry, we're the only one with a built-in container registry, we're the only one who has artifact storage of builds locally in our system. Review applications, canary deploy, deploy boards, integrated monitoring, cross-project pipelines, right? These other systems simply don't have them. And so we are very well aligned for cloud-native applications. And we can of course continue to push ahead pretty rapidly here. So with that, I thought I'd take some questions and see what you all want to see any kind of questions on Kubernetes or containers or GitLab CI in general and how we can compare to others.