 I need my little dongle here to get connected with my MacBook with no HDMI, but that's okay. All right, let's see number three or four, sorry. And sweet, all right. Okay, so I am a developer, and I have an application that I want to deploy out to production, and that application has some infrastructure it needs as well, it needs a Postgres database. So right now, I don't have any Postgres, I've got no database, I've got no infrastructure, and let me make this a little bit bigger here. I've got no application either, so I've got no app, I've got no infrastructure. Let's fix that, let's do something about that. So I'm going to go ahead and I'm going to kick this all off by pushing a commit to my project that's hosted on GitLab. And so the first thing we should see here is that on my project to GitLab, just like you saw Eddie do, the GitLab Auto DevOps pipeline is going to kick off, and so I wanted to get that started because we're bringing up live infrastructure here, and it takes a few minutes, so I wanted to go ahead and at least get that started, and now we can take a step back, and we can talk about what we're going to do and what we're looking at here. So as Sid introduced earlier for us, the multi-cloud maturity model, now we're kind of moving through those phases there of the further you get along to being able to adopt and use a multi-cloud strategy. We saw workload portability from Eddie, and then now we also are going to look at application portability here in this demo, where as a developer with my application, I don't really want to get too worried about the environment it's going to run in or what cloud provider, what services it needs, et cetera. I want to focus on writing my app and the code and the business logic, et cetera, and I don't want to get bogged down in those details about the infrastructure. So a couple things here that make that a lot easier is first the GitLab's auto DevOps pipeline, which if we take a look at our repo here, we can see that it's not that big. We have our main.go file, that's my production application, the go lang logic for it, go my favorite language, and then we have a docker file which talks about how to build and package the application into a container so we can deploy it to Kubernetes, but there's not really anything in here about how to run the pipelines, how to handle errors, how to execute tests, all that sort of stuff. GitLab's auto DevOps just kind of figures that out for us, how to build and test and deploy, and there's a little bit of input I can put into it, because if you recall, as this application developer here, I wanted to have Postgres, right? For my infrastructure and my production environment, my app needs to talk to Postgres, so I'm going to basically express that need for Postgres. My app needs Postgres, and I also, I want it to be a managed instance, like a managed service from a cloud provider that could be Amazon's RDS, that could be Google's Cloud SQL, it doesn't matter. As an app developer, I just want one please for my app. We'll get into a little bit more details in a second here about how we select what type of managed service for our Postgres we want, but let's take a little bit of a different look here now on the other side of the coin. So this whole time here, I have been playing the role of an application developer, right? I'm building my app, I want to put it in production. There is another side of the house here of the infrastructure owner, the DevOps people. They are the ones that are responsible for the infrastructure. They need to be able to keep costs down. They need to be able to make decisions about policy, security. They've got all that domain expertise and that knowledge about what it takes to get things out into our production environments, make sure they're secure and everything's happy. So I want to be able to make sure that the things that are running in my environments as the infrastructure owner are secure and they're not going to cost too much and all this sort of stuff, but I also don't want to be bothered by application owners having to come to me or file a service ticket or whatever saying that they need new infrastructure, they need new databases. I want to set these people up to be self-service so that they can get the infrastructure on demand when they need it without bothering me too much, but also make sure that it's not too expensive or anything either because I don't want them doing that. So as Eddie was showing here in our GitLab Auto DevOps scenario here, I have in my GitLab project, I too have a connected Kubernetes cluster that is serving as my production environment that this project and this code is going to be deployed out to. So I've got Ingress installed, I've got the GitLab Runner installed, and here we go, I also have Crossplane installed on this production environment as well. So we got to introduce Crossplane real briefly before I mentioned it. So let's talk a little bit more about what Crossplane is. So Crossplane is an open source, multi-cloud control plane, and we open sourced it just before KubeCon last year in Seattle. So it's been going for about a year now, but the super fresh news is that it's now available, integrated into GitLab and GitLab's Auto DevOps, where it's a GitLab managed app. So if you want to be using GitLab CI CD stuff and you want to be deploying to production, you can now also use Crossplane as a multi-cloud control plane to provision your infrastructure to schedule and deploy your applications out to those different environments that you have and do that in a way that's cloud agnostic to have application portability in our multi-cloud maturity model to be able to enable that and be able to deploy your applications across multiple clouds now. And so that's super fresh as in it was merged into master in GitLab yesterday, so this stuff is less than 24 hours old. And I'm getting the... I have a habit of at KubeCon, so when I demo, I don't ever demo anything that's older than 24 hours, so I like to live by the seat of my pants basically, and it's always really exciting. All right, so one more thing to tie it all together here. We know as the infrastructure owner, I've got my autodevops pipeline stuff, I've got my production environment, I've been able to get lab-managed apps such as Crossplane to provision resources for the developers that when they need infrastructure, and these are my cheat sheets here, you're not supposed to be able to read this, don't worry about that, okay? So this is the thing that ties that all together. So an application developer, they want Postgres. They don't know if that's going to be Amazon RDS or if that's going to be Azure's Postgres instance or if it's going to be Google's Cloud SQL, but they just ask for Postgres. Now as the infrastructure owner, I want to make sure that they're not using some wacky configuration, but it's not secure or it's super big crazy instance, it's going to cost us a lot of money, so what I've done as the infrastructure owner is enable a number of set classes of service where I have a standard service for Postgres, I've got a high performance, high IOPS, a micro instance, whatever it may be, but I as the infrastructure owner have defined these classes of service so that the application developers, they can self-service, they can get their infrastructure and their databases when they need it, but it's going to be the type that I'm okay with in my environment. So for instance, this machine tier here, this region using this VPC, this version of Postgres, et cetera. So that's what ties the application developer's request for Postgres to a specific Cloud SQL on RDS with a specific class of service. All right, so that ties everything together, so let's look at this thing now. So if we go back to the pipeline that I kicked off, remember at the very beginning I kicked off, I pushed a commit to my production environment to get a new, an update to my software there. I didn't have Postgres and I did not have an application, but the pipeline has completed now, so that should mean that if I refresh, we should have a dynamically provisioned Postgres database that is up and running, sweet, which is there, and we should also have a application that's been deployed as well. Sweet, yep, the application's up and running too. So one more thing here to show you before we do more stuff is that, let me make that bigger or clear. So this, I know it's all jumbled on the screen here, but I'll point at some things here. So let's tie this together here. Application owner requested Postgres, and that was bound through a resource class, just like storage classes in Kubernetes, to a particular type of Postgres that is a Cloud SQL instance running inside of Google. So we have that up and running, our application's doing stuff. Let's take a quick look and see what the application's doing, because, oops, wrong one, let's look at the logs of the application. So yeah, so it's doing stuff, it's doing important production work, and we'll talk about what it's doing in just a second, but here's what I want to do next. You know, I have my application running, it's got its infrastructure, I want to do something new with it. I want to go ahead and update my production instance, right? So let's say version two in a log statement here, and let's go ahead and commit that. Okay, version two of my application, and let's go ahead and push it to my GitLab project, and with that push of my application, we should see another pipeline of GitLab auto DevOps pipeline get kicked off in response to that new commit. Okay, great, that's running, and so now that that's running, it's going to go through the same steps that it did before to initially get everything up off the ground, the infrastructure, and the application. It's going to build the container, it's going to run tests, and if the tests are okay, it'll go ahead and deploy it out to production. So an important part here, though, is that if you recall, we didn't have an application, and we didn't have a database. Now we do. If we're pushing another new version of our application, we want to honor that database, right? We want to just wipe it out, right? We want to make sure that it's okay there. So let's talk about what the application is doing. As I said, it is a very important production piece of infrastructure, sorry, application, and it's doing important production work. So the production, when we first ran this, the Postgres database came up, it didn't have any tables in it, so we created a table, and then we started inserting records into the database, just get a one, two, three, four, inserting in records, doing our workload here. As I said, the production workload, it's inserting integers into a database. Super important. So now that it's doing that, what we should see here is that the autodevops pipeline is running. We've got all this data persisted into the database, and as the autodevops pipeline runs, it's going to recycle, or sorry, update the container with a brand new version of our application. So if we do a get pod on that, we should see that the brand new one is running for the last 12 seconds, and if we look at the logs of it, we should see that it picked up right where it left off with its important production workload of inserting in records into that database. So we kept the data persisted and we updated the application there. So now to tie all this together here to summarize everything. As the application developer here, I needed to put my application out into production. I needed to get infrastructure for it as well, but I didn't want to deal with any of the details. I want application portability in our multi-cloud maturity model where I don't have to worry about what environment it's going to run in. It could be Google Cloud SQL, or it could be Amazon, it could be Azure, it could be Alibaba, it doesn't matter. As an application owner, I want application portability and not have to worry about that. But then as the infrastructure owner, they want to make sure that people are getting self-service, so the application developer needs infrastructure and they'll get it, but it's going to be a particular class as a service that I'm okay with running in my environment. And that's all done in an application portable way so that it'll work on any cloud. And then we put all that together with GetLab Auto DevOps, with Crossplane, our multi-cloud maturity model, et cetera. And what we're seeing here is that we've enabled a multi-cloud continuous deployment story finally. So I think that's really cool. So thank you very much, I appreciate it.