 I do want to warn you all I've got 15 minutes. I'm going to talk really really fast and I've been on vacation for the last three and a half weeks. So I'm a little rusty. So I'm just going to warn you. So we are absolutely going to talk about infrastructure as code. So here's a little bit about me. My name is Sean O'Dell. I'm a developer advocate for VMware. I've been at VMware nine years, a little two separate stints. Here's some of my interest just so everybody knows. It's a level playing field. I love Texas barbecue. I smoke meats. By the way, I know I'm in California and I'm born and raised in Texas, but my favorite meat to smoke is fish, not beef. So don't judge me okay. Everybody's like beef. You know, no, I'm just kidding. I love to smoke veggies and desserts. I am a big fan of snowboarding video gaming. And yes, if you need any Disney World tips, let me know. I got three kids. I got a wife. We've done this way too many times. But we can do that afterwards. So a little bit about my team. We are a developer advocacy team at VMware solely focused on developers. I know somebody's like VMware developers. We're software company at the end of the day. I don't touch infrastructure except when it's infrastructure is code. Kind of quote me on that. Check us out. Cloud journey IO on Twitter. There's our website. We got lots of fun stuff out there talking anything from Kubernetes to deep in public cloud security as well as you name it. We got a lot out there. So give us a shot. Here's what we're going to talk about really today and why infrastructure is code and kind of the genesis of this 15-minute talk actually started at GitLab Commit in both London as well as in Brooklyn. So I've had the privilege to be at both Brooklyn and London and now San Francisco. I'm looking forward to where the next location is. So hopefully I can get another talk and have a little bit of fun there. So our team came up with something that we kind of really thought about and begin working with developers. What we call continuous verification. Now this is a single slide. I'm actually going to show this to you in GitLab in just a minute. But I do want to focus pretty much most of my talk on the infrastructure piece is just some of the things we've learned both from the Terraform side and obviously on the GitLab side. But this is actually a run job that we built that deploys our seven microservices based application. It's a polyglot app so it's got every language you can think of. But this is all of the pieces that we in the room typically care about because we want to be developing applications. Now within that framework we wanted to not only deploy the application but we wanted to make life easier for some of our... I'm a reformed infrastructure admin. Forgive me. Reformed. Notice I said that is when I need to deploy, when I need to build an application, when I want to provision an application, I have to go back to IT at some point in time or IT comes to me and says your application is not secure or your application is too expensive or why are you running these crazily over-the-top provision workloads. The things that we in the developer space really don't care about. And so what we wanted to do with continuous verification is include all of those components inside the build pipeline. So in this case our application is deploying all of the services. We're going to do a container vulnerability scan from within GitLab. We're actually going to do a budget check with some of our solutions that's Cloud Health. We're going to do a security solution check with our VMware secure state and then so on. In this case this is deployed on top of AKS. And then last but not least we want to do some traffic generation, all that fun stuff. This is the genesis of our talk in London as well as in Brooklyn. But for today's session I wanted to talk a little bit about the infrastructure piece. I know in many conversations I have with developers and so on nobody wants to really care or talk about infrastructure. We only care about what the applications that we're building, how we're impacting the business by creating net new applications as quickly as possible. So here's the live example within GitLab of our repo and some of the jobs that we've been running. But when we go to the infrastructure piece, I own the infrastructure creation for all of our demonstration applications. So I've got Terraform everywhere. I've got some Terraform for Azure, for AWS, for Google, it varies. And so when we initially started we were like, hey, let's just go ahead and use some of the infrastructure that we already have provisioned and built. Makes sense. It's okay. And then the crazy idea I had was why don't I build the infrastructure as well as the application all within the same job? Now, I cannot do that in 15 minutes. This is not going to happen. Unfortunately, AKS takes about 12 minutes for me to provision a Kubernetes cluster. Obviously I have to spin up the application, all that good stuff. So I'm not going to do that today. Maybe that will be for another day and time. But I do want to highlight a little bit of kind of the beginning stages of that. So in my environment, I'm going to jump in here to just a very simple quick repo that I have. I'm not boiling the ocean here. Every example that I use, in most cases, you can find on the Internet in any form, whether it's from Hashi or from Microsoft or from Google or from Amazon, they own their providers. And so in this case, I took an example from Microsoft from an Azure perspective. And you can see here I've got the basis for my Kubernetes build. And so let me make sure this is big enough. There we go. And I'll look at this as well in VS Code in just a second. But there's nothing crazy to this. I think most of us are familiar with the infrastructure pieces. I'm building every, from soup to nuts, the entire infrastructure from a Kubernetes perspective. I'm not changing anything from my environment, but I'm obviously setting some sizes, etc. Now in the case of, from a Terraform perspective, so that's obviously the GitLab view. I think we're all familiar with it. I have gone ahead and set a few variables within Terraform. Now I'm using Terraform Cloud for this example. You can use John Shulman, one of my old peers. He works at Hashi. He's here up front. He'll give you the entire spiel on what we can do with Hashi and Terraform. But in this case, I'm using the Terraform Cloud. It's available free up to five users, which I kind of like. And so I'm actually providing the necessary variables for me to create the Kubernetes infrastructure within Azure. So I've got my client ID, I got my client secrets. This is one of the nice things for me that I have found within Terraform Cloud is the ability to set these variables. Obviously, I have my TFRs if I wanted to go that route. But I can actually set them here from a workspace perspective. And then ultimately, that could apply to multiple infrastructure provisioning aspects if I want to go down that route within Terraform. But in this case, it's just a single, a singular view. Now I have also set up within Terraform Cloud. I've actually set up GitLab. It's one of my providers. So I have a couple of providers in here. But this is my VCS provider in this example, GitLab. So hopefully there's nothing off ID token. I better hide that or change it after this. It's not that important. It's okay. If you have it, that's fine with me. I delete it all the time after I do demos. So here's my environment that obviously I showed you what it looked like in GitLab. I showed you some of the variable applications within Terraform Cloud. This is what it looks like from a VS code perspective. This is nothing new or extraordinary from a Terraform perspective. The one thing I want to point out, though, is in our scenario, and there's no way I was going to be able to demo all of this in 15 minutes, is if I'm taking an infrastructure build, and in this case, it's Kubernetes, I then have to set up the provider or the Kubernetes instance within GitLab. I'm going to make API calls. I wasn't going to go too far into that. We don't have a lot of time. But I'm creating API or I'm calling necessary APIs to take my Kubernetes cluster information, plug it into GitLab, make it accessible and available within the pipeline. And then ultimately to go back to my scenario of continuous verification, there are a few things that I found valuable within this process is rather than manually inputting some information into a performance monitoring solution or into a cost management or analysis solution, I was able to, from within Terraform Cloud, within that TF state, I know the name of the Kubernetes cluster. I have all of the necessary information within that state file. I could then programmatically within the same build actually set up my performance management solution. Obviously, we own Wavefront. If you're using Wavefront, if you're using Datadog or Prometheus and so on, if you want to take the name of that Kubernetes cluster or some value that you have within TF state and obviously make that call, you can programmatically do it. Within GitLab, really the runner's functionality within GitLab is actually fantastic. We've gone pretty far on that path. Just be careful, I guess more of a tip and trick as you go down this path, is what are you building? What do you need it for? Why are you using it? And simplify your entire build. I always say this when I talk about this specific subject. Every organization does it differently, 100%. You may want to do certain things that my organization may want, may not, and there is no right way to do it. But what I always try to stress is learn from your peers. How are they doing it? Some organizations, even within VMware, they separate the infrastructure pieces or the infrastructure is code from the application code. That's fine. I have no preference. It's up to you. This is kind of a quick example of what it would look like from that perspective. I am going to run this real quick just to highlight kind of the usability. I do have some client IDs and secrets, that's fine. Everybody is like, why are you doing this? I can change it in two minutes. I do it all the time. Let me change this here if I'm still connected. Where are you? There we go. There is my client ID. There is my client secret. Ultimately, this will go out in provision. In this case, it was AKS. One thing I do want to call out while the Internet is having a good time here, let me jump back to, there we go. Yes, boom. If you have created anything in the last few minutes, congratulations using my information. You have it. You know how my subscription ID, it's okay. One thing I do want to call out from a resources perspective is we did kind of the genesis of this talk. Obviously, I'm just talking about the infrastructure pieces, but I'm going to put a link up here in just a minute for the broader talk that we did at Brooklyn, which was talking about the application pieces and not the infrastructure is code. I will be here all afternoon or really the rest of the day to kind of talk. Let's talk infrastructure as code. I was struggling to figure out how to do infrastructure as code in a 15-minute talk, so I figured I would up level it right rather than get totally down in the weeds and have 100 lines of code and kind of run through that in 15 minutes. But here's a few things of importance. Find me on Twitter. Our team is Cloud Journey I.O. We're extremely open and willing to talk to you. VMware has kind of gone through a lot of a transition. We made the acquisition of Pivotal last week or I guess a couple of weeks ago now. So we're doing a lot of movement, especially developer advocacy team. There is a link within the deck to the talk at Brooklyn. That is the kind of a smaller version from one of my peers, Tim Davis, talking about the cost analysis piece. And then that second one is myself and my boss. We did the missing link, which is kind of the broader talk for continuous verification, as well as a few additional pieces. So go ahead and check that out there. The last thing I'll mention, I know in this case, obviously I'm talking about Terraform. You can use other providers, right? If you're a Pulumi shop, go for it. If you have other ones, if you're doing it manually, congratulations. Not really. But let's have a conversation, open dialogue today, and I'll be here as well. I do want to appreciate it. It's a nice quick short talk. Just want to kind of set the appetite, what your appetite, and give you a little bit of an idea of maybe where you can go or where you should go from an infrastructure as code perspective, and then kind of where it fits in more importantly, in my opinion, into the broader lifecycle of application development. And so with that, I'll say much appreciated. Come talk to me about barbecue, about Disney World, whatever you want. I'll be here as well. And thank you and have a great day.