 Hello. Thank you for taking the time to meet with me. My name is Atef Rashid. I'm an Alliance Solutions Architect supporting Google Cloud at GitLab. And I'm excited to spend some time with you today to talk about something near and dear to my heart, which is developer flow with GitLab on Google Cloud. First, I just want to say that the reason, so prior to joining GitLab, which was, I think, under a month and a half now ago, I was at Google Cloud for four years in a technical role. And it was a rocket ship while I was there. Google Cloud exponentially grew the number of people, the number of services that they provided. It's still a very exciting proposition for a lot of developers. I'm sure all of us know about all the different Google services that are out there, but they have global scale. And the sort of power that's unlocked to a developer to host their services on Google Cloud is pretty great. I mean, with a very small team of innovative developers, you could actually write a very small application that could scale to meet billions of users. And that's something that happens quite frequently for customers of Google Cloud. And you just see it everywhere you go when you start working with customers over there. You'll see that the innovative sort of creativity kind of exude from people's pores, right? It's a pretty exciting place. Google Cloud has a pretty cool network, in my opinion. They have capacity like all over the place. So they have 22 regions with 67 data center zones within those regions. And the one sort of exciting part about Google Cloud that I think is pretty unique is their entire network is kind of virtualized. So the entire backend and front end and edge is all containerized. And so they can get very clever and very smart with how they manage traffic across the board. They have 140 global points of presence with 96 edge nodes. Apparently the stat is that they go through or spin up 4 billion containers a week on their infrastructure. I believe GitLab and Google share a lot of key values. The list on the left is the eight sort of pillars of innovation at Google, not just Google Cloud. And you'll find that there's a really tight affinity of the same values at GitLab. And so Google Cloud employs more open source developers than I think any company that I've seen. And it's exciting that they pay developers to develop open source services, open source code. And that's very similar to GitLab. And so you'll see all of that sort of appear or manifest in the services that they deliver that Google Cloud delivers. And I think you also see it at GitLab. I mean, in my opinion, I feel like GitLab is just scratching the surface of unlocking all of the products and services of Google Cloud. And it's a very exciting time to be at GitLab, in my opinion. So for most cloud consumers, I would say that the cloud or the hosting providers kind of sometimes takes an afterthought to developing a product, right? So if I'm building a product or an app, then I'm usually thinking about my users and their usability and tracking them and all of the APIs I'm consuming to build my app. And while that's all fine and good, I feel like a lot of companies or a lot of customers have existing apps. And those apps are probably from the past 20 years, where they've, you know, have some business function related to an app or they're using an app that's, you know, helps them sort of generate their day to day business. And so for me, when I think about when I'm building an app, it usually comes from a place of iterating on top of an existing app. And so while there are use cases of customers like startups who build apps from scratch, but most companies have a legacy. And this diagram sort of articulates that legacy a little bit. And there's all sorts of ways to think about how to move to cloud. And where I see GitLab sort of shine or optimize that move or sort of iteration is around the improve and move. So usually what happens is an application decides to move to cloud, they go, oh, I'm just going to try to move it like for like, I'm going to try to do it exactly the same way I did it in the data center. They try to do it, they realize that it's not as easy as they thought there's some gotcha, there's some engineering hiccup. It's this forever scoped thing that they'll never be able to sort of land on. And so usually where it all ends up is this improve and move sort of approach to try to get to that target. And then once they get to cloud, then that's where in my opinion, the real sort of innovation and iteration start because there it's just become so much more flexible, so much easier to actually build stuff. So once customers build an app on the cloud, it's kind of a forever thing, right? They go out and they qualify the APIs or the technology they want to incorporate in their app or their application. They discover new services, new ways of doing things, they evaluate those new things, they try to solve existing problems, improve on those problems, and then they build some sort of proposal or some sort of bet. And it isn't until they actually start, that's when they actually put hands to keyboard and build stuff on a cloud provider. And so where most cloud providers see they usually start at that point, they usually say, look, we want to get our developers to the point where they're actually building stuff. And then what happens is they go out and build some application, and they come up with some first release and on it goes. And then they start scaling users and more people and it goes on forever. And it's this ongoing thing. And the reason why customers consume cloud for years, like they commit to it for years is because they know, like there's so many services and so many iterations that they'll need to go through to really keep up with their business or their market or their customers or users. And so where things sort of go sideways a lot of the time is when they go and do a lot of discovery and qualify these new technologies, but they don't actually figure out, it really looks great on paper, right? So they kind of like any one would go out and start consuming these services. But then there's a lot of learning that's required to figure out how to fit all these pieces together, how your database is going to talk to Kubernetes, how you're going to host certain portions of your app, like what should be a cloud function versus what should be a container versus what should be a server. And it's those types of experiments that lead you through some design exercise that lets you figure out what you're ultimately building. And then there's the whole sort of relationship around a cloud foundation. Now to me, a cloud foundation is the constructs of security and the constructs of networking. And the reason I choose both of those is that usually networking is complex and security is even harder to achieve. And so a cloud foundation requires both of those things to have a very firm sort of, MVC type setup in order for a customer or anyone really to put their production application, their data, their company assets onto a cloud provider. And even then, to actually take it to the next step, then they decide, look, I want to actually build something, but I already have existing systems and existing processes or silos in my organization that I need to overcome. And that's, and it's those sort of key points of friction or that complexity that really causes a lot of gravity in your migration, but also your build, which ultimately slows down your adoption of cloud, but sort of the iteration onto cloud. And then it becomes very hard and slow. And that's where I see time and time again where customers sort of, or companies sort of have trouble adopting cloud. And where I see a lot of value, just to take a step back from sort of the migration or build on cloud concept is sort of this kind of approach toward thinking about how to do software delivery and sort of platform modernization on cloud. And looking at this sort of layered cake approach, what you'll notice is that the stuff at the bottom, which is again that those network sort of wins or their security foundation, those are very tactical and tangible results. Like if you spend some time to build that cloud foundation, you could very easily show that value to someone. However, in my mind, I feel like the true strategic outcomes are usually at the top. So if you think about how hard it is to sort of measure software delivery, there's a few ways to do it. You could think about monitoring like the number of lines of code that people write, but then ultimately a developer could just start writing more inefficient code. And then all of a sudden, they meet the metric, but then your code base isn't great. Or you could perhaps monitor the number of bugs that start appearing and the number of bugs that are smashed in any week or any month or any cycle. And ultimately anyone could just create a bug and then solve the bug. And it's a very hard metric to measure or sort of be accurate about. I propose to this audience that maybe the best way to measure productivity is employee or developer engagement. I feel like if a developer is unhappy, if the culture isn't great, they can't really be that effective. It's sort of necessary to kind of drive that engagement. And if they are sort of happy to be what they're doing, maybe they're passionate about what they're doing, then I actually think you can sort of measure that in the engagement, right? So if they're passionate, they'll care about your project. They'll care about the outcome. And then you kind of see that sort of manifest better. And that's, I think, the only metric at the top that I think any of us can measure. But in this middle tier, that's where I think GitLab shines. So it's that middle tier and the bottom tier. So in the bottom, you have a lot of DevOps foundations. And there's a lot of talk about DevSecOps and DevOps. And I'm sure there's a lot of really smart people who can talk about that. Where I sort of spend my time is in this middle tier around application modernization and migrations and platform modernization. All of that is a forever endeavor for a lot of people, right? They think about, okay, like, I'm going to modernize some application. Where do I go? How do I do it? How do I think about it? How do I mitigate that risk? How do I mitigate that friction? The other sort of side of it is data. And so this is in data science, it's data management that I'm talking about. How do I control costs? I can go on to BigQuery tomorrow, type in select star, and maybe end up with a very big bill at the end of the month. And it's because I wrote poor queries. Perhaps I am putting data that's sort of production or sensitive PII data in a sandbox that has lower security controls. How do I classify my data? How do I think about that? How do I manipulate my data, process it at scale, start using those services? All of those questions can very easily be answered by GitLab. It's a very interesting sort of flexible full stack solution. And I'm going to walk through some of that today. So looking sort of back where I see GitLab sort of shine is in this sort of optimization of these things. And where you kind of see GitLab help customers or specifically cloud sort of migrations or iterations is that it really starts making it a lot more consumable for actual practitioners, right? They can actually go in and with an agile board and with runners hook into cloud in a way that's pretty compelling and sort of abstracting out a lot of the complexity that is sometimes overwhelming when you first sign into a cloud console for the first time. Where I see kind of all of this manifest is if people are sort of adopting GitLab correctly, they start optimizing how they're consuming cloud. And so that sort of cycle of, you know, I'm going to do a lot of discovery and evaluation, that starts happening a lot earlier in the process. And then you can quickly start getting into iterations faster. And that's where I think, you know, a lot of value starts being achieved by any project or cloud workload. Because the first shot that first MVC or that first thing that you build on cloud, it quickly disappears. Like you arrive, you build it, and then you realize, oh, wow, I didn't know what I didn't know. And then all of a sudden you start iterating faster and more and more. And then you realize, wow, I've completely crushed my design or optimized my product or introduced these new capabilities in a way I never thought possible. And that's where I see a lot of value. Another side of it is a lot of, like I have a very sequential mind sometimes when it comes to thinking about building stuff or moving stuff onto to cloud. This, you know, GitLab really does a really great job for developers to really experiment. So you can say, look, I have this application on premise or I have this application somewhere. I ultimately want to move that application to, I don't know where, right? I want to move it to some service, some other service, or perhaps I want to pick and choose across services. And so with GitLab, you can parallel all of that experimentation in a way that's pretty exciting. You can say, I want to, you know, decide if my job application is going to be a cloud function or another instance in cloud. And you can try it. And remember, innovation isn't the only constraint. Sometimes it's budgetary. Sometimes it's the constraint is time. And sometimes you need to move something really quickly to a place that isn't ideal. And by optimizing or parallel or making the sort of migration target parallel allows you to sort of, again, experiment with all these different services to find the best approach. And so I have a bit of a demo and I'm going to go through it with you. But before I do, I just want to say that there's maybe four personas that I'm going to reference over and over in my demo. There's going to be business leaders, data engineers, which sort of manage insights. There's going to be developers and there's going to be operations people that are focused on security and sort of risk. I'm going to take a moment and go through another slide here and show you the tools that I'm going to use. So in my presentation, I'm going to, or sorry, my demo, I'm going to show you Kubernetes and Cloud Run. I'm going to show you how easy it is to integrate with Cloud Run. Again, sort of going back to the beginning of my presentation, there's a pretty cool scaling story on Cloud Run where all of a sudden now I can develop something quite easily and scale it pretty significantly in a very short order. And Terraform is another key element. So Terraform and Helm, so in 14.0 or 14.1, I believe they released Terraform registry and a Helm registry, which allows for a lot of really great sort of management of Terraform within GitLab natively. Yeah, so just bear with me one second and I'm going to start my demo. Okay, so I'm right now in the GitLab console and I'm going to take you to my top level group. And the one thing I want to show you here is that I have three, again, personas. So I have an operations team, I have a data management team filled with data engineers, and I'm an application development team. And in this, each of these subgroups, I've actually defined a few projects. And so the projects that I have set up are AutoDevOps, Cloud Run, you know, I also have an operations cloud foundation, and I have a nice cloud functions project just here. And so the one few things I want to show you is that in this cloud foundation, I actually deployed a lot of Terraform. And with that Terraform, I actually used a lot of the tools or integrations that are native to GitLab. And so we actually have a Terraform state service, I guess, where I can save state. And so if I use Terraform to deploy a ton of infrastructure, well, I can't deploy it again because if I don't save the state, it'll just fail because it'll realize that those resources with the same names are already there. And there's also other ones, like they just actually released a Terraform registry, package registry. There's also a Helm registry now, which just helps you optimize how you're consuming these packages for your coding, basically. So going into it, I would say the Terraform itself is pretty straightforward, like I go in and I enable a bunch of APIs. I, you know, use the GitLab provider. I also use the Google provider for Terraform. I deploy, I enable a bunch of APIs, so I enabled the GKE API, the Cloud Run API, Cloud Functions. And then I deploy some networking. So, you know, I have like an ingress controller that, you know, like I set up a VPC, which has an ingress controller. Just going to the cloud console quickly. So if I go here and I show you my project, then it actually deployed my cluster, hopefully. Let's see. There it is. And then going into it, you'll see that I actually have some stuff. So I have my runners, I have Prometheus, I have an ingress controller. It deployed a Cloud Run instance for me via Terraform. I also deployed Cloud Functions via Terraform. And so if you look a bit closer, I actually have some stuff I had to set up outside of GKE specifically. So I was going to collapse this here. And so I had to set up a VPC. And I also had to set up an external IP address in order for me to access it. So going back to GitLab, if you look closely, I actually set up all of this through Terraform. But then specifically, I connected it up to my group. So that parent level group, like it's like two levels up, is actually integrated into that cluster. And so if I go in and I take a look around, I actually own this domain. And so I set up an A record with a wild card scope to this domain. So that way any time I go to that external IP address of Google Cloud, I then can access things. And so it maps it specifically to that domain. I also have Prometheus integration, which for some reason isn't enabled. So let's try it. Why not? And then there's a few other integrations, but those are the ones I picked. And if I was to go back down, I could see some cool stuff. So in here, I think, oh, I actually have runners that are shared throughout the group. So if I was to go and show you the runners really quickly, you'll see here that I actually have a runner that is on my cluster. This is all on GitLab.com. So it's not my self-managed or anything like that. This is just on GitLab.com. And so I actually have an AutoDevOps project here. So AutoDevOps is enabled. And just to confirm that I have my Kubernetes setup here, I do. And it's at the group level. My integrations are on. So I could actually go in and take a look at some stuff. So there's integrations here that are pretty cool. I have this one that's surrounding monitoring. Oh, wait, it moved me out of my project. Oh, there it is. So let's see if it worked. Is it pulling data? Oh, maybe because I don't have any environments yet or any builds. But let's see. I'm just going to pause this really quick. All right, I'm back. And so to finish my pipeline, it did a bunch of scanning. These are auto-generated from AutoDevOps. This is actually a template that I downloaded from GitLab.com, which has AutoDevOps enabled. It's just an express application with a Docker file and whatnot. But yeah, it went through and it sort of connected. And so now I can go in and take a look around. And I think it has built-in sort of telemetry, yeah, that comes in from Prometheus, sort of built in. And then the other dimension is there's all these other features around how I manage environments. So if I have, say, 12 developers all located in this project, I can actually build an environment for each one and go in and it creates this namespace in Kubernetes, which allows me to build however I like. And that's just the tip of the iceberg for AutoDevOps. There's a lot of integrations into Kubernetes that are super compelling. And so even though it's connected to one cluster, remember, this is a pipeline. And so I can collaborate quite effectively on Kubernetes. And then if I decided to deploy, say, a global-scale application to clusters all over the planet, well, that can go through another pipeline or another subsequent project. And so here I did the same thing with Cloud Run. Like, I can deploy this. It actually uses a lot of environment variables. All I'm doing is running a bunch of GCloud commands. And I've created into Cloud Run. And here is the same service that I just deployed located here. It has this GILab 14.1. This is exactly what's in this file, right? So where things get really interesting is you can actually build templates. And so I could go in and take exactly what I've done. I can create a template. And every single time I run this, I can pass an environment variable, which can then customize the name of that directly, I even think. Yeah, so we can call this, you know, happy day. And when I run this pipeline, let's pause real quick. Okay, my pipeline completed and looks like it deployed. So you should see here my new deployment called happy day. And this is deployed from an environment variable that I use to deploy Cloud Run. So I could create an infinite amount of projects, but also tie them to an infinite amount of services because of the way we manage environment variables in GILab. And so again, just scratching the surface, but if you start thinking about all the different products on Google Cloud and how they all operate, like Google Cloud has a Cloud Foundation toolkit all written in Terraform, managed and kept up to date by Google Cloud. With our Terraform integrations, it actually has a very compelling story for how we manage sort of the infrastructure, networking, security elements of Cloud. Data management is the same thing. We can control a lot around how we move data around, how we classify it. And also with how we develop applications. So if I just want to go out and create a simple, you know, one container pod solution, I can do that with a Cloud Run template. But if I want something that's a little bit more collaborative and tightly integrated into GILab, I can use an auto DevOps enabled project. And I can create all different kinds. I can create templates and I can organize all the security around how we manage change, how we deploy to production and how we sort of manage, you know, all of this work through the one sort of painting class. It's a very compelling story for how we manage Google Cloud. It really tames that complexity in a way that I personally find exciting. And I hope you found this talk very useful. Thank you for your time.