Book Image

AWS CDK in Practice

By : Mark Avdi, Leo Lam
Book Image

AWS CDK in Practice

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

The CDK monorepo model

You are probably familiar with the concept of monorepos. The details are outside the scope of this book, but essentially, monorepos point to all code and assets of a certain project, client, or company being in a single GitHub repo as opposed to logically separating the code by, for example, separating the frontend and the backend of the code base into different repositories.

There are many upsides and downsides to using monorepos, and developers use them at varying levels for code organization, from keeping the entire company code within a repo to just storing project-specific code in a single repository. For example, at Westpoint, we like to keep each client’s code in a separate monorepo within a separate GitHub organization. This way, we keep things secure and easier to configure.

But if you have different levels of developer access to different bits of your organization’s code, it’s best to use other methods. We aim to keep things...