Leverage L2 Constructs to Reduce the Complexity of Your AWS CDK Application: Exploring Architectural Approaches

Leverage L2 Constructs to Reduce the Complexity of Your AWS CDK Application: Exploring Architectural Approaches

Introduction

Developing cloud applications can be a complex task, especially when it comes to defining and managing the resources required by your application. Amazon Web Services (AWS) offers the AWS Cloud Development Kit (CDK), an open-source software development framework that allows you to define your cloud application resources using familiar programming languages. In this article, we will explore the use of L2 constructs in AWS CDK applications and how they can help reduce complexity.

Understanding Constructs in AWS CDK

Constructs are the basic building blocks of AWS CDK apps. They represent "cloud components" and encapsulate everything that AWS CloudFormation needs to create the component. AWS CDK offers three levels of constructs: L1, L2, and L3. Let's take a closer look at each level:

L1 Constructs: These are low-level constructs called Cfn (short for CloudFormation) resources. They are generated from the AWS CloudFormation Resource Specification and require you to configure all of the resource properties manually. Working with L1 constructs requires a deep understanding of the underlying CloudFormation resource model.

L2 Constructs: L2 constructs provide a higher-level, intent-based API for AWS resources. They offer convenience methods and defaults that simplify the process of working with AWS resources. With L2 constructs, you don't need to have an in-depth knowledge of the underlying resource model, making it easier to create your application.

L3 Constructs: L3 constructs, also known as patterns, are designed to complete common tasks in AWS. They often involve multiple types of resources and provide a higher level of abstraction compared to L2 constructs.

Reducing Complexity with L2 Constructs

When developing AWS CDK applications, leveraging L2 constructs can significantly reduce complexity. These constructs provide additional functionality, defaults, and glue logic that you would otherwise need to write yourself when using L1 constructs.

One common challenge in cloud application development is the distinction between logical architecture and physical architecture. The logical architecture refers to the shape of the system's source code, while the physical architecture represents the cloud infrastructure running the source code. In traditional server-centric MVC applications, the logical architecture runs on multiple physical web servers, often behind a load balancer and a CDN.

To achieve high availability and fault tolerance, the physical infrastructure definition should be consistent with the code. However, in many cases, the physical architecture and the logical architecture are at odds, sacrificing efficiency for availability. This disconnect between the two architectures can lead to slow bug resolution and make the system difficult to reproduce consistently.

Introducing JAMstack Architecture

One way to address the complexity of three-tier architectures is to adopt a two-tier architecture known as JAMstack. JAMstack stands for JavaScript, APIs, and Markup. It involves pre-rendering the presentation layer and using browser JavaScript for business logic. APIs act as the server.

JAMstack architecture simplifies the physical architecture by leveraging APIs for dynamic functionality. However, this approach also introduces challenges. Dynamic data and personalization may not be immediately available, as the application logic relies on browser client JavaScript. Additionally, most implementations of JAMstack suffer from the same reproducibility issues as early MVC architectures, relying on third-party API providers for key infrastructure.

Introducing Functional Web App (FWA) Architecture

A different approach to address complexity is to move up the cloud vendor stack and embrace a Functional Web App (FWA) architecture. In FWA, the entire application is authored as single-responsibility cloud functions that can render HTML-first dynamically, incorporating the full-stack, including a managed database.

In FWA, the presentation and application logic reside in the backend as pure cloud functions. These functions communicate with a managed database within the same network. The entire FWA application is deterministically deployed using Infrastructure as Code (IaC), ensuring reproducibility at any given version.

By adopting FWA architecture, the logical architecture aligns perfectly with the physical architecture, eliminating many delivery and maintenance headaches. The code you write is the same code that is deployed, achieving high availability with 100% utilization.

Actionable Advice for Leveraging L2 Constructs in AWS CDK Applications

Now, let's explore three actionable pieces of advice for leveraging L2 constructs in your AWS CDK applications:

1. Start with L2 Constructs: When starting a new AWS CDK project, begin with L2 constructs. These constructs provide convenient defaults and simplify the process of working with AWS resources. By starting at this level, you can save time and effort compared to working with L1 constructs.

2. Explore L3 Constructs: Once you have a good understanding of L2 constructs and have built some familiarity with AWS CDK, explore L3 constructs. These constructs offer pre-defined patterns for common tasks in AWS. By incorporating L3 constructs into your application, you can further reduce complexity and improve development efficiency.

3. Use Infrastructure as Code: As mentioned earlier, deterministic deployment is crucial for reproducibility and efficient bug resolution. Embrace Infrastructure as Code (IaC) practices to define your cloud infrastructure alongside the code that depends on it. AWS CDK offers powerful IaC capabilities, allowing you to define your infrastructure using familiar programming languages.

Conclusion

Leveraging L2 constructs in your AWS CDK applications can greatly reduce complexity and improve development efficiency. These constructs provide a higher-level, intent-based API for working with AWS resources, simplifying the process of building your application. By aligning the logical architecture with the physical architecture, as demonstrated by the FWA architecture, you can further streamline your development process and achieve high availability with 100% utilization. Start with L2 constructs, explore L3 constructs, and embrace Infrastructure as Code to maximize the benefits of AWS CDK in your cloud application development journey.