Serverless Architecture with AWS Lambda, API Gateway, Cloudfront, S3 and DynamoDB

If 2015 saw the rise of Docker Containers & Micro-services then 2016 is undoubtedly going to be about Serverless architecture.

Late in 2015 AWS announced a preview of a service called AWS Lambda moving from a pure IaaS provider into the PaaS world with one feel swoop. Now AWS is releasing so many new services and features a week that you may have missed this, but in my opinion it is a game changer and I’m going to try to demonstrate why.

What on earth is Lambda?

“AWS Lambda is a compute service that runs your code in response to events and automatically manages the underlying compute resources for you.”

“When using AWS Lambda, you are responsible only for your code. AWS Lambda manages the compute fleet that offers a balance of memory, CPU, network, and other resources.”

Just think about those statements for a second,

In developer terms a Lambda is simply a single function with an input and output, forget microservices this is a nanoservice.

At the time of writing you can write your Lambdas in Node.js, Java or Python but I would expect support for other languages to be coming soon although I don’t have high hopes of .NET being supported anytime soon given the memory overhead.

AWS Lambda on it’s own is not very interesting but it’s the wealth of integrations with other AWS Services where the power comes.

Supported services:

API Gateway
Dynamo DB Streams
S3
SNS
SES
Cognito
Cloud Trail
CloudFormation
CloudWatch
Kinesis

Serverless

Enter a truly serverless architecture. To make this possible the key integration is with API Gateway which allows to execute Lambas in response to incoming HTTP requests, meaning you’re entire API backend can be developed this way (without a single EC2 Instance, or Docker container in sight).

Single Page Application Example

I’m going to demonstrate at a high level how you could implement a completely serverless single page application using just a few AWS services.

Given your typical single page application you would need to use the following AWS services:

Responsible for storing static web assets HTML, JavaScript, CSS & Images.
WebsiteHosting enabled

API Gateway

Used to define the HTTP Endpoints used by the Web Client

Cloudfront

CDN for serving web assets using S3 as the origin
CDN for the API Gateway optimize latency between the end user and the origin

AWS Lambda

Functions which are run when API Gateway endpoints are called.

DynamoDB

Used to store the data

From a high-level this is what the architecture looks like.

Conclusions

I’ve attempted to demonstrate a very simple example about how you can make use of AWS Lambda today to implement a serverless architecture, however this only scratches the surface of what is possible and in my next post I will expand on this example and show how you can implement more complex serverless implementations.

It wasn’t all smooth sailing and they were a few things which I found annoying which I hope AWS will resolve in the future.

AWS Certificate Manager doesn’t yet work with API Gateway
AWS Code Deploy which is highly EC2 centric doesn’t yet provide a way to deploy your Lambdas or API Gateway resources so you’ll still need a Build Server to do this, however if you want to go pure serverless for your CI then check out Solanos Labs or Jenkins which both integrate with AWS Code Pipeline.