AWS Cloud Development Kit – A Deep Dive

The AWS Cloud Development Kit (CDK) is an Open Source tool which allows for a high level of abstraction to be achieved through using a familiar programming language to define, build, deploy and package cloud infrastructure.

If you’re more at home with code than markup languages or configuration files, the AWS CDK may represent a more comfortable and powerful way to build functional code and the necessary infrastructure required to run it whilst maintaining the scalability and flexibility of CloudFormation.

One way to think of AWS CDK is not as Infrastructure as Code but infrastructure is code.

Its level of abstraction allows for, typically, between 10 and 20 lines of code from your choice of programming language (in the above case, TypeScript) to be used where many of hundreds of lines of code may have been used with CloudFormation.

The above example shows how just 17 lines of code can be brought together which results in the creation of a new VPC along with a Fargate cluster created through ECS using a defined image.

How does AWS CDK differ from CloudFormation?

AWS CDK makes use of CloudFormation. AWS CDK can be thought of as a tool made especially for developers which makes use of the capabilities of modern programming languages. It enables you to define Infrastructure as Code while passively invoking CloudFormation at the deployment stage. At the deployment stage, CloudFormation templates, which consist of sensible defaults, are produced then executed in the background. You still benefit from all CloudFormation benefits such as safe deployment, drift detection and the ability to automatically rollback.

Originally, AWS CDK only supported code written in Typescript. Now AWS CDK allows the user to provision infrastructure through their language of choice from Python, TypeScript, JavaScript, Java or C#/.Net. As a keen proponent of Python, I will relate to Python in this article.

The Anatomy of CDK

Constructs

A construct is the building block of an AWS CDK app. It is a reusable logical group of cloud components which encode configuration detail through boilerplate examples. Services such as an AWS S3 storage bucket, Amazon RDS database instance or the entire capabilities of CloudFormation resources can be called upon at this level. The AWS Construct Library ( https://docs.aws.amazon.com/cdk/api/latest/docs/aws-construct-library.html ) contains a comprehensive list of resources available on AWS which can be called up as constructs for use in apps, along with the syntax of their usage through the programming language of your choice. To compare with programming languages in a conventional manner of speaking, constructs could be thought of as libraries in that the lines of code which declare the constructs could be seen as similar to, for example, an import command in Python.

Stacks

A stack is a unit of deployment within an AWS CDK app. To provision the infrastructure resources, a stack is defined. Any number of stacks can be defined within an app. 

Apps

The app defines everything which is brought together at the point of executing the code. The execution follows four stages: Construction, Preparation, Validation and Synthesis.

The construction and preparation phases involve linking all constructs together and making syntax checks on the parameters applied within the high level code. The validation stage follows on from brief checks during the construction phase and involves a more thorough validation that they can be deployed correctly. Finally, the synthesis stage will send instruction to the core CDK code to create the various artefacts, such as CloudFormation templates, which are subsequently deployed.

What are the advantages of AWS CDK?

Avoiding markup languages

They’re not everyone’s cup of tea. I personally have almost torn out what little hair I have left whilst having a meltdown over JSON spacing. Whilst they are powerful and are used in the configuration of services such as CloudFormation, AWS CDK keeps all that low-level markup code firmly under the bonnet. Through minimal high-level code in your favoured language with several parameters spread through a few lines of AWS CDK library code, the resulting hundreds of lines of CloudFormation code that AWS CDK will create on-the-fly takes care of the Infrastructure-as-Code aspect of your deployments.

Familiarity

The scalability of AWS CloudFormation is now available as a library, reduced to several lines of code in the language you are comfortable with. For those who prefer to bring everything back to the programming language they feel most comfortable and creative in. It is an excellent way to extend your comfort zone into infrastructure provision. 

Portability 

With typical CDK code being around 10-20 lines long, there are obvious portability benefits. Providing that application code, if complex, bespoke or not an out-of-the-box, is suitably encased within a repository (e.g. GitHub), both application and infrastructure code will be extremely portable.

Innovation and flexibility

Innovation may be more of an abstract notion, but if you consider yourself to be creative when it comes to your chosen programming language, it could lead to your finding of a new or improved way to deliver an infrastructure based upon a creative use of coding which might not otherwise have been possible with other tools. In essence, you could bridge the gap between bright ideas and functional deployments and be imaginative as to what triggers an infrastructure event.

Summary

Personally, I have more knowledge of Python than I do of CloudFormation. Knowing that there is a tool I can invoke through Python code which manages, amongst other things, the use of CloudFormation is encouraging.

Not that I have anything against CloudFormation, far from it. It is a fantastic utility and it firmly holds its place amongst the powerful and most popular of all AWS devops tools. For drilling down into the minutia of configuration items, it remains the best option.

AWS CDK offers programmers the means to deploy using the best of AWS tooling whilst staying within their programming language comfort zone, being content to accept sensible defaults, and simply choosing to not get too bogged down in the nuts and bolts of a modern devops deployment.

Hopefully this look at AWS CDK has been beneficial to you in how you look at the right tools for the job and how you can quickly provision infrastructure in a manner you may feel more comfortable with.

If you would like to find out how CirrusHQ can assist you in your DevOps journey, feel free to drop us a line at info@cirrushq.com or via our contact page.