An Overview of AWS, Serverless Computing, and CDK

This is the "Introduction" chapter of the AWS CDK Serverless Cookbook.

This book will provide a step-by-step guide to creating a serverless application using Amazon Web Services. We will create a serverless website with databases, application programming interfaces, and processes to analyze data.

An Overview of Amazon Web Services

Amazon Web Services1 is a cloud computing service by Amazon. Cloud computing is a model where computing and data services (e.g., servers and storage) are hosted by another company and accessed over the Internet. Traditional models used on-premise hosting, where all servers and data storage are hosted inside the buildings where organizations run their operations. Some organizations have a hybrid model using a mix of on-premise and cloud-based solutions. This book will focus on cloud computing even though creating a serverless solution on-premise is possible.

AWS became popular because it offered low-cost cloud-based storage and virtual servers in various geographical locations worldwide. Developers could create and delete web servers, databases, and storage quickly and efficiently. As their applications grew, they could easily scale their resources. As demand increased, they could add more servers to meet the demand. As demand decreased, they could remove unused or underutilized servers. AWS simplified development compared to the limitations of physical space, utilities, support staff, and procurement in the on-premise model.

In 2014, AWS introduced its AWS Lambda. Lambda allowed developers to run code without having to provision a server. The introduction of Lambda introduced “serverless computing.”

An Overview of Serverless Computing

The term “serverless” has evolved over the years. The initial definition with the launch of AWS Lambda was focused on computing (i.e., running code) with less focus on servers. Whether or not Lambda uses servers to run the service is irrelevant. Developers did not need to worry about creating a server, installing the dependencies and packages, keeping it up to date, and hardening security settings. Their main focus was uploading code to the Lambda service to create a function and having it execute some business logic.

Over the years, serverless has been associated with certain key benefits:

• Faster development
• On-demand services
• Improved elasticity
• Increased scalability
• Simplified maintenance
• Reduced attack surfaces

These benefits came from the event-driven architectures typically used for serverless applications. An event-driven architecture assumes that an event drives system activity. For example, a computer will send an HTTP request to an Application Programming Interface (API). The API will forward the HTTP event to a Lambda function. The function will execute the code and send a response to the API. The API will forward the response to the computer. In this example, the API and Lambda functions will have no activity until it gets an HTTP request.

Microservices architectures can be used in serverless computing. This design paradigm allows us to divide resources into logical groups. For example, we can have an API and Lambda functions for creating, reading, updating, and deleting user data. The application will make API calls to the microservices to process relevant data.

Serverless applications can suffer from overly complex architectures that are difficult to maintain. For example, an HTTP event is sent to an API. The API forwards the request to a Lambda function. The Lambda function sends an event to a queue and a response to the API. Another Lambda function polls the queue and uses its data to write data to a database. The database sends an event to another Lambda function that writes data to an S3 bucket. The S3 bucket sends an event to another Lambda function that updates a value in a parameter store. We can easily fall into these confusing design traps when we develop a serverless application ad-hoc.

We will focus more on building on our application than architecture design in this book. This book is meant to be a book for practitioners who want to learn to make a serverless application step-by-step. We will keep the serverless application design as simple as possible. We will use the Keep It Super Simple (KISS) principle.

Read a more detailed introduction to cloud computing and security from the Serverless Security book.

An Overview of Infrastructure as Code

Over time, cloud developers realized creating cloud resources and deploying the application systematically was essential. Programmatic deployments were already typical in software, but early cloud computing lacked this capability. AWS users had to configure cloud resources and applications using the web-based AWS console.

In 2010, AWS launched AWS CloudFormation, allowing users to write their cloud configurations in JSON and YAML file formats. A user would use the AWS command line interface (CLI) or software development kit (SDK) to request CloudFormation to create resources using the CloudFormation template. Teams could now use “code” to deploy their cloud infrastructure and maintain their cloud configuration in source code repositories.

In 2015, the Serverless Framework[2] was launched to simplify the creation of CloudFormation templates for serverless computing. The framework provided a simple custom YAML template, making creating and deploying serverless designs easy.

In 2018, AWS created the AWS Cloud Development Kit (CDK). Rather than writing CloudFormation templates, developers can create their cloud resources using JavaScript, TypeScript, Python, Java, C#, and Go. Unlike the Serverless Framework, CDK allows writing code to deploy any AWS resource that can be deployed using CloudFormation. The Serverless Framework can deploy CloudFormation templates for non-serverless cloud resources. Both frameworks have their benefits and drawbacks. Please read the post below for more details. We will create our cloud infrastructure with code with the AWS CDK framework.

An Overview of the AWS Cloud Development Kit

The AWS CDK framework allows us to create infrastructure as code with CDK apps. A CDK app is used to deploy a group of AWS cloud resources. A CDK app is structured into the following components:

• The executable bin file that runs the application
• Stacks that have a group of cloud resources
• Cloud resources defined by constructs

A CDK stack will create a CloudFormation stack. Thus a CDK app allows us to develop multiple CloudFormation stacks using the CDK app code.

CDK provides constructs that configure cloud resources. There are three types of constructs:

• Level 1 constructs allow us to configure a CloudFormation resource directly. The L1 construct provides the same properties as the CloudFormation template.
• Level 2 constructs are an abstraction of L1 constructs to configure a group of CloudFormation resources to deploy a logical group. For example, the aws_lambda package provides the Function construct that will create a Lambda function and the CloudFormation resources it needs. AWS writes the L2 constructs.
• Level 3 constructs are the next level of abstraction, allowing us to group L2 constructs. For example, we can create an L3 construct to create a Lambda function, the related CloudWatch log group, and add custom tags. We create constructs or get them from Construct Hub.

The concepts will become more apparent as we build our serverless application.

Chapter Review

We quickly reviewed AWS, serverless computing, the infrastructure as code methodology, and AWS CDK. As we build our application, the following chapters will expand on relevant cloud computing and serverless concepts. In the next chapter, we will set up our environment to create our first CDK application.

Next, we will set up our AWS account and development environment to create our application.

Before you go

Subscribe to my mailing list to get new chapters delivered to your email.

Go to the “AWS CDK Serverless Cookbook” table of contents.

Endnotes

[1] Amazon, Amazon Web Services and AWS are registered trademarks of Amazon Web Services, Inc.

[2] Serverless Framework is a registered trademark of Serverless, Inc.