Phase 4: Using Infra as Code on AWS

This part of the challenge was super interesting. We have to define the resources used on AWS for our project in a configuration file. Using a few commands, we can automatically deploy the resources, as defined in our configuration, using tools such as AWS Cloudformation, AWS Serverless Application Model and the open source Serverless Framework.

Coming from an infrastructure background, I understand how time consuming it is to set things up manually. There’s a saying where if you have to do the same thing more than three times, you better automate it. I try to follow this advice as much as possible.

Back end Infrastructure

As I was researching on how others have done serverless deployments, I found 2 popular tools; AWS SAM and the Serverless Framework. In both tools, the required components are defined in a YAML file and deployed to AWS as a Cloudformation stack.

After comparing both, I chose to use the Serverless Framework for this project. The framework does the heavy lifting for you to create these resources on AWS.

For example, below code snippet shows how we can define a Lambda function along with the API Gateway endpoints.

• It’s way easier to setup. Just a npm install -g serverless does it. SAM needs a couple of pre-requisites (Docker, SAM CLI).
• The documentation is comprehensive and easy to understand, with plenty of examples.
• It’s way easier to deploy a stack. Just a serverless deploy does it, compared to running few commands on sam.

  

• Testing your serverless application on the local machine is easy using few plugins. Also, the ability to have different environments on AWS is also a huge advantage when testing.
• Configuration template syntax is very similar. So it would be easy to switch between the 2 if required.

Lessons Learned

• When defining infra-as-code, it is important to keep it flexible. Use variables and don’t hard code values into the configuration.
• This approach meant I had to modify the Lambda function to be flexible as well, in the sense that it can identify the resources automatically provisioned by the framework. (For example, the deployed AWS regions, DynamoDB table etc.)
• Using a separate user for deployment with minimal IAM permissions (not be admin for all of your AWS account) that enables the framework to create the necessary resources. AWS CLI allows to configure different profiles that you can switch to when running CLI commands.

Front end Infrastructure

Although I had setup the static website hosting earlier in the console, I thought of attempting this using Cloudformation templates. This way I could use the same template for another project that might need a static website.

We define the resources required as shown in the example above and deploy them using using the AWS CLI command line.

Lessons Learned

• There are useful intrinsic functions within Cloudformation, like Sub, Split, Join which can help manipulate auto-generated or input values needed for different configurations.
• Need to get more familiar with using change sets, which help identify how your configuration changes are going to impact the existing stack. You can choose to apply those change sets based on the results. This is much better than going straight for the update-stack which might end up in a failed state if you missed something in the configuration.

Conclusion

In this task, we got to define the AWS resources needed for our project in a template and use simple commands to deploy them. This has been a huge time saver and also served as documentation for future reference.

Also using frameworks such as Serverless Framework helps speed up the development work, as now you can focus on the application code, knowing that the framework will take care of ensuring the resources are setup properly.

In the next part, we will be checking all of our code in source control (Github) and automating the build, test and deploy steps as part of CI/CD.