July 17, 2019Corentin Doue9 min read
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:
I also wrote an article about how to Store your data in AWS Serverless architecture as a second part of this one.
The lambda is a service that runs code without provisioning or managing servers. It’s defined by :
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:
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.
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:
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.
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.
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 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 :
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).
The Simple Storage Service provides the cloud storage service of AWS.
S3 can send notifications when several events happen:
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:
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 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.
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.
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.
Web Developer at Theodo