Book Image

AWS CDK in Practice

By : Mark Avdi, Leo Lam
3.5 (2)
Book Image

AWS CDK in Practice

3.5 (2)
By: Mark Avdi, Leo Lam

Overview of this book

As cloud applications are becoming more complex, multiple tools and services have emerged to cater to the challenges of running reliable solutions. Although infrastructure as code, containers, and orchestration tools, such as Kubernetes, have proved to be efficient in solving these challenges, AWS CDK represents a paradigm shift in building easily developed, extended, and maintained applications. With AWS CDK in Practice, you’ll start by setting up basic day-to-day infrastructure while understanding the new prospects that CDK offers. You’ll learn how to set up pipelines for building CDK applications on the cloud that are long-lasting, agile, and maintainable. You’ll also gain practical knowledge of container-based and serverless application development. Furthermore, you’ll discover how to leverage AWS CDK to build cloud solutions using code instead of configuration files. Finally, you’ll explore current community best practices for solving production issues when dealing with CDK applications. By the end of this book, you’ll have practical knowledge of CDK, and you’ll be able to leverage the power of AWS with code that is simple to write and maintain using AWS CDK.
Table of Contents (17 chapters)
Part 1: An Introduction to AWS CDK
Part 2: Practical Cloud Development with AWS CDK
Part 3: Serverless Development with AWS CDK
Part 4: Advanced Architectural Concepts

Getting Started with IaC and AWS CDK

Infrastructure as code (IaC) is the standard practice of defining various infrastructure components using code. You must have heard about a few of these software tools, such as Chef, Puppet, Terraform, or the old-school Bash programming, to set up servers in a predictable way.

The need for IaC was born out of the toolset for spinning up servers circa 2006 lacking the predictability, speed, and agility of the code used in programs that were deployed onto servers. Pre IaC, the normal workflow of deploying something on AWS would be this:

  1. Spinning up Elastic Compute Cloud (EC2) servers manually via the dashboard
  2. SSHing into the machines
  3. Copying some Bash configuration files using Secure Copy Protocol (SCP)
  4. Running them in a certain sequence to deploy an application
  5. Configuring database connections

This is one of the better scenarios of how things were done back then.

Needless to say, this method was not scalable, repeatable, or reliable enough to deal with the ever-increasing complexity of web applications on the cloud. Around the same time, tools such as Chef, Puppet, and a few others showed up, which helped immensely with server configuration.

A couple of years later, tools such as Terraform popped up, which at the time were quite revolutionary in the way that they defined the desired state of the deployment on a given cloud service provider (CSP) such as Amazon Web Services (AWS) in a declarative fashion. This configuration would then be fed into the Terraform toolset, which would then decide which AWS services needed to be created, deleted, or modified. Let’s look at one such Terraform configuration file:

resource "aws_instance" "single-instance"{
  ami           = "ami-ebd02392"
  instance_type = "t2.micro"
  subnet_id     = "subnet-eddcdzz4"
  vpc_security_group_ids = ["sg-12345678"]

The preceding Terraform configuration file defines an AWS EC2 server using the aws_instance resource type provided by Terraform’s AWS provider and then is given an Amazon Machine Image (AMI) configuration (which is essentially the operating system image) instance type to define its CPU and RAM configuration and other network settings. If you have Terraform set up correctly locally, this will investigate your AWS setup, see that this server doesn’t exist, and then proceed to create this server for you.

Obviously, this is a very simple example. There are Terraform configuration projects with many thousand lines of configuration files. These projects can get quite elaborate and out of hand once the complexity of the deployment increases. There are various remedies for this, none of which—in our opinion—really addresses the issue here. Have you spotted the problem?

The problem is that these configurations are not really defined as code. They are defined as declarations in a declarative language that are not Turing Complete code blocks.

In this chapter, we will cover the following main topics:

  • Introduction to AWS CDK
  • Setting up your local environment and writing your first CDK app
  • Creating a containerized web application in AWS CDK using Docker
  • Understanding the inner workings of AWS CDK