Forem: Zineb El Bachiri

Level Up Your AWS CDK Development: Demystifying integ-runner and integ-test

Zineb El Bachiri — Fri, 21 Jul 2023 10:53:33 +0000

Do you ever get frustrated testing your infrastructure and resources' behavior, only to discover errors after deployment? 😫 As a developer, I feel your pain. Testing is an essential aspect of software development that can be complex and time-consuming. But fear not! AWS CDK offers two powerful testing tools - integ-runner and aws-cdk integ-test library - to streamline the testing process. 🧪🚀

This article kicks off a series dedicated to integ-test. Here, we'll unravel the underlying principles of integ-test and delve into the theory surrounding tests. In the next article, I'll walk you through a CDK App example repository that illustrates how to implement and use these tools. By the conclusion of this series, you'll have a clear understanding of how AWS CDK integration tests can help you build better infrastructure with less stress! 🎉

Access the Github repository used in this series.

Understanding the Value of Integration Tests

You can use unit tests to check that your DynamoDB table or Lambda function is correctly set, but you can't use unit tests to check if they interact correctly with each other. That's where integration tests come in. And as nothing is more self-explanatory than a meme:

Harness the Latest Tools to Test Your AWS CDK Constructs

AWS Cloud Development Kit (CDK) enables developers to define cloud infrastructure as code using familiar programming languages like TypeScript. 👩‍💻🚀

As we develop a CDK app or library, two critical questions often arise at each phase:

Have I inadvertently introduced flaws in my infrastructure? 🤔
While my infrastructure seems fine, does everything that functioned earlier still operate as expected? 🧐

In the context of AWS CDK integration tests, there are two types of tests that can help answer these questions and that will bring you answer: snapshot tests and assertion tests. ✅🔍

Snapshot tests are useful for checking your CloudFormation templates, while assertion tests are designed to test the behavior of your deployed resources. Combined, they provide a comprehensive testing approach:

To write integration tests, we'll be utilizing the IntegTest library. Subsequently, we'll leverage integ-runner for running and managing these tests.

Unpacking Our Testing Tools

Let's go on a Github repository adventure! Take a look at this repo. Inside the 'tests' folder, you'll find our various integration tests:

This is an example of a typical test file, it includes the declaration of a new App, a new stack to feed to integ-test and as many assertion tests as required.

Once we declare our test file with integ-tests, we use aws-cdk-lib/assertions to add assertions, and then we run it with integ-runner! 🏃‍♀️🏃‍♂️

Snapshot Testing

Snapshots allow you to avoid re-running all your tests every time. Here's how it works:

To re-run integration tests for failed tests, run:

integ-runner --update-on-failed

This will run the snapshot tests and collect all the failed tests. It will then re-execute the integration test for the failed tests. If successful, the new snapshot will be saved.

Snapshot testing is quite common (e.g., with react components using jest). It is often overlooked by developers when they automatically use the --update-on-failed option.

Assertion Testing

In AWS CDK, assertion testing is used to test the behavior of deployed resources. Developers define an integration test using the IntegTest construct. Then, using the different integ-test tools, API calls are made, and once the request has timed out, we can check that the actions resulted in the expected events.

By using aws-cdk-lib/assertions, we can add fine-grained assertions to test specific aspects of the generated CloudFormation template, such as "this resource has this property with this value." These assertions validate the infrastructure before the deployment is considered successful.

Here's an overview of integ-test and its assertion tools:

Conclusion

Congratulations! 🎉 You now have a good understanding of the importance of integration testing in AWS CDK development and the available tools to harness the power of testing.

Stay tuned for the upcoming article, where you'll be guided through the process of becoming a proficient integration tester in the world of AWS CDK! ✨

That one AWS Lambda hidden configuration that will make you a Hero - Guardian is watching over you

Zineb El Bachiri — Fri, 05 Aug 2022 16:19:22 +0000

This article is part of a series on Guardian, an open-source, highly configurable, automated best-practice audit tool for AWS serverless architectures.

When I first started working on Guardian, I realized that AWS was releasing super cool features at an incredible speed but that an important number of them would go unnoticed by developers. This is especially the case for new options that can not be set by default to avoid breaking changes on AWS APIs. One of them is the introduction in 2021 of the new Graviton2 processor architecture in the AWS ephemeral compute service: Lambda. If you don't want to miss out on the performance, sustainability and cost saving, keep on reading!

Use the latest infrastructures for your Lambdas: Graviton processors

The X86 architecture is widely adopted in the computer science field and is the go-to choice when it comes to computers and servers hardware. Yet, in the last couple of years, ARM have seduced more than one. AWS is one of the early adopters of ARM architecture in their on-demand cloud computing offer. In 2018, they unveiled their Graviton processors using 64-bit ARM chips for their compute offering stream (AWS EC2). In 2021, AWS Lambda followed up and now AWS Lambda followed up and functions could also be powered by AWS Graviton2 processor. Now, AWS Graviton3 processors are the latest in the AWS Graviton family and is ready to use on EC2.

Improve your performance with ARM based technology

The family of processors has brought revolution by hardware as it offers reduced costs and latency while increasing performance and scalability.

Think performance

Graviton2 has shown impressive performance improvements in comparison to the X86 processor family, this is especially the case with higher loads and concurrencies. Though it is difficult to assign an overall improvement percentage, it is undeniable that using ARM processors will definitely boost your app's performance. Graviton3 is previewed to give 25% performance improvement to the previous graviton2 according to AWS. ARM also provides more predictable performance with less latency and disruptions.

Think sustainability

Your software projects —serverless or not— ultimately run on hardware and as your projects continue to grow, so does the reliance on and the use of the hardware. A 64-bit ARM core undertakes operations faster than x86_64: the task gets done quicker, and then the chip shuts down. Using an ARM architecture, you are guaranteed to reduce your carbon footprint.

Think costs

A quicker run time rhymes with saving costs. RedPanda, a streaming platform for mission-critical workloads, measured key performance metrics using the storage intensive workload platform as a target application. The results show a 20% price to performance advantage with Graviton2 compared to x86.

Specify your Architecture

The AWS Lambda service offers the possibility to use the AWS Graviton2 processor. By default, architecture is set to x86_64 to avoid breaking changes as it was the only available option up to a year ago. That is why you should specify the architecture in your lambda.

Switching all functions to AWS Graviton2 processor is easily done by specifying the architecture at the provider level whether you're using serverless-framework, cdk, san, sst or any other. With serverless-framework for example, you'll have to modify your serverless.yml as follows:

// serverless.yml

provider:
  ...
  architecture: arm64

Only one line of code to add and huge benefits.

You can (almost) always migrate your project from previous x86_64 to ARM64. Here is a link to the AWS documentation with migration instructions for Lambda Functions.

Easily monitor Lambda Functions Architecture with Guardian 🛡️

Guardian now offers a new rule guiding you to specify the architecture of your lambda functions.

Guardian also comes with many other rules to help you make the best decisions for your Serverless project. It will help you identify where your deployed resources can be optimized to achieve better performance at a lower cost.

Guardian how-to

npm install @kumo-by-theodo/guardian
npx guardian -p <your_aws_profile> -c <your_stack_name>

Guardian is available on NPM. You will find instructions to use Guardian in your CI.