Understand AWS Serverless architecture in 10 minutes

Serverless provides scalability. It also solves the waste of having servers up and running when no one needs them, by instantiating and running your business functions only when needed. 

That’s why at Theodo we are excited about serverless and developing serverless apps. But building a serverless app requires one to change some architecture paradigms, so it is important to understand how AWS implements serverless and what modules they provide for such an architecture. 

The first important modules to know are: the lambda, the computing unit in serverless, and the nine services which can trigger one. This article is an overview of these:

• ALB or API GateWay V1: Http endpoints
• API GateWay V2: WebSockets endpoints
• SNS: PubSub service between AWS Services
• SQS: Queue service between AWS Services
• DynamoDB stream: trigger events on actions on DynamoDB
• S3: Cloud Storage service
• Kinesis Data Streams: high volume data stream
• CodeCommit: GitHub in AWS

I also wrote an article about how to Store your data in AWS Serverless architecture as a second part of this one.

Lambda

The lambda is a service that runs code without provisioning or managing servers. It’s defined by :

• The runtime: it is the programming language used to write the code of the function. Lambda natively supports NodeJs, Python, Java, Go, Ruby and .NET but it’s also possible to implement custom runtimes such as a Php one.
• The handler: it is the function written in the runtime language which will be executed when the lambda is triggered. It takes two arguments, the event which triggered the lambda and the context of this event and can do whatever you want while respecting the AWS lambda’s limits. It is also recommended to follow some good practices.
• The events which will trigger the function.

Trigger the lambda

Serverless infrastructure is an event-driven infrastructure. Building it means to create the right event to trigger the functions. In AWS there are nine services which can trigger the lambdas:

ALB / API GateWay V1: HTTP

The Application Load Balancer and the API GateWay V1 have the same roles, they create Http endpoints and redirect the Http requests to AWS services such as lambdas.

You can define routes and which lambda they will trigger to build an API. The lambda is triggered with the Http request as an event and the output of the function will be the Http response.

The API GateWay has some additional features than ALB (Authentication, Authorization and Request and Response mapping) but is more expensive.

API GateWay V2: WebSocket

The API GateWay V2 creates a WebSocket endpoint, keeps the WebSocket opened with the web client and forwards the messages from the client to lambdas. The SDK of the API GateWay allows sending back a message to the client from a lambda knowing its id of WebSocket connection.

There are three default actions which can trigger lambdas:

• $connect which is dispatched when the WebSocket is established.
• $default which is dispatched when a message comes from the client.
• $disconnect which is dispatched when the WebSocket has been closed.

It’s also possible to route the messages to lambdas according to their content. By default, the key “action” of the body of the message is used to route the message to the corresponding lambda.

Even if the documentation and interfaces of API GateWay V1 and V2 are shared, it’s two separate services. If you need both HTTP and WebSocket you will need two API GateWays.

SNS

The Simple Notification Service is a PubSub service between AWS services.

The use case with lambda is to communicate between lambdas: a first lambda publish a message in a topic and a second lambda which subscribes to this topic is triggered with the message as the event.

SQS

The Simple Queue Service is a Queue service between AWS services.

The use case with lambda is also to communicate between lambdas: a first lambda send a message in a queue and a second lambda will consume the message as the event.

The difference with SNS is that your lambda can consume the queue with a batch of messages (up to 10) and a message could only be consumed once.

DynamoDB stream

DynamoDB is the NoSQL DataBase of AWS.

The DyamoDB stream is a stream of events dispatched when a service creates, updates, or deletes items in a table of the DynamoDB. The stream message could contain the type of operation (insert, update, delete) and one of the following :

• only the key of the modified item
• only the whole new item
• only the whole old item
• both new and old items.

A lambda can listen to the stream of a specific table and be triggered to each activity with the stream message. The messages could be batched (up to 1,000).

S3

The Simple Storage Service provides the cloud storage service of AWS.

S3 can send notifications when several events happen:

• An object is created
• An object is removed
• An object is restored from archive
• An object is lost from A Reduced Redundancy Storage (RRS)

There are lots of sub-events that you can find here.

The notification contains the type of event and information about the object that has been modified.

The notification can be sent to:

• SNS (and then trigger lambdas cf SNS)
• SQS (and then trigger lambdas cf SQS)
• Lambda

Kinesis Data Streams

The Kinesis Data Streams collect and process large streams of data records in real-time. The lambda could process the data of the stream by being triggered by the data as the event.

1. A custom app writes records to the stream.
2. AWS Lambda polls the stream and, when it detects new records in the stream, invokes your Lambda function.
3. AWS Lambda executes the Lambda function by assuming the execution role you specified at the time you created the Lambda function.

The differences between Kinesis and SQS are that Kinesis could have multiple consumers and is designed to stream huge amounts of data. But Kinesis is harder to implement and more expensive.

CodeCommit

CodeCommit is the version control service of AWS (GitHub like). Some continuous integration actions could be implemented by publishing in an SNS topic or triggering directly lambdas.

Warning: you can’t test or build your code with a lambda, to setup a CI/CD, use a pipeline with an EC2. With the lambdas, you have access to the data and meta-data of the repository. For example, it could be used to copy static code to S3.

Security

To build your architecture you also need to know how you will secure it.

The simplest and recommended way is to give an IAM role to your lambdas which contain the right to interact with the other services. Do not give too much right to your lambdas, try to create a role with only the rights needed to execute your lambdas.

Conclusion

This was a brief overview of the typical services you use in a serverless architecture on AWS. Of course there is a lot more about the topic!

Another type of important service is storage. As Lambdas are short-lived, you need to store everything that needs to be shared between two executions of lambdas. If you want to learn more about the storage services, I invite you to read the second part of this article: Store your data in AWS Serverless architecture

Serverless is very new and the possibilities evolve very quickly as AWS regularly adds new serverless features to its services. This article will probably need recurrent updates, feel free to suggest it in comments.