How to Start the Serverless Journey: Serverless Framework Deep Dive

Engineers are understandably attracted to serverless as it allows them to execute code in response to events without the complexity of building and maintaining infrastructure. In a previous article, we shared how a serverless framework allows you to develop, deploy, test, secure and monitor any number of serverless applications with increased agility and a lower cost of ownership.  While we compared different models and gave a high-level overview of serverless with example use cases, in today’s article, we’ll highlight how Flux7 implemented an AWS serverless framework for one of its customers with best practices. 

This retail organization wanted a serverless framework for the benefits it brings in delivering business value and innovation at a low operating cost. Moreover, the retailer has a large number of remote, on-demand applications to manage. As some of its deployments are partially based on Azure, and some are based on AWS, Flux7 helped the organization create serverless continuous integration (CI) and continuous delivery (CD) tools and pipelines for their cloud deployments. These CI/CD tools facilitated the customer’s ability to build more custom pipelines for infrastructure provisioning, and application and service deployments. The pipelines were made as cloud agnostic as possible, supporting rolling deployments. Through these pipelines, even ECS and EKS were deployed to AWS to support blue/green deployments with options to automatically scale up or down the nodes in the cluster.   

Serverless Framework Architecture

Before we deep dive into the details of the technical implementation, let’s take a quick look at a generic serverless framework architecture and its prerequisites.

To install any serverless framework, there are a few prerequisites. But most of the time, these are dependent on the environment and applications that run on them. This hypothetical serverless framework has the following prerequisites.

Access to API Gateway and AWS Lambda 

IAM role created 

Terraform installed 

Git CLI  installed

AWS CLI installed

Jenkins installed

Starting the Serverless Journey

AWS serverless applications are a combination of an AWS API Gateway with backend AWS Lambda functions. Requests received by the API Gateway trigger appropriate AWS Lambda functions and the response is given to the end-user by the API Gateway. AWS Lambda runs the core application function, the real heart of the serverless app. Lambda functions are exposed to everyone using the API Gateway, which has logic to trigger a Lambda function if it gets a specific user request. 

Terraform modules are written to create a serverless AWS application. Developers can define specifics — like which infrastructure to provision, the programming language of their choice, etc. — in the Terraform file. In addition, they can specify which Lambda functions to trigger and which environments to apply the infra. The Terraform module expects several input parameters. Mainly, the Lambda function name, Lambda runtime environment, memory allocation for Lambda, the timeout for Lambda, the handler for Lambda, and so on. 

Jenkins uses this approach for CI/CD purposes. We create a Jenkins pipeline to on-board a deployable unit; it also deploys the infrastructure using Terraform. To keep onboarding and deployment separate from each other, we divide the process into two different pipelines. 

1. Onboarding Pipeline (Onboards the serverless components in the cloud) – When a user onboards a deployable unit from the DevOps dashboard, the dashboard triggers the Jenkins job named “onboarding”. The logic to create a repository and add a webhook in GitLab is all taken care of by this pipeline.
2. Terraform Pipeline (Deploys the serverless components using Terraform in the cloud) – The second Jenkins pipeline takes care of deploying the serverless infrastructure across different environments. As soon as the first pipeline job “onboarding” completes, GitLab sends a webhook trigger. The webhook is added to the repository when it is created. Hence the commit done by Jenkins during on-boarding of a deployable unit triggers a Jenkins job. The onboarding job makes use of another repository named serverless-template to download an example deployable unit with some AWS Lambda functions. The serverless deployable unit is also a Terraform template. The onboarding pipeline uses GitLab APIs to download the repository archive of the serverless-template. Once the repository archive is downloaded, it is updated with the parameters provided by the end-user inside Terraform tfvars files. 

The serverless framework benefits enterprises by delivering business value and innovation at a low operating cost. Interested in knowing how serverless framework efforts such as this help engineers deploy applications without the complexity of building and maintaining infrastructure? Let us help. Reach out today:

Avoid costly mistakes in Serverless strategies