AWS Serverless Application Architecture
Intro
One of the big trends in web application architecture today is moving away from servers entirely to serverless applications. This website, for example, is a serverless application. It is hosted as a set of static files on a CDN, and it handles functions like search by making API calls.
This seems viable for something simple like a blog, but what do we do when an application needs to perform more complicated functions, like running calculations on data, and querying an internal API? These are the actions that used to necessitate a server. For example a common pattern is to use Express to create a REST server on top of Node.
Today however, companies like Amazon Web Services offer microservices that allow us to create API's and run functions on demand without the use of a server. If we couple that with a static front end, it's now viable (and preferable) to create an entirely static web application.
The advantages are threefold. Applications are faster, more secure and less expensive. Servers need to run all the time, which makes them cost more, and are inherently vulnerable to security breaches.
Static Application Overview
Let us take a look now at what a static application would look like using AWS microservices.
S3 (Simple Storage Service) is just what the name implies, a simple storage service. In this case we would deploy our built application files to an S3 bucket instead of an EC2 server, and then serve the files to users from that bucket instead of the EC2 server.
Then we would couple that with Cloudfront as the CDN to distribute those files horizontally. This would replace the horizontally scaled EC2 instances. Imagine how much less expensive it is to serve an S3 bucket through a CDN than it is to horizontally scale EC2 instances globally.
Next we can replace our Express REST API server using the API Gateway service. It allows us to create an API that is only used on-demand, instead of on a dedicated server that is up and running at all times waiting for requests.
Lambda behaves the same way, except it replaces logical functions that would typically also run on the Express server.
Databases as a managed service have been popular for a while (think MongoDB Atlas) and that is no exception here in this architecture. We are simply using the AWS version of Atlas, DynamoDB. It's just a managed non-relational database.
Lastly Cognito moves authentication out into a managed service, which will communicate with the rest of your services using API calls.
Partially Static Applications
This whole stack does not have to be used in unison. You could create a partially static application by simply cutting out a few of these services.
It would be entirely possible to host your application on a traditional EC2 server, and simply replace the API and logic functions with the static AWS microservices.
It might not be difficult for you to migrate however. For example right now I have an application that I am building that is hosted on EC2 instances. However I have already built out a whole CodeDeploy CI/CD pipeline for this application. And because it's a React application, I could simply change the deploy section of my pipeline to point to an S3 bucket, update my DNS routes in Route 53, and I just eliminated servers from my equation.
Comments
Recent Work
Basalt
basalt.softwareFree desktop AI Chat client, designed for developers and businesses. Unlocks advanced model settings only available in the API. Includes quality of life features like custom syntax highlighting.
BidBear
bidbear.ioBidbear is a report automation tool. It downloads Amazon Seller and Advertising reports, daily, to a private database. It then merges and formats the data into beautiful, on demand, exportable performance reports.