11. March 2017 12:45
by Aaron Medacco

Hosting a Serverless Website on Amazon Web Services

11. March 2017 12:45 by Aaron Medacco | 0 Comments

As cloud providers such as AWS keep growing their customer base and offering new services, there has been a rising interest in adopting serverless code execution models. Make no mistake, "serverless" isn't just a buzzword. The benefits of adopting such a model are real and substantial implemented under the appropriate circumstances. 

In this post, I'll provide a simple architecture available on Amazon Web Services that is both serverless and fulfills a common need: hosting a website. Below, you can see the bird's eye view of how Amazon's services can come together to deliver this.

Understand that I may use "website" and "web application" interchangeably in this post.

AWS Serverless Website

A traditional web application can be broken down into the following components: front-end (styling, behavior and structure of the interface), back-end (business logic and object management), and data (the database, it's schema, the indexes, etc.) These segments of what comprise a web application are easily mapped to the services used to create a serverless website on Amazon Web Services.

Hosting a Static Site in S3 (Front-End)

This is where you serve the files that make up your website's front-end. HTML, CSS, and Javascript among just about anything else can be stored and served from S3. You simply create a bucket with the name of your domain, upload your static files, enable public access, and flip the switch to enable static website hosting. When updates need to be made, you can manage the bucket contents like you would a file structure.

Writing Your Code with Lambda (Back-End)

Since were not deploying push packages to servers or virtual machines, we'll manage our code with Lambda.

With AWS Lambda, you can write code in one of a variety of different languages and perform the same operations and business logic a traditional back-end would. There are a number of benefits that come as a result of this.

First, no management. You no longer need to manage the servers where the code is living. No installing operating systems, performing updates, setting up drives, etc.

Second, scalability. As your website receives more traffic, you don't need to bother provisioning additional infrastructure to service the increasing number of requests. Lambda will use Amazon's infrastrucutre (which is a lot) to handle your load. While there are soft limits to the number of Lambda functions that can run concurrently on an AWS account, this number can be increased as needed by contacting AWS support.

Third, high availability. Your serverless Lambda code does indeed still run on servers, but not those you might otherwise provision yourself. Lambda might execute from any machine living in any one of several data centers maintained by Amazon. Therefore, your code will continue running as long as the Lambda service is online and won't go down when a bonehead developer elects to shutdown an instance rather than disconnecting.

Fourth, cost. The pricing model for Lambda, like most AWS services, is based on usage. You are charged for the number of requests made to each Lambda function plus the time and memory your code allocates to complete it's execution. The detailed pricing model can be found here. Obviously, there are going to be cases when Lambda is not cheaper than hosting an application on EC2 instances. However, there are also situations where usage for the month will be below the free tier, in which case your serverless compute is completely free. 

Storing Your Data with RDS or DynamoDB (Data)

You have options when it comes to storing your website's data on AWS. For an website expecting to perform several OLTP operations and where join operations will be common, RDS is the obvious choice. For sites that require lookups but don't require joins or SQL querying, DynamoDB provides an alternative. Regardless, both services are managed for you. And while RDS does involve choosing a class of server to run your database, Amazon takes over the server ops. Both services can be configured to be scalable and highly available.

You could also manage your own database on an EC2 instance, which is appropriate in some cases, but not a serverless solution to storing your data.

Exposing Your Functionality via API Gateway

API Gateway is the glue that connects the interface of your application with the code you write in Lambda. The functions you write with Lambda can serve as the backing to endpoints you define in API Gateway. Therefore, AJAX functionality served from the Javascript files in your website's S3 bucket can make calls to your API's endpoints to perform back-end functions handled by your Lambda code. 


It's worth mentioning that all the available options for implementing a cloud-based solution should be considered before marrying yourself to any one path. Just because serverless is the new Kool-Aid, does not mean it is the best route in all cases. Very often it's the case that both traditional and serverless computing are combined to arrive at the best result.

Additionally, many websites require additional features such as data transformation, sending notifications, etc. which I haven't included for brevity. Lambda in conjunction with other services provided by Amazon can be combined to achieve these, too.


Copyright © 2016-2017 Aaron Medacco