Hey everyone, how are you doing? I'm Robert a solutions architect from AWS, and today I have a talk for you called stop configuring infrastructure and start co it. Now, a better title for that talk could also be how coding infrastructure helped me to deal with my yaml phobia. So what do I mean with that? Let me pedal back for a second here. How did it all start? Well, if you've been present in the dark ages of infrastructure provisioning, you did a lot of stuff manually. You had wikis, you had playbooks, and you had this one person who knew everything. Then you started to script everything. You started writing a lot of bash scripts that did things most of the time, unless they didn't, and you were back to square one. After that we got a revolution, and that was declaring infrastructure and its configuration declaratively with things like cloudformation or terraform. And that was also already pretty good. And this is where my story starts, because for me it wasn't good enough. So let me explain. Like two years back I was looking at a new role as an architect, and I knew AWS is the focus. So I've worked with AWS before and I did infrastructure as code, of course. But I was figuring out, well, in my new role I will do it all the time. So I need to get deeper into it and see how it feels, because I think I will do it like basically every day. So I did a very simple thing. I said, let's build a small example application because infrastructure AWS code is easy, right? Can't be that hard. All I want to do is I want to connect to the Internet, I want to have a load balancer, and if I query that load balancer from the outside, I want the request to go to a number of EC, two instances, so a number of vms, and of course I want to build a well architected application. So it should be resilient, so it shouldn't be just one easy to instance, it should be multiple. So I need an auto scaling group. So looks pretty simple, right? Well, I was mildly annoyed to scared to see that when I wrote this in cloudformation, which is the native infrastructure as code language for Aws. Yeah, I had a fully declarative template at the end. I had hit and miss ide support for filling out all these values, having the right fields and so on. But the thing that stuck out to me most was that I had to write over 300 lines of yaml. Why was that? I was kind of stupefied here. Well, if we zoom into that architecture. It's actually not that easy what things are, right? So of course you have the load balancer and you have your auto scaling group, but you also need to have a VPC, which is the virtual private cloud, the private network that you are building in the cloud where all these things will be deployed into. And the problems don't stop there. Actually, these are the big players, the big parts that you see in your nice infrastructure diagram. But actually these things need a lot of additional objects that have to be configured. And these are all somehow related to the big resource, to the main resource or to the others. So the VPC, it's not just, hey, give me a network and you're done. You have to think about subnets, you have to think about connectivity, you have to think about routing. And for the load balancer, it's not just a load balancer, you have to think about its security group, which is basically its built in firewall that says which ports you can connect to and which ones not. And then you have to tell it what is the target when an incoming request is going through the load balancer. So then you're going to the auto scaling group. And that auto scaling group is also not just it, it's like, okay, you want to scale, how do you want to scale? What are we actually launching? I need a template. How do you set up the vms in that auto scaling group? And you need an IAC role that defines what these individual instances could do with other AWS services and so on and so on. So that's the reason why you come out with 300 lines of yaml. And honestly that was pretty scary to me. And yeah, it pulled me down a lot. That's basically where it all went downhill for me. And I started to drink a lot coffee. And then I talked to a colleague about that and mind you, this was somewhere around 2020. And he said, you know what, Robert, you are a web developer by trade. That's what I did before, right? I was a web developer, did javascript, typescript, node JS, all that stuff. I've heard of something new. I've heard of a way where you can actually take real general purpose programming languages and use those to model your infrastructure. And I said, really? That sounds like a dream. And he got closer and closer to me and he said, robert, what if I would tell you there's a world where before you were doing manual things and you had to be a lucky engineer, then you went on and you could do scripting, you had to be a bash engineer now you are provisioning your infrastructure declaratively, and you're a Yaml engineer and you hate it. What is the next step? What if you could use code and typical abstractions in code and become a software engineer? And that's what we're talking about today. So in the recent years a few new frameworks have come up that help you to abstract your infrastructure or to model your infrastructure with general purpose programming languages. Here we can see two widely known frameworks that do that. So one is from AWS, the cloud development kit, or CDK for short, and one is from Pulumi. Now for today, I want to dive deeper into the CDK, and I think it should be transferable if you're coding another framework, because a lot of the things I will talk about hold true for all of these, let's say new wave frameworks that are using programming languages. So what is the cloud development kit? Well, let me read it off here, because it's really a mouthful. It's an open source multilanguage software development framework, okay, for modeling cloud infrastructure years, that's what we want to do. AWS reusable components. So what are the main benefits I could gain by using the CDK or another framework that lets me use general purpose languages? Well, first of all, if I have any familiarity with a programming language, I'm probably able to use that language to now model my infrastructure instead of juggling with a yard of yaml. And you can see here at the bottom right, all the languages that are supported by CDK. So you can write in Python, in JavaScript, in typeScript, in Java, in c sharp, and also in Golang, which is currently in developer preview. You also get great tool support because basically every ide under the sun understands code, and it gives you things like autocomplete and inline documentation. Now the real fun starts with the abstraction. So you are getting classes, and those classes, as we will see in a minute, they can do a lot of smart stuff for you that then you don't have to figure out. And that's actually one of the superpowers of CDK and other frameworks like that. Finally, because you're now using code, it's easier for you to manage infrastructure and code together, or to put it differently, in a similar way. And that can be very helpful, especially for developers who might know a programming language very well, but might not like to be Yaml engineers like we are. So how does CDK actually work? And again, this is similar to how other frameworks work as well. So first of all on the left side, you're writing what we call a CDK application, and that's really an app in the language of your choice. In that application you create so called stacks, and those stacks would represent everything you need around a part of your application, or maybe even the whole application. And within that stack you are creating so called constructs. And these constructs are classes that are actually representing your infrastructure. For example, if you were to use it on AWS, you want to create an object store, which is an s three bucket, and then you would have a class you instantiate for that s three bucket and it would represent that resource. Now once you've written that, you are actually going to the CDK CLI which you have installed on your pc, then, and you would ask it to synthesize the stack. So then the CLI will execute your application and as an output it will create a cloudformation template, which is the native infrastructure AWS code language we have at AWS. And then it will go forth and take that template and ask the AWS cloudformation service to deploy it. And then your resources are actually created. So that's definitely a paradigm shift where before you were writing templates and you would then ask cloud formation or possibly another runtime on your pc to actually deploy the resources. Now you would write an app in the language of your choice, and this app in the language of your choice would then be translated, transpiled, compiled, however you want to call it, synthesized into the infrastructure as code template, and this is then deployed. So it is basically one step more. But from your point of view you are just interacting with the code at the very left. Now basically back to my problem. I was writing a lot of yaml and it drove me crazy basically. So how does CDK help me here? I mean, I have to write code, right? So what's the benefit here? And that's where the so called constructs come. And these are the classes that represent your resources. Now with CDK we are basically separating them in multiple layers. So on layer one we have the automatically generated classes which are just a one to one representation of the infrastructure as code template resources you had before when you were using cloudformation. Now the second level is where it gets interesting. So these are high level representation of AWS services, which have a lot of smarts built into them. So when you use those you get same defaults and best practices out of the box. And in a minute we will look at an example of how that works. On the third layer we have the purpose built constructs. And these are opinionated abstractions that are basically whole architectures. And this is really great because with those you can really look like an infrastructure visit without the 60 years of experience that might be required in the job description because these are basically covering whole architectures. For example, it could be basically what I have built AWS, one class that does all the things, creates the load balancer, creates the auto scaling group, wires everything together. So you get a lot of stuff out of the box here. Now for this abstraction and those same defaults that I just talked about, let's have a concrete example for how that works. So now basically what I've built with cloudformation before, we are now doing this with CDK. So you see some snippets from my code editor here. So let's say I've initialized my CDK project and now I'm starting to write the code. The first thing I do is I create the VPC and as I'm typing this you can already see that I get really nice code completion and also inline documentation for what this thing already does. So that's great. Now if we read the whole text a little bit more you would actually see that this is a level two construct. And as I said, it has a lot of smarts built in and it does a lot of great things for you already. Here's the full bullet list for that. The full bucket list, so to say. So I will not read everything that is here, but basically the gist is it does basically everything. You would want to have a same default well architected VPC already created in your account. And just to give you some ideas of what it does, it not just creates the VPC, it also creates subnets, it creates private and public subnets. It thinks about all the routing, it thinks about Internet connectivity and it tries to be resilient because it does all of that while at least setting it up. So it's highly available over two availability zones, which is also great. So with one lighter of code we did all of that, which is already mind blowing for me. And it still is. It was at that time and it still is. So let's go on. For the next part we are actually creating the auto scaling group. So that is the group of instances that can even scale, hence the name and represent my web servers. So again I'm starting to create to instantiate a class called auto scaling group here. And this time I need to provide some more properties, some more arguments for creating that. So I have to pass the VPC obviously, but I also need to define what instance type do I want to use. And here what's great for me is that this is actually based on types and enums or however you want to call them. So these are defined values that you find in the code in the classes provided, so you don't have to look it up in the Internet and maybe make a typo and then it doesn't work. You can easily fetch those in your editor, get autocompletion again and basically choose the right type without any issues. Then we have to set a few more variables here, a few more arguments like what machine image, what VM image we want to use. And we can also say in which subnets this auto scaling group should operate. And there we are referencing the VPC that we have created before. So that's super cool. Basically it's very familiar for a software developer to set this up. Now we're already at step three and that is configuring the load balancer. So again we are instantiating a class called application load balancer. We give it some settings and then we use some cool convenience functions. So there is for example a convenience function saying add listener. And that means if I call this and give it a port, that's the port that is available on my load balancer when I try to connect to it. And after I did that, I use another convenience function called add targets. And in add targets I tell the load balancer that it should forward those requests to the auto scaling group that we have created before. And finally, I'm also configuring the security. So there is a neat convenience function that says allow default port from any IPV four. And that means that we will publish that port to the Internet and that all the security groups are actually configured correctly to let that traffic in. And now we're basically already done. Something I want to point out here, which I find is really cool, is that what we've done here is talking to me. I can understand that. Let me take a small segue here into clean code. This might be known by you. So there's this book, clean Code by Robert C. Martin. And that book is basically about how to write great code. And one of the pillars or the tenants that they have is that if you write clean code, it can be understood easily. And understanding something easily helps with actually enhancing it by someone who was not the original author. So it's really a success factor for collaborating, which I think is great. And if you think about what we've just saw with these convenience functions, we have a kind of story. We're adding our listener to the load balancer and we're adding the targets for the load balancer. So that for me is telling the story of this small picture we have down here. And that story is my load balancer shall receive traffic on port 80 and send it to my instances. Now this is something that a human can understand pretty well, but what's actually happening behind the scenes and what CDK is managing for you is all the creation and wiring of the multiple resources that are behind that. But that part is to some extent just complicated. It's busy work, you have to do it. And if you would read the cloudformation template for the right part, it's much harder to understand the original story that we have on the left. So that's something for me that is one of the game changers about CDK and similar frameworks, that you can really tell a story by code if you write good code. So let's have a look at how these two things compare. So on the left side in the ring, we have cloud formation, the default and native infrastructure definition language, basically representing the declarative class of things. It's fully declarative. IDe support varies on what you have, and it's rather verbose with 300 lines of code, or Yaml, to say that on the right side we have the contender. It's the CDK app. It has used abstraction via code, which did a lot of things for us. It definitely has some imperative aspects because we are writing in a real programming language. But we saw that we profit immensely from a lot of built in, sane defaults and best practices. And in total, I don't know if you counted, we created less than 30 lines of code, which is awesome. So that was the point for me where I was totally. Basically, my mind blew at that point. That this is possible with CDK is great. And again, it's not just down to the programming languages I can use, it's down to these built in, same defaults and best practices with other declarative languages. There are also modules you can put in to make it easier to abstract some of that away. But the cool thing is with CDK that's all included, you do not have to search for it. It's in the main library. And I think this is super powerful. And when I did that, I was so happy. I was jumping up and down in my seat. I was calling my wife, saying, hey darling, I did great things today. I did a lot of work with a new tool I have, and I did it super quickly, I was so efficient with that. And she said yeah, that's great darling. So you can come home from work earlier today and do the dishes. I kind of blew it there, but basically I'm really happy with that. And from there on I'm just using CDK for basically whenever I can to create and manage my infrastructure. Now we talked a lot about how we can do this with AWS, but I want to make clear that you understand that CDK is an open source framework and there are actually other variants of it that also deal with infrastructure that is not just AWS. So as you can see here, we have the AWS CDK. We have cdks which is a variant of CDK to provision resources in Kubernetes, and we have CDKTF which is CDK for terraform. So if you are already using terraform, you can also now write your terraform templates with CDK in a programming language of your choice. So the main message to take away here is CDK is not just for AWS, you can almost provision and manage anything with it. And where would you find all those things? Well, there's the construct hub, which is not only providing constructs for the AWS CDK, but as you can see here, four cdks and CDK for terraform. And you find this under constructs dev. So let me sum this up for you. Why should you code your infrastructure with CDK or similar frameworks? Well, first of all, you can leverage the developer experience you already have, and you can work with familiar programming languages. You can profit a great deal from IDE support with things like autocompletion and inline documentation. And as we've seen in my example, you can use powerful abstractions to build smarter, faster and more understandable. And in general you can bring code and infrastructure closer together. Now you might ask, why should I not do that? And that's a trick question because of course there's no reason not to do it. It's the bestest tool ever, obviously. Just kidding. Of course if you are more familiar with configuration tools like cloud formation or terraform, CDK might just not be your thing. Or if you're not too deep into coding or debugging stuff, because that happens from time to time, might also not be your cup of tea. But the good thing here is you can actually use both. Why decide? For one, you can mix and match depending on your use case and your team environment. So maybe your infrastructure team that provides like the basic platform services that is still using terraform, but for a new application you are building. You are managing everything for that in CDK. Why not? We are wrapping up here. I hope I could get you excited for coding infrastructure instead of configuring it. If you want to try this out, for example with the AWS CDK, I can recommend the CDK workshop which you can find under cdkworkshop.com. And if you want to dive deeper, there are also resources out there to learn more about the CDK for terraform, the CDK for Kubernetes. As I said, you can find the construct hub under constructs Dev and you could also research CDK pipelines which is a cool way configuring infrastructure, coding and code and the pipeline closer together in basically one single code repository. Finally, because CDK is not just an AWS thing, but really a thing of a big growing open source community, I want to make you aware of the upcoming CDK day. And the CDK Day is a completely community organized event where all these things that you're seeing here, not just the AWS CDK but also for terraform, for Kubernetes, are discussed and celebrated. And actually this is coming up pretty soon at the end of May. So I would say check it out. I hope you liked my presentation. Feel free to find me on Twitter or LinkedIn and tell me if you did something cool with CDK in your next project. Take care.