Video Summary and Transcription
Welcome to this session on Lambda Developer Experience. Learn about using AWS Cloud Development Kit (CDK) to write code in your favorite language and automatically generate CloudFormation templates. Test locally with the SAM CLI and deploy with CDK. Accelerate testing and updates with CDK flags. Use the AWS Toolkit to invoke Lambda functions, analyze logs, and generate code with Application Composer.
1. Introduction to Lambda Developer Experience
Welcome to this session about Lambda Developer Experience. Discover tools to properly develop serverless workloads using Lambda function directly with Visual Studio Code or IntelliJ.
Hi, and welcome to this session about Lambda Developer Experience. How often you have found yourself that you are deploying your Node.js workload on the cloud and you need to wait for CloudFormation or Terraform or whatever else that has to deploy all your code every single time, despite you change maybe one line of code, the feedback loop that you have in order to wait for the deployment is pretty long. Sometimes you go out for a coffee, maybe you lose the momentum, and therefore, today I want to show you what are the tools that are available for you to develop properly a serverless workload using Lambda function, your favorite compute service directly with Visual Studio Code or IntelliJ because all the things that I'm going to show you today are going to be valid for VS Code as well as IntelliJ.
2. Using AWS Cloud Development Kit (CDK)
AWS Cloud Development Kit (CDK) is an infrastructure as code tool provided by AWS. It allows you to write code in your favorite language and automatically generates a CloudFormation template for deployment. Let's look at an example: a simple Hello World application using ESM with nodes and CDK. CDK lets you write TypeScript and extends the Lambda function with additional capabilities like bundling options using ESBuild. Deploying the solution is as simple as running 'cdk deploy' and choosing the profile with the necessary information. CDK will handle the deployment, including the creation of an HTTP API acting as a proxy through API Gateway. Once deployed, you can access the API using the provided URL.
So let's start. First of all, what we are going to use today is AWS Cloud Development Kit, CDK as everyone refers to, is one of the infrastructure as code tools that are offered by AWS and allows you to write with your favorite language and then automatically behind the scene when we are building our artifact, what happens is that we are generating a CloudFormation template that will be then used for the deployment and provisioning of your code and infrastructure.
Now, let's try to see an example. I prepared a couple of examples so we can start to look into that. So the first example here is about a very simple Hello World example. I created this template for using ESM with nodes and using CDK for defining my infrastructure. So as you can see here, the beauty of CDK is I'm writing TypeScript that is in this case my favorite language for writing CDK. And here I have a high-level construct like node.js function that is extending the Lambda function. So as you can see here, it's extending this construct, this low-level construct that is called Lambda.function and it's adding new capabilities like the possibility to add bundling options. By default, CDK offers you the possibility to use ESBuild and therefore why not leverage that for making our bundle size smaller. So as you can see here, I use the bundling with a bunch of configuration that allows me to have the possibility to use ESM modules as well as other capabilities like top-level await for instance.
And now if we want to deploy this solution in an AWS account, it is as simple as writing here cdk deploy and then I decide which profile that I configure multiple profile in my machine I want to use where I have the region, I have my information needed in order to deploy this workload on the cloud. Now it's the first time that I'm doing that. So as you can see, CDK is telling me, oh by the way, there are a few things that you need to deploy, that are all the things in green. As you can see here, that will be needed in order to have this API up and running inside my system. So okay, so this one is as simple as a lambda function with an HTTP API that acts as a proxy that shows as API gateway the possibility to expose your API. So in one minute, this will be up and running and available on the cloud. And in the meantime, we can see that here we have the definition of my hello ESM lambda. Then we have an HTTP API definition that you can easily do with CDK. I just create the integration that basically is allowing you to have all the roles and settings needed in order to wire on a specific route your lambda function. And here you have the path that is the root path, the method that you can invoke this specific lambda function. And that's basically what you get. And at the end, we are going to have also this construct, this CFN output, basically it highlights inside your command line, the URL where you can find this API. As simple as that. So now we have deployed everything. As you can see, we have a URL that is useful. So if everything goes well, we should have our API up and running. And here we are. We have hello node ESM module. That is exactly what we have here, as you can see.
3. Testing and Updating with CDK
When developing with CDK, you can test locally using the SAM CLI. By running 'SAM local start API' and referring to the generated template, you can have an API running on your local machine. To update and test changes, you can use the 'cdk build' command to rebuild and deploy the solution. CDK also provides the 'cdk sync' command to repackage assets.
Now, if for instance, now we would like to change these hello ESM module and want to change in hello devops.js. That is a new let's say, way to potentially a new functionality that you have or something like this. We should go through the same process. And this time we are going through the build and and then provisioning for cloud formation that checks if your infrastructure is changing. If it's not, it's just updating the code. Is there a better way to do so? Yes, the reality there is a better way, especially when you are developing.
When you want to develop and have a decent developer experience, you want to have a fast feedback loop. So let me show you a couple of things. So first thing, with CDK, you have also the possibility to test locally using another tool that we have created in AWS. It's called SAM. And SAM is just a CLI. So what I can do is just say SAM local start API. And then I refer to a specific template that is generated by CDK. This slash dash with this flag basically is taking as input a cloud formation template. And you might wonder how we can provide that. But it turns out the CDK in the CDK out folder has exactly what we are looking for. So these specific node ESM template. So what we're going to do is going here, selecting node the ESM stack.
And when we run this, sorry, when we run this in the CLI, what we're going to have is an upper running API that you can test locally. So for instance, now, what we should expect is that if I'm going here and use the curl is running invoking my Docker container with Node.js 20 is running the application. And here we are. We have the previous session. Why is that happening? That is on purpose. So we didn't rebuild our solution. We made a change. We save the file, but off you go. So now if we want to have the new way, let me show you another message, sorry, another comment. So you can use CDK scene. And basically what is happening right now is repackaging inside the CDK out. As you can see, there is a new asset folder.
4. Testing in the Cloud and Rapid Updates
To accelerate the testing of serverless workloads, especially Lambda, it is recommended to test in the cloud rather than locally. Certain things, like IAM policies and cloud latency, cannot be mocked and need to be considered in the design. To accelerate the feedback loop, CDK provides flags like 'watch' and 'hot swap' that allow you to make changes to your code and swap it under the lambda function without going through cloud formation. This eliminates the need to wait for package creation and deployment. The deployment is up and running, allowing for rapid updates.
And my new, let's say, code. And in this case, if I start again locally, my SAM application, in this case, I have my upper running container. This is running my code. And now I run in my CLI. If everything goes well, as expected, we are going to have a new command that is hello devops.js. So job done.
So now we know that we can deploy on the cloud. We can test locally using SAM. That is a serverless application model. It's the CLI that I mentioned before. But we can do even more. Now we have tested our Lambda function, the API, locally. So that's great. What can we do better for every rapid feedback? Usually what we recommend when we are testing a serverless workload, especially Lambda, is that you are testing in the cloud. Because the reality is, there are certain things that you cannot mock. For instance, the IAM policies, the latency that you have in the cloud, and so on and so forth, that matters when you are designing a serverless workload.
So in this case, let's kill this process and let's go back here. So what can we do in order to accelerate? Very often when I speak with a customer, they remain surprised when I show these tricks. So you can do with CDK deploy and add a bunch of flags. So first I want to have watch. So every time that I change something, either in the infrastructure configuration or in my code, I want that something happens. And then I have this special flag that is called hot swap that has also hot swap fallback that allows you to do two things. Every time that you are going to make a change on your code, it's going to first watch and recognize that is a given of the watch flag. But more importantly is swapping your code underneath the lambda function without passing through cloud formation. What it means that we don't have to wait every time to create the package, upload on an S3 bucket, and then start to deploy the template. And then suddenly, finally, you have your change deployed in your development account. Without swap that we heavily recommend to use only for development environment. What you can do is say, okay, so we have this, we are the profile that so we know that we have all our configuration already there. And now what is happening is the deployment is up and running. So I take one millisecond change, and now we have our URL.
5. Testing Locally and on the Cloud
To quickly make changes and see them on the cloud, we can use curl commands to test our code. By recognizing code changes without infrastructure changes, we can see the updated results. We can also modify the infrastructure, such as changing the architecture, but this requires going through cloud formation. Overall, we now have the ability to build, deploy, and test our serverless workload without leaving our IDE, using SAM and CDK together. This allows us to test locally and on the cloud, utilizing additional services like local stack if needed.
So if I take this and run here, a curl command, I run, I have a load DevOps. So all great. But what if I want to make a change? What if I want to make a change quickly? I want to add just some question marks and I want to see what looks like on the cloud. So as you can see here, it's already started to do some stuff. So what happened is that it recognized that I changed my code, it recognized that it's just a change of the code, no infrastructure has changed. And therefore, if now I call the curl command, here we are, we have the three question exclamation marks available over here. We can obviously change the status code and do any changes we want in this case. So if I instead of doing just curl and the URL, I just curl verbose. And then now I see you have like 200 status. Obviously, those are very simple. Potentially, what I can also do is changing something on my infrastructure. So in this case, instead of using an architecture x86, I can use Arm architecture. And when I store it in this case, because I'm using hot swap, it's recognizing that it's not hot swappable because it's an infrastructure change. So in this case, it's going through cloud formation again and following the normal path. But if you think about that, very often you work on the business logic and the action that you want to express inside your lambda function. Way less when you configure on the specific intrinsic of the configuration of your infrastructure. Therefore, these shouldn't happen as often as the other phase. So as you can see here now, we have deployed everything, now it's running in Arm and off you go, you have what is needed. But as you can see now, without leaving our favorite IDE, we have the possibility to build our serverless workload to deploy. We have the possibility to change just atomically a portion of the code and have everything up and running. We have the possibility also to, let's say, test locally using SAM in conjunction with the CDK. And that is great because it enables you to use also things like potentially local stack if you want to mimic other services like SNS or SQS that are not available through SAM. So we have a bunch of capabilities now to test locally, to test quickly on the cloud, only on the development account, and we have seen, let's say, how we would like to design these kinds of solutions.
6. Deploying the Stadium Stack
I will now show you another example, the stadium stack. It includes an API gateway, a lambda function for retrieving NFL stadium data, a cache aside pattern using Elastic Cache with Redis, and a Postgres database in Aurora RDS. This production-ready solution also has stacks for deploying parameters, power tuning, and using AWS Lambda Power Tool for observability. The workload is already deployed, and you can curl the URL to get the response. You can also use AWS toolkit to invoke the lambda function.
Now, we have seen this example, but I want to show you more. For instance, I have another example that I prepared just for you, that is this stadium stack. So let me clear for a second this part here, but we are here. So okay, so how it looks like. So this is the architecture that was designed in this example. So we have an API gateway, we have a lambda function that is retrieving all the NFL stadiums available in 2023. And then we have a cache aside pattern using an in-memory database like Elastic Cache with Redis. And then we have a Postgres database that store all the data and information needed in Aurora RDS. So as you can see, we have a lot of capabilities here that are needed for building a simple API, right?
The cool thing of this, let's say, production-ready solution is that you have quite a lot of stuff inside. So you have in this specific example, my stadium stack that is deploying my API with API gateway and the things that we have seen. We have one for deploying only the parameters that are needed for, I don't know, setting the port of the database or checking where to find a specific parameter store extension available for lambda function. We have also another stack for power tuning. So this is a tool that is used for rightly size without guesstimate the memory size of your lambda functions and so on and so forth. So I can create multiple stack on a specific solution that is quite normal. And then I have my get data and get data is using another open source tool that we recommend to use with lambda, it is AWS Lambda Power Tool. And lambda power tool is nothing more than an opinionated way to operationalize the observability of your applications. So the cool thing is here, I'm adding a bunch of tracing, I'm adding some metrics, I'm adding some logs and everything usually are available in CloudWatch that is our solution for collecting all this information.
So now let's try to see how it works. So this specific workload is already deployed. Let me double check that everything is working as expected. So we want to deploy in this case stadium stack, and we want to use profile playground that is my default one. And now everything should be there. So they build the two lambda function, it's just checking everything's there. In fact, it didn't take too much time, we have everything in here. So we take this URL and just to show you how it works, you can curl this URL and off you go, you have the response of all your stadiums, the NFL stadiums. There is another way that you can invoke a lambda function that is through AWS toolkit. AWS toolkit as you can see here is this AWS solution here that provides a bunch of capabilities that you can wire up code whisperer that allows you to use generative AI for creating the code based on some comments that you do. We announced recently Amazon Qt that is in preview and we will see in a moment how it works. But let's first focus on how to invoke a lambda function. So potentially here, what you can do is going in this Explorer.
7. Invoking Lambda Functions and Analyzing Logs
I can invoke my lambda function directly from my IDE without using curl or any CLI command. The AWS toolkit allows me to retrieve live logs from CloudWatch inside my IDE. I can analyze the logs and debug my lambda function without going into the AWS console. I have full control and access to the logs for the last 15 minutes or even a specific time range.
So I'm already in my region that is Ireland, that's where I deploy my workload and I can go and check my lambda function that is stadium stack. Here we are. That is get data, so it's this one. And I can invoke on AWS. So directly from your IDE without using curl or any CLI command, you can invoke a lambda function that maybe is triggered by API gateway, maybe is triggered by I don't know Kafka message, maybe is draining a queue on SQS queue. So as you can see here, you have all different templates for every single event that the lambda can be triggered from.
In our case, we will do an L award. We don't care about what is inside because in this case, it's just a get. It doesn't require anybody. But when I invoke my lambda, I have exactly the same thing. As you can see here, I have exactly the same response inside output. That's another way that you can use your, let's say, invoke your lambda functions based on testing different things in directly in the cloud from your IDE without, let's say, creating different tools or other things that are needed. I can also do more with that.
For instance, now we invoked a few times. Let's invoke another couple of times this API just for the sake that I want to show you another interesting thing. So from the AWS toolkit, another cool capability that you have is retrieving directly live the logs that are available in CloudWatch inside your IDE. So now if I say, OK, I want to go in CloudWatch logs in get data is the name of my API. Yeah, I want to have all the last 15 minutes logs of this specific one. And here we are. So as you can see here, these are pulled directly from the calls that I've made. So the last call, the last few calls that I made to this specific lambda function happened at 12.48. Now it's 12.49. So it's one minute delay. But as you can see, I have the last 15 minutes. And here I use PowerTools to get quite a lot of information out of it. So I set up PowerTools in order to provide some information, like I want to know when my parameter secret lambda extension is available. I want to know how much is the duration of my lambda function, and so on and so forth. So if I have any metric or any other thing are available here without going into the AWS console, I can start to debug and do my, let's say, analysis of what I'm looking for directly here. As you can see, this doesn't allow you only to take the latest 15 minutes or latest logs. You can also go back on a specific time range.
8. Using AWS Toolkit and Application Composer
You can use AWS Toolkit for IntelliJ IDs and VS code to select different time ranges for logs. The Toolkit also allows you to generate state machines for step functions and visualize your infrastructure using AWS Composer. You can use Application Composer in your IDE to create applications through a drag-and-drop interface and generate code.
You can select last week, and three days, and so on and so forth. And that is another cool thing that you can do with AWS Toolkit that, again, is available for IntelliJ IDs and VS code.
The other interesting part of the Toolkit is, as we have seen, running lambda function or running other things. If you're using step function, you can generate on the fly the state machine that you have written inside your code. But moreover, you can even, from a recent announcement, visualize through AWS Composer what you are building.
So let's go back here. We go in the CDK out, and we select our template for the stadium stack. So I can click here, right click, and select Open with Application Composer. So as you can see here, Open with Application Composer, when I click that, is going to generate a graph for me that contains everything that is deployed inside my infrastructure. So this one basically is representing, visually, what I have written in CDK, transformed through CDK into a CloudFormation template. And now, suddenly, I have the possibility to use that. Obviously, this one, because it's from CDK, so it's derived template, you cannot edit it. I cannot add that resource and, let's say, find it, because we didn't build yet a solution that we are able to transform from CloudFormation into CDK. But what you can do is, if you start from scratch using SAM or using just CloudFormation, you can use Application Composer directly in your IDE for, literally, drag-and-drop application and generate code directly from there. You can use from the AWS console, or you can use directly from there.
9. Exploring Amazon Q in AWS Toolkit
AWS Toolkit offers various possibilities to rationalize serverless workloads and provides a fast feedback loop for developers. The last thing to explore is Amazon Q, which allows asking questions about code and finding optimization suggestions. Amazon Q enhances the IDE experience, simplifies development, and is not limited to serverless applications.
So as you can see, there are quite a lot of possibilities that are offered with AWS Toolkit to really rationalize what you are building in your serverless workloads in AWS, but moreover, also the possibility to, let's say, have fast feedback loop as a developer for what you need to build.
Now, the last thing that I want to show you is Amazon Q. So let's go back for a second inside our code. Let's, for instance, take this. So Amazon Q allows you to ask questions on a specific part of your code and then help you to understand what could be done better.
I'll just give an example. I created this, let's say, query to insert a bunch of stadiums into the database. So now I want to ask Amazon Q, do you know a more performant way to insert these records in Postgres? Now, he's thinking, and again, he's in preview, so it's not generally available yet, but just to give you an idea of the flavor of the things that you can find.
So, as you can see, with Q, I can start to create a sort of relation and an assistant that helps me to figure out how to do certain things, and this is, in my opinion, pretty great.
So, as you can see also with Amazon Q, we are adding new capabilities on your IDE in order to simplify the work that you need to do. We want to create a great developer experience for people like you that are building solutions using serverless but not only. Obviously, Amazon Q can be used not only for serverless. The beauty of this approach is that, as you can see, you have a bunch of tools that are already available on your IDE. You just need to install the right plugins and off you go.
So, I hope that you enjoy what you have seen, and if you have any questions, feel free to reach me out here in the conference or even remotely on my socials. So, thank you very much and enjoy the rest of your day.
Comments