get started developing applications for the AWS serverless platform and how your life as a developer changes when you move from a traditional application development environment to a serverless one.
There are a number of benefits that our customers realize when moving to a serverless architecture, including an improved cost model for their infrastructure and the ability to scale their costs along with the usage of their application.
The AWS serverless platform is comprised of a number of different services that take care of everything from compute to api management, data persistence and messaging. In this course will be focused on the AWS Lambda service, which is a serverless compute platform that allows you to bring your own code.
Now this course assumes that you're already familiar with the basics of the AWS Lambda service. But to review, AWS Lambda allows you to bring your own code and have it run in response to events. So, when an event source triggers your function, your code is run and it can interact with other downstream services such as databases and message streams.
Now it's important to understand that the permission model for Lambda has two different components.
On the front end the event sources that are allowed to trigger your Lambda function are controlled by an IAM resource policy and the resources that your function is allowed to interact with are controlled by the execution role.
So, if you were to have an Amazon S3 bucket triggering a Lambda function, which then put some data into a DynamoDB table for instance, the Amazon S3 permissions to invoke the function would be managed by the resource policy, while the DynamoDB access for your code itself would be managed by the execution role.
WRITE LAMBDA FUNCTIONS
So, let's get started by taking a look at some of the best practices for writing code for Lambda functions. Oftentimes when developers get started with AWS Lambda, they use the AWS Management Console to write their first functions.
However, when you start developing production applications, it's important to move away from that initial experimental kind of phase and start using standard application development tools and practices that you're used to.
One of the most important lessons to take away from this is that all of the best practices that you've learned about software development still apply when it comes to developing serverless applications. You should still be writing good quality, object-oriented code and build and deploy your applications using standard industry practices.
So, let's talk a little bit about how you might organize the code within your Lambda function. Every Lambda function has a handler method. You can think of a handler method, like a main method in a JAVA application. And remember that when you're building Lambda functions, just like it doesn't make sense to include all of the business logic and all of the code for your application into a single main method, you should also be splitting up the functionality of your Lambda functions into multiple classes and functions that are called from that primary entry point.
A typical layout for a Lambda function might look something like this, where we divide the functionality into multiple layers. It starts with the handler function that we just talked about where you would set up your function configuration. Any of the Lambda specific code needed to integrate with the Lambda runtime should go here, but you shouldn't include any of the actual business logic for the function in the entry point itself.
Instead, you would put that business logic into a controller class that's responsible for handling the actual event itself and doing all of the business specific functionality for that particular method.
Finally, service classes can be used to abstract away any external services that your function needs to interface with and provide business interfaces into those external services.
MANAGING SERVERLESS APPLICATION
Transcript
–
So now that we've taken a look at some of the best practices for writing code for your Lambda function, let's talk a little bit about the overall development work flow that's necessary when you move from a traditional application environment into a serverless model.
Just like we talked about, the best practices for writing code when it comes to using Lambda don't really change from a traditional application development world. Also, the tool chain that you're using shouldn't have to change much, either. You should still be using standard source control, IDEs. build and deployment tools when you're building functions in Lambda as you would when you're building traditional applications.
The one addition to that is using a serverless application framework to help manage all of the components of the application. In a traditional application, you would typically use a build tool like Maven or Gradle to create a compiled application binary that then goes and gets deployed onto a cluster of servers. In the serverless world, there's an additional step where you need to package and deploy your code out to the Lambda service, and you're probably going to be breaking your code up across multiple different Lambda functions and resources. And this is where an application framework really becomes valuable.
Typically, when you're deploying a serverless application, there are a number of different steps required in order to actually move from development into a running application. This includes building the code, zipping it up, sending it to Amazon S3, managing all of the different execution roles, and IAM policies, creating the function API and other resources that are integrated to your application, and then finally updating those integrations and creating any other components that are necessary. Now, typically, when we think about a complex process like this, we would use a tool like AWS CloudFormation to script out and declare all of the different resources that need to be created, and to help with the orchestration there.
However, with a serverless application, there are a lot of different resources that need to be created. So even to create a relatively simple API for instance, that has a single method with one function backing it and maybe a simple DynamoDB table, there are a number of different resources and configuration components that you would need to define inside of a CloudFormation template in order to get that application launched.
One of the main benefits of using an application framework such as the AWS Serverless Application Model (SAM) is that the code required to define all of those application components is dramatically simplified.
So now we can take a look at an example SAM template here, where we're defining a function as well as the events sources and API structure, all in a few lines of code. So, compared to the previous CloudFormation template that would've taken potentially hundreds of lines to define our application, we can now do the same thing in much, much less code. It makes it more maintainable and easier to develop and scale overall as you build larger and larger applications.
So, let's talk a little bit more about AWS SAM, which is an example of one of these application frameworks. AWS SAM provides a CLI that allows you to easily package and deploy your applications. The first step in packaging a new application is to run the SAM package command. That command is going to take all of the function code or compiled binaries within your application, create a zip archive that's ready to be deployed to Lambda, and upload that to Amazon S3.
It's then going to modify the template definition that you have to update the code uri from a local system path to the S3 path that's been created by the tool in the previous step. So now, instead of you being responsible for zipping and packaging this application, the tool itself is automating all of that process for you.
Once you've created a package template using the SAM CLI, it can then be deployed using the AWS CloudFormation service. So, this allows us to simplify the overall deployment process we looked at previously to two simple CLI commands. And now we can manage our application deployment across multiple accounts and environments easily and repeatably in order to provide an automated deployment mechanism.
So now that we have a good mechanism for packaging and deploying applications, let's talk about how you should be organizing your application code into a source code repository. Oftentimes customers struggle to decide how many functions should live within a single repository. On the one hand, you could put a single function inside of an individual repository and create a new repository for every single individual Lambda function that you create. Or you could put all of the functions that you build into a single source code repository. However, both of these options have drawbacks and really require a different mindset when you're thinking about how to organize the repositories.
Instead of being focused on individual functions, think about how your application is divided into services. A service should be comprised of one or more functions, along with all of the other AWS services, and resources necessary for that particular piece of functionality to work.
Each of those services can then be defined in an individual template and stored in a single repository. This way you have a separate repository for every service but still have multiple Lambda functions in each one of your repositories.
There are a couple of different ways you can approach providing developers with a dedicated sandbox environment. On the one hand, you can create separate accounts for each developer. This is typically the most flexible and provides the best isolation between developers. However, there is some overhead that you need to be aware of in terms of your ability to secure and monitor all of these different accounts. Assuming your organization already has the infrastructure in place to create and manage multiple AWS accounts effectively, this is probably the best way to go.
On the other hand, you can use a single shared development account that all developers use to deploy multiple stacks into. The nice thing about using a framework like we discussed in the previous section, is that each developer can deploy the same code multiple times, using something like AWS SAM and simply create multiple stacks within the same environment and test different versions of the code side by side.
Manual:
TEST AND DEBUGGING SERVERLESS APPLICATION
Top comments (0)