Check out a free preview of the full Build Go Apps That Scale on AWS course

The "AWS & CDK Setup" Lesson is part of the full, Build Go Apps That Scale on AWS course featured in this preview video. Here's what you'd learn in this lesson:

Melkey introduces AWS and the Could Development Kit (CDK). AWS will host the application, and the CDK will allow the AWS infrastructure to be set up with code rather than through the AWS interface. Installation instructions are reviewed. The AWS CLI and CDK setup instructions are in the course repo README.


Transcript from the "AWS & CDK Setup" Lesson

>> AWS. We finished the first, module and the second module go again, I think it was a little bit more intro, that was by design, and I didn't go into like every concept of go like we just mentioned. I mentioned interface a few times, we didn't go into detail of it, because, I think some things are better shown with like an example.

And so when we go through building our software with AWS, we're gonna actually write and use interfaces more in-depth. But, that was go, let's switch gears to AWS. So, if you don't know what AWS is, if you've never used it, AWS stands for Amazon Web Services and it's a cloud provider, that's kind of the gist of it.

And cloud provider does is it offers fully featured services to consumers. These fully featured services, there's, I'm not even joking, like so many, it says 200, I'm pretty sure there's more I've never counted. But it's anything from databases, computing engines, networking, storage options, machine learning capabilities. I mean literally anything you could want, either AWS has a version of it or they somehow got propriety access to make it into their cloud providing systems, okay?

And why did I choose AWS for this course, why go in AWS, why not go in Azure or something else?. And I really find it important to have a course that has the most practical benefit to person taking it, and I'm sure everyone will take away. If it was Azure, but it'll take away concepts Azure and that's gonna be helpful but from a job perspective, AWS has the biggest market share.

And this is a stat from, last quarter, Amazon owns 31% of the market share, so it's a substantial portion, almost one third of of all cloud providing, functionality with Azure coming in second. And then you have Google Cloud, GCP, Alibaba Cloud, Salesforce, IBM cloud, Oracle, Tencent Cloud and then a bunch of other smaller components that maybe have like half a percent market share percent market share.

And so AWS is known to be king, it has the biggest availability and this translates to typically more jobs available for companies looking for an AWS engineer. You see a lot of companies facilitate like if you complete my AWS course you'll get a certificate or even AWS offers his native certificate courses.

And these have a lot of substance when applying to stuff, right? So for me, like AWS makes a lot of sense because I think goes practical. I just think AWS, if anything is more practical in terms of software engineering developing because it's not bounded to one language. It's bounded to more, what do you want to build with it?

And basically, it enables businesses and developers to run virtually everything in the cloud. And again, the 200 fully featured services, like this is queuing systems, this is like Kafka real-time systems, machine learning endpoints with Sage maker, you can have relational databases with RDS. You can have non-SQL databases with DynamoDB.

You can have, literally everything, you can have server-based architecture, serverless-based architecture. The list goes on and on, and I don't wanna bore you with all those possibilities that AWS offers. But AWS and the AWS is used extensively with CDK or it can be used extensively with CDK. And I kind of want to actually break this for a second to go and show you AWS.

If you've never seen AWS or the console, this is the UI. This is like AWS, I've logged into my account, you can see here Mockito has hello. And you can see a list of recently visited services, right? You have CloudFormation, DB, CodeBuild, CodePipeline, Gateway, whatever. It's just some of the port services it has offered, and you can go to services, you can check them all out, okay?

And if I wanna spin something up, a piece of infrastructure, like AWS offers, let's say we go through an S3 bucket, an S3 bucket, just blob storage, you can store anything in here. It could be CSV files, it could be images, let's just say we want to make a new bucket.

I can go ahead and create a bucket here, I can follow this really nicely designed system to create my bucket. And that's fine, that works nothing's wrong with that, maybe. Because that is where CDK comes into play, in CDK, framework built by AWS, which allows us to define our infrastructure as code.

So it eliminates that portion of where I go in the UI, I click a button, type a few parameters, click Create, and to an extent, that's fine. Like creating an S3 bucket, no one's going to lose sleep. Kratom on the UI, whatever they're like, up down time is pretty easy, you can destroy them in less time they make them.

But when we deal with heavier infrastructure now I'm talking like redshift clusters, you don't wanna mess that up. Because the uptime to make a redshift cluster takes some time, and then if you mess it up, if you configure it improperly, or whatever, destroying it is also a time consuming task.

So you're taking time away from your iterative speed when you do it like that. And infrastructure's code is something that allows us to provision and write a code and in deploy all that to AWS CloudFormation. AWS CloudFormation is a service on AWS, which basically uses flat file templates to provision what service do you need on AWS?

It's kind of like this channel where we write our code using CDK, we deploy that, and then deploy to CloudFormation, and CloudFormation is able to then transform that code into these JSON or YAML files. These template files essentially, which then communicate to the rest of the AWS suite.

This individual needs a cluster, a bucket, a lambda, etc, with these configurations, I'm gonna deploy for them. And that is all existing in CloudFormation as our source of truth when we use CDK, okay? And yeah, we'll go into detail of infrastructure's code if this is kind of your first time hearing it, like hearing that term.

But yeah, essentially it allows us to spin up light or heavy-duty infrastructure services to the cloud without actually interacting with the AWS UI. And here, what is Infrastructure as code? So it's a key concept in DevOps and in cloud computing practices, like I just mentioned, it automates any sort of management of infrastructure, so it replaces any manual processes.

And this is one really example that I kind of like, and let's say you, three months ago, deployed some infrastructure, let's use the redshift clusters example. You deploy it and you deploy it on the UI. So you configured it, you had to play around with this cat and mouse game like okay did I provision it to expensive, is my boss gonna yell at me because it's too expensive?

Does it do the right thing, can it scale? But let's say at the end of that process, you have this configuration for this cluster that does exactly what you need it to do. But in three months down the line, six months down the line, you get this new engineer.

He's like, hey, Melkey, I need to make the exact same cluster for our team, what did you do, where's the config set, can I see it? And of course, the user can go in the UI, they can see the settings, but that's pretty cumbersome, that could probably have a lot of.

If they copy something incorrectly, they may skip something, right? It's, it's not the best system and it's prone to errors. But what's not prone to errors and what's something you can just like safely reference is like the code that you use that's now been battle tested and this is where infrastructure's code comes into place.

You basically define all the infrastructure you need, all the configurations you need, any sort of properties using code. This is just like writing a function, all the functions we wrote, changing the name name of a property, you can have that for CDK. And it's defining code using declarative files and allows infrastructure to be versioned, shared or reused.

So CDK is kind of this breaker of like a DR, like driver principle. You can define one construct, one piece of infrastructure, and you can reuse that if you make into a function into other piece of our application, right? So as long as you have this one definition, and you are able to make that into a function, you can just keep calling that function, or you can just copy and paste it and define it right into your stack.

So again, it's however you want to write your code. But why does this actually matter? And it's because when you run applications in different environments, like development, testing and production, these are very drastic things to deploy your code on. Your testing sandbox shouldn't be the most up-to-date version of the production environment.

Your testing sandbox should be able to handle specific testing scenarios, specific maybe burst of load testing. But to have the provision as if it is your full production environment, maybe that's costly, maybe that's just not efficient. So that's why we want to be able to separate these environments and separate them using code, and when we deploy it, we'll have more security of how and what is deployed in terms of infrastructure.

And it's used a lot in cloud environments, so again, CDK's native to AWS, but there's a native version for GCP, a native version for Azure. I don't know them I actually being truthful, I haven't used them, I just know CDK. And you can also define your infrastructure using TerraForm, has anyone like used Terraform to deploy infra here?

Yeah, so you can use Terraform as well, it's just kinda a different flavor CDK, like I said before it's the way I like to break it down as like it's deploying infrastructure in a functional way. Writing functions that get deployed. And then why AWS and CDK? So like I said, the biggest market share has AWS, so I think it's gonna be really good for jobs.

I think if you apply with more knowledge of AWS, I think it makes you more of a hot commodity, if you will, on an engineering team. And the next point is it's, it's mainstream in a sense that a lot of popular companies like Versal use AWS under the hood.

So lots of these companies are coming up, use a lot of the AWS services or infrastructure to make them successful, right? Cuz they recognize what they can do with AWS, and also another interesting example like barcode scanning or any kinda application. You go to a restaurant and you scan the QR code for a menu, that's probably using AWS as well, right?

You can actually see when it renders the page, there's like an S3 address, and that's obviously using AWS. And AWS has many different services, CDK allows us to communicate with their services, allows us to configure them, use them how we want. And then the practical example, maybe more specific to this course, is we can combine CDK with Go to create practical real-world applications, right?

So we're gonna write everything in Go and we can deploy the infrastructure that can, how is that code or what database you're going to interact with using Go with CDK. But everyone get a chance to set up their environments. So you have like your AWS account, you have a method to communicate with your AWS account from the CLI, CDK all configured, everyone kind of thumbs up.

Yeah, cool. And there's different ways to act like for setting up your permissions. Sorry setting up your permissions in AWS I have a resource up here let's see. Yeah, what is this? Okay, this is the CK1. So setting up the AWS CLI. There's a bunch of different methods for setting up your credential information, you can do short-term access, you can do long-term access.

It's not recommended to use long-term credentials with IM. I personally think for this kind of environment, this toyish example, this non-production example, I think is a better way to say it, you can use long-term credentials. It will be fine, obviously don't share them and if you've never set anything any of these app, you can actually set up to AWS.

Here and their is a service called IAM, and it's kind of funny joke where, if you wanna learn AWS, all you need to do IAM. But yeah here I have two users here, and we need to spend up some of this app you can give them different permissions, like root permission, or be granular.

Can this user interact with Redshift, or MWA, or all these other services, you have this granular control of the permission level with IAM. And then you basically spat out also these kind of access keys here on the right. There's an access key and a secret access key, don't share your secret access key at all.

I'm pretty sure it's like once you spin it up, you only have one time to copy that the JSON or save it as CSV, so you only get one time. So you copy those into your .aws credentials and that will set you up to communicate with AWS. And then last there is obviously, you can check this with AWS S3 LS, so if you run that command on your terminal right now.

If you have your list of buckets, it'll show them, if there's a permission issue, it'll pop it up, so try doing AWS S3 LS. And then there's the last command, the get caller identity, this will show you who's calling it. So what account did you set up, is it the right account, what permissions that account has?

Cool, and the last part is installing CDK. So it's like an NPM install, you can follow that link. I think I again have it open right here, getting sort of AWS CDK, so I think there's a bunch of different things that you can solve here. Yes, NPMG install type script, so there's different ways that you can, Install your CDK code and get it all provisioned.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now