Enterprise implementation of Infra-as-Code using CDK

Introduction

In the traditional IT and Software Development setup, we have always seen development squads are oblivious of how developed applications are deployed and how the infrastructure/configurations are maintained. With Cloudformation as one of the front-runners in the IaaC world of infrastructure development, declarative YAML-based implementation tends to be of no interest to squads doing object-oriented development. Moreover, with Cloudformation, Infra engineers needed to have specific service or domain knowledge as well. Once AWS introduced CDK in 2019, we started observing a change in the motivation for the development squads to involve themselves in the IaaC realm. This post describes the problem statement and resolution to steer the application squads to move toward deployable infrastructure code development. We will also showcase one of the solution patterns written in CDK, adopted within multiple squads in an organization.

Problem Statement

We have seen inside the enterprise IT and Software ecosystem, that there is a lack of cadence when it comes to developing infrastructure and applications together as part of similar life cycles. Initially, we have the IT infrastructure being maintained separately and have different iterations/development cycles.

Most of the common setup in the IT and Software industry is backed by the conglomerate of multiple teams namely,

• Infrastructure: Managing the Cloud environment and its ecosystems.
• Configuration and Devops: Maintaining the different infrastructure-dependent configurations and DevOps support for application teams.
• Application development teams: Producing and maintaining the production deployable workloads and functionalities.

Resolution

Change in Philosophy

With the adoption of CDK, we have tried to enable developers to also deploy and manage cloud infrastructure as well as provide the scope to get involved in the development realm of Infra-as-Code.

Evolving Ecosystem of Traditional Software Development

One of the main advantages CDK brings is creating deployable resource management objects using code. Using the strength of object-oriented programming and different tool support in CDK, our multi-functional IT ecosystem has experienced increased overall visibility and knowledge of the infrastructure and AWS ecosystem. We have adopted the approach of the Cloud Center of Excellence (CCoE) where solution architects and developers of the infrastructure team provide solution patterns, including best practices and knowledge sessions. For providing the solution patterns, We have repositories that are leveraged with the packages getting deployed to be used/reused in the production-grade applications.

For the CDK-based development, we have used the Construct Library which is a library of AWS-provided objects to encapsulate the Cloudformation configuration interface. These are L1 resources that are used to create the resources which need a more customizable setup. Additionally, we have been providing the team with pre-baked production-grade Solution Constructs to import into their application. Lastly, through different knowledge forums, we have been providing a curated list of CDK projects like AWESOME CDK which increased the development speed in CDK.

Solution Construct Deployment

Working with CDK has been proven to increase the production of the infrastructure engineers which provided them with the full CI/CD Workflow and Code Review. Engineers can also leverage the features of OOPS unit testing features like snapshots and assertions-based testing. One of the most common implementations using CDK and CI/CD is using Github and AWS services like Codebuild, Codecommit, and Cloudformation Changesets.

Migration of Cloudformation to CDK

For the Infra engineers and the Cloud solution architects team, we have opted for the following approaches to move the existing Cloudformation templates to CDK

1. Rewrite the templates to CDK: This is the longest approach for a few of the templates to be rewritten using CDK with If-Else conditions and unit tests, however, it provides the full flavor of CDK towards the development. Most of the solution constructs are being built using this approach.
2. Importing templates inside a CDK application: This approach is by far the quickest way to get the infrastructure running on AWS CDK, but it also does the least to position the developers for success by basically adding a wrapper around the existing templates.
3. Using 3rd party tools: AWS Cloudformation Disassembler is also used to translate the Cloudformation templates into CDK, however, it also comes with perils as the tool itself is still evolving.

Architecture

The next section through an end-to-end solution which consists of a solution pattern deployed in production using the CI/CD strength of Github and open-source framework projen.
We will present a pattern where an application is present which is a simple REST API, backed by a Java application using quarkus and maven. It will be deployed in the AWS Service ECS as a service. The most interesting part of the whole lifecycle is the CDK code.

Architecture Diagram

In this example, we assume that we already have VPC and Bare ECS Cluster setup in the account. Also, we need to have a private Route53 hosted zone which will be used to create the application listener rules.

DevOps Setup

We will start with setting the IAM roles which will be used to deploy the resources as changeset in AWS accounts

The Above Cloudformation template once executed into an AWS account will provide us with the role required to connect Github and the repository with the account. Also based on the resources deployed we might need to add more custom policies in the role as well.
Moving on to the Github actions and pipeline triggers, We will add the basic steps required in the workflow to execute the changesets in the AWS account

We need to add the role created in the secrets of the Github actions and also mention the region in which the stack sets will be deployed. This workflow contains the basic steps of automating the CDK synth and CDK deploy command with all the necessary installations.

Application to be deployed

Looking at the application deployed, it’s a simple REST JSON API built using Java, with Maven and Quarkus. It’s a basic API that will return a predefined response from the backend. Once we run the application locally, it will give the following response:

We have established the structure of the application code and infrastructure CDK code in a separate folder based out of the root path.

Moving inside the CDK code, We have started defining the VPC object by looking up the VPC id from the stack’s input.

Next, we will move on to fetch the existing ECS cluster setup by providing the security group id and cluster name from the stack’s input.

After creating the VPC and ECS cluster object, we move on to create the Task Definition based on the application described above. Here in the stack inputs, we need to provide the path in which the application and docker file is present. Also, we need to create the log group definition which will be created as part of this stack.

Next, we provide the EC2 Service definition that will be created based on the task definition which is created above and also the desired count taken from the input.

Lastly, we create some route53 records based on the DNS domain and ALB DNS name from the previously created private hosted zone

Lastly, We define the load balancing rules based on the above-created records and also create the autoscaling rules for the EC2 hosting the service.

All the above implementations provide the setup for the Application to be deployed in an ECS cluster as an EC2 based service. After committing the code to the Github, the workflow executes and creates a changeset in the AWS account.

Once we log into the AWS account, We can also see the components are created and deployed in ECS as a service

All the resources are created in private subnets and without creating a public API, We can connect to the EC2 using session manager and check the rest API is deployed and behaving as intended.

Here is the sample code for the full repository. The Github actions run will not work in this scenario, we need to put the actual values inside the stack input parameters namely VPC ID, ECS cluster, and Security group(these are not part of this CDK stack)

Conclusion

Apart from the above methodology and inspirations, Squads are also provided with many workshops and community support for motivating them to adopt the CDK based on the programming languages they feel comfortable with.
Using the above approach, We have experienced different squads implementing the infrastructure configurations using CDK as well as improving the overall CI/CD workflow and also reducing issues or downtime in the production applications due to misconfigurations or infrastructures related issues.