Building Serverless Architectures

Cagatay Gurturk

• Publisher: Packt Publishing
• Year: 2017
• eBook ISBN: 9781787128019
• Edition: 1
• Topic: Computer Science
• Subtopic: Programming
• Index: Computer Science

Build scalable, reliable, and cost-effective applications with a serverless architectureAbout This Book• Design a real-world serverless application from scratch• Learn about AWS Lambda function and how to use Lambda functions to glue other AWS Services• Use the Java programming language and well-known design patterns. Although Java is used for the examples in this book, the concept is applicable across all languages• Learn to migrate your JAX-RS application to AWS Lambda and API GatewayWho This Book Is ForThis book is for developers and software architects who are interested in designing on the back end. Since the book uses Java to teach concepts, knowledge of Java is required.What You Will Learn• Learn to form microservices from bigger Softwares• Orchestrate and scale microservices• Design and set up the data flow between cloud services and custom business logic• Get to grips with cloud provider's APIs, limitations, and known issues• Migrate existing Java applications to a serverless architecture• Acquire deployment strategies• Build a highly available and scalable data persistence layer• Unravel cost optimization techniquesIn DetailOver the past years, all kind of companies from start-ups to giant enterprises started their move to public cloud providers in order to save their costs and reduce the operation effort needed to keep their shops open. Now it is even possible to craft a complex software system consisting of many independent micro-functions that will run only when they are needed without needing to maintain individual servers.The focus of this book is to design serverless architectures, and weigh the advantages and disadvantages of this approach, along with decision factors to consider. You will learn how to design a serverless application, get to know that key points of services that serverless applications are based on, and known issues and solutions.The book addresses key challenges such as how to slice out the core functionality of the software to be distributed in different cloud services and cloud functions. It covers basic and advanced usage of these services, testing and securing the serverless software, automating deployment, and more.By the end of the book, you will be equipped with knowledge of new tools and techniques to keep up with this evolution in the IT industry.Style and approachThe book takes a pragmatic approach, showing you all the examples you need to build efficient serverless applications.

Hello Internet

In previous chapters, we looked at how to build standalone, event-based Lambda functions. Lambda functions were code pieces living in the cloud that respond to different events, such as a new file in S3 bucket or an SNS notification, such as what we will see in following chapters. However, at this stage, maybe our simplest requirements would be to invoke the lambda function with an HTTP request, thus having a fully serverless REST API.

Thanks to API Gateway, it is possible to create a REST API that responds to HTTP requests. API Gateway replaces servlets, servlet containers, application servers, and basically the HTTP layer. When a request arrives at API Gateway, it decides where to route this request, transforms the input, invokes the "backend", and sends back the response to the client.

API Gateway can proxy to many types of backends, and it can be configured separately by the REST resource and the HTTP method. It can proxy requests to a custom HTTP API, to an AWS API, or-most importantly-to a Lambda function. For example, you might have an on-premise REST API and you can route the users resource of your API to that application, while you can route other requests to lambda functions. You can even proxy to AWS APIs, so you can allow users to upload their pictures to an S3 bucket after authorizing them via another Lambda function. This is one of the examples we will see in this book and you will learn how easy it is to build an image upload service using AWS offerings.

In this chapter, we will introduce API Gateway and connect some Lambda functions to HTTP resources and methods. This chapter is extremely important because we will introduce complicated CloudFormation structures and a lot of new concepts. Additionally, we will cover CloudFront, the CDN solution of AWS. With CloudFront, we will enable some HTTP features such as HTTP/2 or IPv6, which are currently not available for API Gateway out of box.

As for this chapter, we will just cover how to create a REST API using the very simple test function we developed in previous chapters. Throughout the book, we will develop more Lambda functions and REST endpoints. These will extend our API Gateway configuration, but it is important that you understand the basics for now. Also, you will explore how to configure a CDN that can be useful even for classical approaches. At the end of the chapter, we will introduce our second Lambda function, which will authorize API calls.

We will cover the following topics in this chapter:

• Setting up API Gateway
• Creating a REST endpoint using our current Lambda function
• Manipulating an HTTP request data and the incoming Lambda response
• Setting up CloudFront CDN for enhanced HTTP properties
• Decoupling a Lambda function to authenticate API calls with a Bearer token

Setting up API Gateway

In this section, we will start with extending our CloudFormation template.

First of all, we should start with some boilerplate. In the previous chapter, we had mentioned CloudWatch Logs, the service that AWS provides to store logs in a central place. API Gateway also uses CloudWatch to store HTTP logs and, like all services that try to access to other services, needs an IAM role. In this IAM role, we should give access to the apigateway.amazonaws.com service to access the CloudWatch logs and deliver this role to API Gateway as the AWS::ApiGateway::Account resource. Now let's open our CloudFormation template and just prepend these lines to the Resources section:

 "ApiGatewayCloudwatchRole": { "Type": "AWS::IAM::Role", "Properties": { "AssumeRolePolicyDocument": { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "apigateway.amazonaws.com" ] }, "Action": "sts:AssumeRole" } ] }, "Path": "/", "ManagedPolicyArns": [ "arn:aws:iam::aws:policy/service-role/AmazonAPIGatewayPushToCloudWatchLogs" ] } }, "ApiGatewayAccount": { "Type": "AWS::ApiGateway::Account", "Properties": { "CloudWatchRoleArn": { "Fn::GetAtt": [ "ApiGatewayCloudwatchRole", "Arn" ] } } } 

Considering you may be familiar with the syntax, you should understand what are we doing here. Basically, we are creating a role with the arn:aws:iam::aws:policy/service-role/AmazonAPIGatewayPushToCloudWatchLogs built-in IAM policy, which allows you to write to the CloudWatch role. In the AssumeRolePolicyDocument section, we indicate that apigateway.amazonaws.com , the IAM entity API Gateway uses internally, can assume the role, so it can write to the logs. If you deploy the project at this stage and open the Settings tab of API Gateway Console on AWS Console, you shall see the newly created IAM role in the CloudWatch log role ARN box. This is a one-time step that should be done once per account per region.

Creating the API

Following the REST principles, API Gateway consists of different parts: REST API, stage, resources, and methods. If we analyze an API Gateway URL, it is easier to understand https://51xda3cqkj.execute-api.us-east-1.amazonaws.com/production/ping.

Here, 51xda3cqkj is the API ID, while production is the stage and ping is a resource. When you set up an API Gateway, you first create a REST API, so reserve an API ID that will build the URL of the API in future. Then, you create resources with static routes such as /ping or with parameters such as /users/{id} and finally, you create HTTP methods under these resources.

API Gateway offers a couple of options as the backend to HTTP methods. For instance, you can proxy native AWS APIs with limited permissions, so, for example, your users can upload files to S3 on your behalf. You can use API Gateway as a proxy to an existing custom REST API you built with another platform, and finally, and most importantly for us, you can invoke Lambda functions to process a request and return a response. For all the options, API Gateway provides a set of request and response transformation possibilities. For example, as we already know, Lambda functions accept some JSON strings as input and return JSON responses. They do not know, and mostly are not interested in, who is invoking them; they just process the input and return an output. At this stage, the transformation capabilities of API Gateway become very important. Using API Gateway, we will map HTTP request parameters to JSON properties and create a JSON object to send to the Lambda function. Also, we can map back the returning object to HTTP response parameters such as response headers or the response body. API Gateway uses Apache Velocity Template Language (VTL) for this mapping process, and in the following sections, we will be writing some transformations with this language.

To start with creating our API Gateway stack, we can add a AWS::ApiGateway::RestApi resource type just below the AWS::ApiGateway::Account we just created. AWS::ApiGateway::RestApi is a simple resource with minimum properties:

 "RestApi": { "Type": "AWS::ApiGateway::RestApi", "Properties": { "Name": { "Ref": "AWS::StackName" } } } 

For the sake of simplicity, we named the API using the AWS::StackName variable, which means that if you are following our naming convention, this will be serverlessbook.

If you want, you can deploy now; open the API Gateway console and check whether your new API is created.

Creating the resource

After we create the API, we can now create our first resource, which will be a test resource, and remove it later. We can add these lines to the end of our resources in order to create the resource:

 "TestResource": { "Type": "AWS::ApiGateway::Resource", "Properties": { "PathPart": "test", "RestApiId": { "Ref": "RestApi" }, "ParentId": { "Fn::GetAtt": [ "RestApi", "RootResourceId" ] } } } 

If we analyze this resource, we can see that the resource type is AWS::ApiGateway::Resource . In the properties part, we can see PathPart , and we set it as test. It will create a REST resource and will be invoked when https://base_url/test is requested. Here, we can use brackets to create a dynamic parameter. For example, {test} would match both https://base_url/1 and https://base_url/2, and we can use these parameters to pass to our Lambda function. The RestApiId property refers to the AWS::ApiGateway::RestApi resource we just created, and ParentId refers to the RootResourceId value of the RestApi resource.

This is a bit tricky. Normally, you create resources referring to their parent resources. For example, to create a resource such as /users/{id}/picture, you have to create the users, {id}, and picture resources separately, and for each resource, you have to refer to the previous one. But for the users resource, you do not have a parent resource. In that case, you should refer to the RootResourceId value of the REST API.

Creating the method

After we create the resource, we can create the very first HTTP method under that. This part is maybe the trickiest one because it needs many configurations and we are going to introduce new concepts. First, let's add the method configuration and then let's discuss it line by line:

 "TestGetMethod": { "Type": "AWS::ApiGateway::Method", "Properties": { "HttpMethod": "GET", "RestApiId": { "Ref": "RestApi" }, "ResourceId": { "Ref": "TestResource" }, "AuthorizationType": "NONE", "RequestParameters": { "method.request.querystring.value": "True" }, "MethodResponses": [ { "StatusCode": "200" } ], "Integration": { "Type": "AWS", "Uri": { "Fn::Sub": "arn:aws:a...

Table of contents

• Title Page
• Copyright
• Credits
• About the Author
• About the Reviewer
• www.PacktPub.com
• Customer Feedback
• Preface
• Getting Started with Serverless
• Infrastructure as a Code
• Hello Internet
• Applying Enterprise Patterns
• Persisting Data
• Building Supporting Services
• Searching Data
• Monitoring, Logging, and Security
• Lambda Framework