Why Serverless?

This application was the perfect use case for going serverless without having to invest a lot of time or money into the architecture.

We justified going down the route of using AWS Lambda with the following criteria: 

• Disconnected: Most of the services were connecting to an API that the main application didn't need to connect to.
• Lightweight: The logic inside was lightweight and didn't average more than a few seconds or processing time, even on heavy load.
• Scalable: This was the largest area of concern, with Lambdas our resources scale as we need them to.
• Flexible: We only needed to process data at certain intervals or times of the day, we didn't need a powerful application server running 24/7.
• Cost: We only pay for what we use, in this case our average run time per day was less than 1 minute.

AWS Architecture

Cloud Watch / SNS:

CloudWatch was utilized for two of the four lambdas to help fire them on a specific interval. Instead of building out a queueing mechanism like we may do with Hangfire in .NET Core, we decided to use CloudWatch events. 

Advantages of using CloudWatch over an application-side queue: 

• Less technical debt and maintenance
• If our application server went down, our queue would still be running
• The event mechanism integrates directly as a Lambda trigger
• Intervals can be changed without deploying new code

SNS (Simple Notification Service) was utilized after the  CloudWatch triggered Lambas had fired. Part of the logic inside of the CloudWatch fired Lambdas checked to make sure results were returned. If no results were found, we continued to check on an interval until they were. Once the results were identified, we sent an SNS message to a queue. On the other end of the queue were two Lambdas listening for messages, once received they knew they could begin running. 

Benefits of using SNS:

• Reliably deliver messages without ties to the application itself
• Easily scales with higher demand
• Keeps messages private through topic-specific channels

Managing Configurations:

One of the more important aspects of deploying applications is how their credentials are stored. You don't want values stored in a version control repository or anywhere that unauthorized users can access them. We used Parameter Store inside of the System Manager to configure different environment variables. Every time a Lambda was fired, we passed through an environment type that told AWS what parameters to use.

AWS automatically injects the CLI profile for other services like SNS and S3.