Intro to Amazon Web Services Cloud Development Kit
Rivers Agile Lead Software Engineer, Jimi Tallon, examines the structure and background of Amazon’s new software development framework.
The goal of this blog article is to show how code and resources can be defined and deployed using AWS CDK. Starting with some general ideas of resources provide a baseline for a cloud infrastructure story that can be built-up over time. Everything is not needed at once. As more details are fine-tuned and come into play, it turns into a type of snowball effect. Also because general resources are defined when needed it becomes easier to pick and add more complexity to them making our “snowball” even bigger. CDK code can also be modified in one place and deployed into other environments just like standard code is deployed to environments like development, staging, and production. The alternative to CDK is to use the AWS Console (i.e., Amazon’s website based tool) which can become suboptimal overtime and creates potential issues. It all depends on complexity and level of effort. Some reasons why issues can occur is because manual steps may not be followed/created in the same order or conventions may be lost depending on who does the cloud work. Moreover, resources in the AWS cloud can be spun up in record times with a little practice and following ideal patterns and procedures in CDK land.
The article is broken down into two parts: the first is defining some structure and background to our project and the second part will start to introduce the technical setup and implementation aspects of AWS CDK.
Once the YAML data is ready to be consumed, it is treated as a CloudFormation stack. A CloudFormation stack is a representation of a logical grouping of cloud resources to create, where they exist, and other pertinent information. All of this information can be defined in the CDK programming language used. There also is an AWS web service which shows which CloudFormation stacks currently exist or are in progress (creation, update, deletion, rollback, etc.). A CloudFormation deployment could be compared similarly to a database transaction. If any part of the transaction would fail, the entire change of cloud resources will roll-back until the error is corrected. An example of a CloudFormation error would be a S3 bucket (i.e., a storage bucket) name that already exists. There are no guarantees to S3 bucket names and there is a possibility that the name you have entered was already taken. Many complex cases are handled but not all of them so be thoughtful with constraints you know to exist within the AWS cloud. Trial and error goes a long way here. It’s also important to note that a ‘stack id’ definition in CloudFormation becomes fairly important at this point. Naming conventions especially of purpose and environment should be specified during this time. A good practice of a naming convention could be DevWebStack. This example naming convention indicates the environment (Dev), the purpose (Web), and of course what it is (a Stack).
Now with a good understanding of what is going on within AWS CDK, let’s look into our example CDK project goals. The goal of this project is to get a web server and infrastructure in place for our development environment. Build and deployment of the code should also be required when the code goes through a CI/CD process. As the product grows other environments like quality assurance and production should be introduced at appropriate times. A few basic resources that we’ll need to build in CDK are the following:
- Isolated network
- Web service
- Build of web service code
- Deployment of web service code
Looking at our example project requirements, it makes sense to break the cloud resources into two stacks. The first stack will host the web service. The web service will be a Node.js application. The second stack will build and deploy code to the web service that will be triggered automatically from a CodeCommit repository. The web service code will take advantage of the AWS cloud’s native CodePipeline and the features of CodeBuild and CodeDeploy. Along with the first stack, we’ll include some network infrastructure for types of security containerization. Also Security Groups with AWS will be defined for network port restrictions.
In our next part
We hope we’ve illustrated that AWS CDK can be an easy (and dare we say, fun?) way to define cloud infrastructure in your favorite programming language. Now, with the background and structure portions squared away, our next article will examine the technical set-up and implementation aspects of AWS CDK. We’ll explore the set up of a development environment and learn how to use the CDK Toolkit for deployment to an AWS environment. In the meantime, feel free to look over some documentation on what CDK can handle in our external resources (below). Continue to follow our Amazon Web Services Cloud Development Kit blog series, but if you have questions about implementing AWS or CDK, don’t hesitate to reach out as our team can offer solutions to help streamline your development process – contact us today.