AWS Lambda is just one service out of upwards of 160, each performing its own function for its own use cases. When we develop code for Lambda, there are often other activities that we need to do around that. I'm referring to the authoring, life cycle, and management activities that are necessary as we evolve our service. When we need to add more functionality, we should look to the ecosystem to see what AWS can provide. Using tooling from within the ecosystem can save us setup time and effort in procuring a new tool elsewhere. We can instantly make use of the native integration that the service will naturally provide and know we are covered under our existing support agreement with AWS if anything goes wrong. An additional benefit is that, when we come to declaring all of our infrastructure as code, we can include our extras bundled in the same project structure.
Let's quickly touch on some of the things from the ecosystem that we can use when we develop Lambda functions. When we're authoring, we might be working solo or in distributed teams, following a git branching type of workflow to cut code and merge into the trunk for deployment. We can support this workflow using AWS Cloud9, a browser-based IDE. Developers working on the same function can now be in the same workspace, thus making it easier to collaborate and troubleshoot problems. When you're ready to deploy, the native integration can package and deploy straight to Lambda from the IDE.
In our journey of creating robust enterprise code, we also need a way to enforce versioning and control of deployments. A service such as AWS CloudFormation allows us to declare our cloud and serverless resources as code. You could specify your Lambda functions and any extra resources that are needed, such as S3 buckets or DynamoDB tables in a YAML or JSON template, give the template to CloudFormation, and the resources will be provisioned for you. Any updates to your Lambda function can be deployed by updating and deploying the template again. This allows you to version the surrounding infrastructure, as well as the Lambda code. It also allows you to store your infrastructure definitions right beside your function code, if you're that way inclined, bringing the infrastructure and programming worlds closer together.
Your Lambda function code will most likely need to follow a software development life cycle where code is tested before it is promoted to the next environment, eventually making it to production. AWS CodePipeline can orchestrate and automate the steps for moving the function code through the environments, with AWS CodeBuild running automated tests and deploying to the necessary environments. We'll go into detail about how this works in Chapter 8, CI/CD with the Serverless Framework.
This section was a brief introduction to make you aware of what can help you when you're developing Lambda functions.