The Life of a Serverless Microservice on AWS

In this post, I will demonstrate how you can develop, test, deploy, and operate a production-ready serverless microservice using the AWS ecosystem. The combination of AWS Lambda and Amazon API Gateway allows us to operate a REST endpoint without the need of any virtual machines. We will use Amazon DynamoDB as our database, Amazon CloudWatch for metrics and logs, and AWS CodeCommit and AWS CodePipeline as our delivery pipeline. In the end, you will know how to wire together a bunch of AWS services to run a system in production.The LifeMy idea of "The Life of a Serverless Microservice on AWS" is best described by this figure:A developer is pushing code changes to a repository. This git push triggers the CI & CD pipeline to deploy a new version of the service, which our users consume. The load generated on the system produces logs and metrics that are used by the developer to operate the system. The operational feedback is used to improve the quality of the system.What is Serverless?Serverless or Function as a Service (FaaS) describes the idea that the deployment unit is a single function. A function takes input and returns output. The responsibility of the FaaS user is to develop the function while the FaaS provider's responsible is to execute the function whenever some event happens. The following figure demonstrates this idea.Some possible events:File uploaded.E-Mail received.Database changed.Manual invoked.HTTP API called.Cron.The cool things about serverless architecture are:You only pay when the function is executed.No under/over provisioning.No boot time.No patching.No SSH.No load balancing.Read more about Serverless Architectures if you are interested in the details.What is a Microservice?Imagine a small system where users have a public visible profile page with location information of that user. The idea of a microservice architecture is that you slice your system into smaller units around bounded contexts. I identified three of them:Authentication Service: Handles authentication.Location Service: Manages location information via a private HTTP API. Uses the Authentication Service internally to authenticate requests.Profile Service: Stores and retrieves the profile via a public HTTP API. Makes an internal call to the Location Service to retrieve the location information.Each service gets its own database, and services are only to communicate with each other over well-defined APIs, not the database!Let's get started!The source code and installation instruction can be found at the bottom of this page. Please use the us-east-1 region! We will use services that are not available in other AWS regions at the moment.CodeAWS CodeCommit is a hosted Git repository that uses IAM for access control. You need to upload your public SSH key to your IAM User as shown in the following figure:Creating a repository is simple. Just click on the Create new Repository button in the AWS Management Console.We need a repository for each service. You can then clone the repository locally with the following command. Replace $SSHKeyID with the SSH Key ID of your IAM user and $RepositoryName with the name of your repository.git clone ssh://$SSHKeyID@git-codecommit.us-east-1.amazonaws.com/v1/repos/$RepositoryName` We now have a home for our code.Continuous Integration & Continuous DeliveryAWS CodePipeline is a service to manage a build and deployment pipeline. CodePipeline itself is only responsible triggering integrations to do things like:Build.TestDeploy.We need a pipeline for each service that:Downloads the sources from CodeCommit if something changes there.Runs our test and bundles the code in a zip file for Lambda.Deploys the zip file.Luckily, CodePipeline has native support for downloading sources from CodeCommit. To run our tests, we will use a third-party integration to trigger Solano CI to run our tests and bundle the source files. The deployment step is implemented in a Lambda function that triggers a CloudFormation stack update. A CloudFormation stack is a bunch of AWS resources managed by CloudFormation based on a template that you provide (Infrastructure as Code). Read more about CloudFormation on our blog.The following figure shows the pipeline:The cool thing about CloudFormation is that you can define the pipeline itself in a template. So we get Pipeline as Code.The CloudFormation template that is used for service deployment describes a Lambda function, a DynamoDB database, and an API Gateway. After deployment you will see one CloudFormation stack for each service:We now have a CI & CD pipeline.ServiceWe use a bunch of AWS services to run our microservices.Amazon API GatewayAPI Gateway is a service that offers a configurable REST API as a service. You describe what should happen if a certain HTTP Method (GET, POST,PUT, DELETE, ...) is called on a certain HTTP Resource (e.g. /user). In our case, we want to execute a Lambda function if an HTTP request comes in. API Gateway also takes care of mapping input and output data between formats. The following figure shows how this looks like in the AWS Management Console for the Profile Service.The API Gateway is a fully managed service. You only pay for requests, no under/over provisioning, no boot time, no patching, no SSH, no load balancing. AWS takes care of all those aspects.Read more about API Gateway on our blogAWS LambdaTo run code in AWS Lambda you need to:use one of the supported runtimes (Node.js (JavaScript), Python, JVM (Java, Scala, ...).implement a predefined interface.The interface in abstract terms requires a function that takes an input parameter and returns void, something, or throws an error.We will use the Node.js runtime where a function implementation looks like this:exports.handler = function(event, context, cb) { console.log(JSON.stringify(event)); // TODO do something cb(null, {name: 'Michael'}); }; In Node.js, the function is not expected to return something. Instead, you need to call the callback function cb that is passed into the function as a parameter.The following figure shows how this looks like in the AWS Management Console for the profile service.AWS Lambda is a fully managed service. You only pay for function executions, no under/over provisioning, no boot time, no patching, no SSH, no load balancing. AWS takes care of all those aspects.Read more about Lambda on our blogAmazon DynamoDBDynamoDB is a Key-Value-Store or Document-Store. You can lookup values by their key. DynamoDB replicates across multiple Availability Zones (data centers) and is eventually consistent.The following figure shows how this looks like in the AWS Management Console for the authentication service.Amazon DynamoDB is a 99% managed service. The 1% that is up to you is that you need to provision read and write capacity. When your service makes more request than provisioned, you will see errors. So it is your job to monitor the consumed capacity to increase the provisioned capacity before you run out of capacity.Read more about DynamoDB on our blogRequest FlowThe three services work together in the following way:The user's HTTP request hits API Gateway. API Gateway checks if the request is valid — if so, it invokes the Lambda function. The function makes one or more requests to the database and executes some business logic. The result of the function is then transformed into an HTTP response by API Gateway.We now have an environment to run our microservices.Logs, Metrics, and AlertingA Blackbox is very hard to operate. That's why we need as much information from the inside of the system as possible. AWS CloudWatch is the right place to store and analyze this kind of information:Metrics (numbers).Logs (text).CloudWatch also lets you define alarms on metrics. The following figure demonstrated how the pieces work together.Operational insights that you get out-of-the-box:Lambda writes STDOUTand STDERR to CloudWatch logs.Lambda publishes metrics to CloudWatch about the number of invocations, runtime duration, the number of failures, etc.API Gateway publishes metrics about the number of requests, 4XX and 5XX Response Codes, etc.DynamoDB publishes metrics about consumed capacity, the number of requests, etc.The following figure shows a CloudWatch alarm that is triggered if the number of throttled read requests of the Location Service DynamoDB table is bigger or equal to one. This situation indicates that the provisioned capacity is not sufficient to serve the traffic.With all those metrics and alarms in place, we now can be confident that we receive an alert if our system is not working properly.SummaryYou can run a high-quality system on AWS by only using managed services. This approach frees you from many operational tasks that are not directly related to your service. Think of operating a monitoring system, a log index system, a database, virtual machines, etc. Instead, you can focus on operating and improving your service's code.The following figure shows the overall architecture of our system:Serverless or FaaS does not force you to use a specific framework. As long as you are fine with the interface (a function with input and output), you can do whatever you want inside your function to produce an output with the given input.