aws

Serverless computing on AWS #3 Project structure

by
published on

Before starting to develop a serverless application I setup a project and a robust deployment process.

Project structure

 My application is split into two projects:

  1. Web application
  2. API

The Web application is hosted on the AWS S3 storage service and exposed via AWS Cloudfront content delivery network.

The API methods are developed in NodeJS (Javascript), hosted as AWS Lambda functions and exposed via the AWS API Gateway. The Serverless Framework automates the creation of the API environment by generating and executing AWS CloudFormation instructions. AWS CloudFormation provides a common language for provisioning AWS resources.

Source code repository and build service

In developing the serverless application I made use of 3 AWS services:

  1. AWS CodeCommit - a Git source code repository 
  2. AWS CodeBuild - a service responsible for building software. AWS Codebuild provisions a build server, configures it, pulls source code from CodeCommit, builds it and runs automated tests against it
  3. AWS CodePipeline - provides a continuous delivery pipeline from source code commit to provisioned environments and deployed software in production

What's the point of this?

As changes are made to the application and committed, the build process is automatically initiated. The Serverless framework makes any necessary changes to application resources, for example, creating file storage buckets in AWS S3. 

Once the resource changes have been made the application builds and tests the software. If the resource changes take and the tests are successful, the software will be deployed to a production-like environment. If the tests fail, or there is an issue with any of the resource changes, the deployment will be rolled-back.

This makes for a very productive development environment, where changes are deployed to a production-like environment frequently and issues are detected early (while they are still fresh in the developer's mind).

In the old days software developers would work independently on large batches of work. A developer's work would be integrated with the rest of their team's work infrequently and this would often result in bugs. With small batch sizes and frequent integration of work, these issues still surface but they're much easier to resolve as they aren't buried in large batches of other work, nor in the deepest recesses of the developers' memory. 

Comments