 Hi everybody, thanks for joining us for this demo presentation. My name is Phil Lamb and I am Senior Solutions Architect for AppDev with Red Hat Global Strategic Alliances. And with me today is Kurt Dusek from GitLab. Kurt. Yeah, hi everyone. My name is Kurt Dusek. I'm a Senior Solutions Architect with GitLab. And we're really excited today to talk with you about the upcoming general availability release of the GitLab server operator for OpenShift. Awesome. It's pretty sweet. All right, so Red Hat, you may have heard of us, maybe. We've been a proud partner with GitLab for more than a year now. And together we've been working on building solutions that are having a real great impact on our customers, whether they're working to modernize an existing application stack or green-filling a brand new product. But the most important and inarguable fact is that we are the world's number one provider of commercial IT products and solutions based on open source software. And we lead by a large margin. More than 90% of the Fortune 500 use Red Hat products and solutions. And we have a vast reach around the world and in a range of industries. Successful companies are using our products. And we have approximately 13,815 employees, you know why we say approximately because that definitely is specific. But I'm sure that number is a grief. In more than 40 countries, we have really a worldwide presence, offices in those countries, we have 105 total. And Red Hat really does have the size and the scale and the capacity to meet customer needs. We have a global presence and we can support our customers and partners wherever they are. And of course, there's one of the biggest things that Red Hat is known for, open source. So we're a large scale innovator of open source technologies. And we collaborate with open source communities, partners and customers. But we also do a lot of pure development to ensure that our products are suitable for enterprise-wide critical deployments. So working with Red Hat means that you have an advocate working on your behalf to improve existing open source tools to better align with your business needs. So of course, Red Hat Enterprise Linux or REL for short is one of our best known products, but we're not just REL. In the realm of Hybrid Cloud, in addition to Ansible Automation, we have OpenShift, which is an enterprise Kubernetes-based container orchestration and management platform that allows for flexible, scalable, and resilient infrastructure. It also enables faster application development and deployment with OpenShift application run times and is portable across different cloud platforms. We call that Hybrid Cloud. Even for organizations who have not yet begun a digital journey, OpenShift can offer an opportunity to try out more modern technologies and see if they have a place in your organization. Ah, you might say, but if it's just Kubernetes, we can just do that on our own. Well, yeah, I mean, you can, that's technically true. Vanilla Kubernetes, however, is missing a lot of key features that we've baked into OpenShift. So OS container run times, image registries, SDN, load balancing and routing, log management, metrics and monitoring, DNS, ingress control, RBAC, just to name a rather large few. We've included all those and they're ready to go out of the box in OpenShift and it's going to save you a lot of time. We don't just offer a DevTool or an OpsTool, but instead offer RedHead's Cloud Native Application Platform, which is a full catalog of tools for end-to-end lifecycle management, which allows your teams to work together and helps drive innovation to your customers faster. So one key aspect of OpenShift is its certified operator ecosystem. The GitLab has already released a certified runner operator and they're rapidly approaching GA for the server operator that we'll be talking about today. Now, let Kurt speak to the specifics. First, I'd like to answer a question that some of you may have, which is, well, what's an operator? Conceptually, operators take human operational knowledge and encode it into software that is more easily shared with customers and consumers. Operators are pieces of software that ease the operational complexity of running another piece of software. So they kind of act like an extension of the software vendor's engineering team, watching over a Kubernetes environment, in this case OpenShift, and using its current state to make decisions in real time. Advanced operators are designed to handle upgrades seamlessly, react to failures automatically, not take shortcuts like skipping a software backup process to save time. And more technically, operators are a method of packaging, deploying, and managing a Kubernetes application. And maybe Kurt, you can share a few specifics about GitLab's operator offerings. Absolutely. So today, you can install the GitLab runner via the operator hub to an OpenShift cluster. And the GitLab server operator is currently in beta and that's gonna have an expected general availability release of Q3 or Q4 of this year. Once the operator is released, installing GitLab into an OpenShift cluster is gonna be as easy as searching for GitLab in the operator hub and clicking the install button. So if you know anything about GitLab, you know we're a very transparent company. Our developers have made great progress over the last few months in building the GitLab server operator. So you can visit the link above to get a deeper understanding of the progress being made for the server operator and even contribute to that effort yourself. Cool. Yeah, that's one of the fantastic things I think about the integration that we have together is to open source, open ideas, focus companies is that I mean, this is proof in the pudding of the benefit of using this methodology for developing your products. So in keeping with this idea of the open organization or open source and especially what GitLab does around that this is an example of the GA release epic for the GitLab operator. And this is publicly available. You wanna take a look and see how things are moving along. You can see pre-GA, so that's the beta. We've announced the beta version in a blog post and that's actually linked over here in the GA epic. You can take a look at that. So as Kurt was just saying, GitLab is a very open organization and in keeping with the spirit of that they've got ways for you to contribute if you want to help move along the GA release of the GitLab operator or just take a look at the source code take a look at this epic for the GA release and the link is down there at the bottom of the slide. Kurt? Yeah, absolutely. So the server operator is in a public beta. So we don't recommend using it for production deployments of GitLab but we do welcome you to try it out and offer your feedback. So the operator as it stands today you can deploy via manifest or you can perform the manual build itself and that's gonna create a GitLab custom resource definition within your cluster. And then from there, it's easy to configure and deploy that new instance of GitLab using the same configuration values that are available via the GitLab HelmChart. You can then use that instance of GitLab as an identity provider for OpenShift via the built-in OAuth integration. Now features we expect to release after the general availability include Kubernetes ancient support and that's gonna allow you to connect to clusters that are maybe behind a firewall or air gap. And we also are gonna eventually offer native support within AutoDevOps which will speed along your digital transformation journey and also zero downtime availability upgrades. Well, yeah, that's pretty fantastic list of features. I think we can, especially, I'm a big fan of the zero downtime upgrades. I think one of the biggest problems that people run into, especially in smaller dev shops is, well, you're spending all your time keeping the lights on. And I mean, that's really one of the benefits of going with this operator framework is that you don't have to worry about, when are we gonna plan the next upgrade? Are we gonna have X amount of downtime? Are we going, is this gonna be only on a Sunday or are we gonna be delayed or lag? But this is a great way to avoid that. So that's some specifics about the operator and now I'd like to move over to a little bit more kind of abstract look at how you can assemble all these various parts together, whether it's OpenShift and RHEL with the GitLab server and runner operator sitting on top of it and how you can get to this functional kind of DevOps environment. So we've talked to some about operators and what they can do, but we need to talk about the how. So how are GitLab and Red Hat suited to implementing DevOps? Well, let's take a look at this diagram. So starting from the bottom and working our way up, you're building a solid foundation by utilizing Linux based operating systems like RHEL and it's little sibling core OS and you're setting yourself on the path of success and drastically reduce keep the lights on work, which I mentioned earlier, by choosing OpenShift as your container platform. OpenShift allows you to consistently run GitLab on any type of infrastructure. So whether that's a public cloud like AWS or GCP or your own private data center or even an actual individual single virtualized machine, OpenShift is gonna allow you to easily scale your instance of GitLab based on the needs of your organization. So you can run and provision multiple OpenShift clusters and those are all gonna have a common infrastructure via common infrastructure as code configuration and that's will enable GitOps for multi-cloud deployment. So this will allow you to build software, run your automation and deploy to production across multiple cloud vendors and platforms while maintaining a consistent experience. And this is ultimately gonna allow you to reduce your complexity and increase your development velocity. Which I think something that we could all use in the development world, especially with the rapid advent of new technologies and whatnot. So that's really cool. You mentioned hybrid cloud, maybe we can talk a little bit about cloud-native development and how OpenShift fits into that. So I would start with kind of the guiding principles behind the Red Hat OpenShift cloud native application platform, that's a mouthful, can be categorized into four areas So there's innovation, which is happening in open source communities and Red Hat is the best position company to help contribute and grow those communities as well as bring the value of that innovation to customers. And while customers have demands to run applications in many clouds, they also want to reduce the amount of operational complexity that comes from multi-cloud strategy. The OpenShift enables customers to have a consistent development and operational experience as what you were talking about occurred across any combination of clouds, whether they're public or private, or as you said, on-prem, bare metal, whatever. As we learned over the years, there's no single profile of a developer or the way that developers want to get applications into production. So OpenShift is flexible to enable many ways to empower developers and allow many types of applications on the platform. And that's one of those things that I always think about when I was getting started with DevOps and like my agile certification that if you've ever taken an exam like for a certified scoremaster or something like that, I guarantee you that you've had the same feeling that I have, which is, oh, I learned all this stuff in this class and this is exactly how to do agile. Nope, no, no, no. Like Audie Murphy said, that plan does not survive first contact with the enemy. So OpenShift really does allow you to embrace the diversity, I guess, of how applications get developed and where they get deployed to. It's also from a provision ability. So we've talked about configuration for OpenShift, which is in GitLab. So it doesn't matter who your provider is. If you're leveraging GitLab to deploy OpenShift into whatever you want, that also provides for, for example, cross provider disaster recovery or at the very least cross region. And if you use OpenShift as your high availability approach, that, I mean, that simplification means that there's no replication of work. So you don't have to be in this console and that console and that console and that console. It really lets you kind of focus on developing. So I say OpenShift in GitLab, enabling you to avoid having to reinvest the wheel every time. Kurt, do you have anything you wanted to add on that? Absolutely, I mean, just to really reinforce that point. I mean, you can do a lot more than just host GitLab on OpenShift. That's the tip of the iceberg. Again, like we were talking about earlier, if you define your OpenShift configuration as code, store that within a Git repository. You can easily provision all sorts of clusters, again, creating that consistent environment that's gonna allow you to test your software, stage that software and then release it into production as consistently as possible. It's gonna reduce any type of friction between your lower and higher level environments. Again, that's something that you can provision and execute via GitOps type workflow where your infrastructure is defined as code. Yeah, so that sounds fantastic, Kurt. Thank you for giving us a little bit more detail on that side and also showing how everything kind of fits together. I do wanna say thank you to GitLab for giving us the opportunity to make this presentation. You can find out more about Red Hat at redhat.com and you can find out more about GitLab at gitlab.com or take a look at the booth or what have you. Kurt, any final words? Really, other than I'm super excited for the server availability, for the server operator general availability, I think that's gonna be a great aspect and platform to run GitLab on at scale in the future across any cloud provider you choose. Cool, yeah, absolutely. Well, thank you guys for watching or listening. And Kurt, thanks to you and all the folks at GitLab are doing such amazing work. It's been a real pleasure to work with you on this and I'm hopeful that we can see GA very soon. So we'll see y'all then then.