 Hi, I'm Jesse Lovelace. I'm a Solutions Architect for GitLab. Today I've got Brendan O'Leary with me. Brendan, let's talk to you about yourself. Hi, yes. So I'm a long-time GitHub customer, but we started looking at GitLab about a month ago, and so I've just got some questions that I wanted to ask you relative to that. Sounds great. Go for it. So first, you know, we're trying to move away from, you know, hosting our own servers on promises, but I understand that GitLab, you know, is a self-hosted solution. So does GitLab support going to the cloud? Yeah, for sure. GitLab actually supports a lot of different cloud technologies, whether you are using just standard cloud VMs and need to install from a package like a Debian or some other kind of Linux flavors package. We also support a lot of different layers past that. So for instance, if you want to use some sort of deployment manager like Terraform, CloudFormation, Ansible, we also support cloud-native technologies such as Docker containers and also container orchestration systems like Kubernetes. Okay, that sounds great. My teams are geographically diverse. Like I'm worried if we're hosting in the U.S., it'll mean that GitLab will be too slow for my Asian developers. Sure, so GitLab has a lot of support currently for what are called GitLab Geo. GitLab Geo allows you to have geographically dispersed read replicas. What this does is allow you to, your developers to pull your source code extremely quickly from a server that's actually geographically close to their location. And that really helps out for geographically dispersed teams. Great, great, thanks. What about high availability in the cloud? Is there support with that for GitLab? Yeah, for sure. There's a lot of different ways that you can ensure that your GitLab installation is both protected from downtime and also protected from a disaster situation. So the first thing we have is really, really smooth support for disaster recovery. And this comes through really simple ways to actually snapshot and restore your entire GitLab installation. So with one command, you can snapshot the entire installation and then with another command, you can bring the entire installation back up on another server. So, for instance, if you want to back up all your files to S3 or some other off-site backup or however you want to do it, it's really easy to bring everything back up again. Now, we also have support for single-region HA and the way that we pull this off is you can have multiple GitLab front-ends working in a single region and spread those out across multiple availability zones. You can also have either multi-master or some sort of pool master database layer and then a high availability NFS cluster to host your files. This allows you to have pretty good support in case any one availability zone within the region goes down. Great. Great. Thanks. Another concern I have about the cloud is I have very sensitive business data, of course. Our competitive advantage is the software where you're right. So if my GitLab servers in the cloud want to be publicly exposed and how do I prevent people from being able to access it? That's a great question. So GitLab has native support for secure sessions over SSL, but it also supports a lot of different secure authentication methods, not just the typical user and password. So, for instance, OOF, different SAML and SSO implementations, LDAP, and these help your systems stay secure and GitLab from necessarily having to keep any of your user passwords in some database. Now, additionally, all the major cloud providers allow a lot of flexibility in securing access to applications like GitLab. For instance, you can set up secure virtual networks that are not accessible from the outside world, and then you can then hook up your company's internal VPN to bridge those two networks. Also, the cloud providers offer a lot of flexibility in their firewall rules, so you can lock down certain IP subnets or individual addresses that make it so that they're the only ones that can actually access the GitLab server. Great, that makes a lot of sense. So, one other thing that a lot of my developers are talking about is, you know, truly cloud-native technologies, and, you know, I hear Kubernetes a lot. Has GitLab thought about Kubernetes, or are you doing anything with Kubernetes or other cloud-native technologies? Yeah, for sure. GitLab is actually really, really interested in staying at the forefront of cloud technologies. And so, specifically, GitLab has an amazing feature called AutoDevOps, which allows you to automatically build and deploy a Docker container to a Kubernetes cluster given a successful CI build. Now, additionally, just recently in 10.1, we added support for being able to not only deploy to a Kubernetes cluster, but actually create and provision a Kubernetes cluster on demand in Google Container Engine and then deploy your application out to that newly created Kubernetes cluster. Wow, that's impressive. Well, thanks for your time, Jesse. I've got another meeting I've got to run, too, but it was nice talking to you. Thank you, Brennan. Bye-bye. Bye.