Serverless computing and AWS Lambda! – Part 1

Serverless computing and AWS Lambda! – Part 1

Serverless computing, also known as function as a service (FaaS), is a cloud computing code execution model in which the cloud provider fully manages starting and stopping of a function’s container platform as a service (PaaS) as necessary to serve requests, and requests are billed by an abstract measure of the resources required to satisfy the request, rather than per virtual machine, per hour. Despite the name, it does not actually involve running code without servers. The name “serverless computing” is used because the business or person that owns the system does not have to purchase, rent or provision servers or virtual machines for the back-end code to run on.

Serverless code can be used in conjunction with code written in traditional server style, such as microservices. For example, part of a web application could be written as microservices and another part could be written as serverless code. Alternatively, an application could be written that uses no provisioned servers at all, being completely serverless. Serverless code can either be triggered by specific events or be configured to run behind an API management platform in order to expose it as a REST API endpoint. With the onset of Node.JS, there has been a lot of heat in the JS-Realm, different teams, companies, individuals are constantly leveraging this technology and adding value to it, and this is happening right now, as you are reading this. The node.js eco-system is growing by 1000 modules per month and it is the winner by far if you go to the official website of the node.js modules (https://www.npmjs.com/), it reads

That is the number of the npm modules in the registry present currently, as I write this paper.

One of those packages is called as ServerLess, exactly what this discussion is about.

What is ServerLess?

Just by merely reading it out, in its literal terms it can be said it is to do something without using Servers or doing something minus the servers. So let’s first understand what are servers and why we need them: Simply put, servers are like any other Personal Computer but with more amount of RAM and more Hard disk space or you can also look at them as a piece of hardware which provide us with:

  1. An operating system2. A
  2. A file-handling mechanism
  3. A system with more amount of computing power by using a high-end processor
  4. A system with more hard disk space
  5. A platform to install more software on it
  6. A platform to host a web application on – This is exactly what we need when we want to make an application to be used by the entire world

Introduction to ServerLess

Ok, so having said that it is clear that they are essentially needed when hosting an application. In a typical application at a high-level there are two ends:

  1. The front-end (the UI that shows up on the browser)
  2. The back-end (the server-side logic to manipulate the data coming from the front-end and to send to a persistent store.)

So now, if we talk about ServerLess, it implies that you have a front-end but you do not have a back-end or a dedicated server to host it on, then how would you host or what would you host your application on AWS cloud.

In the Node.js realm, it is possible to develop an application that would not need a dedicated server and this has been made possible by the arrival of ServerLess, none the less the prerequisite is you would need a Cloud Service which is capable of understanding / supporting this technology.

For this discussion, we would be using AWS Cloud Service, not only because it was one of the first Cloud platforms the creators of ServerLess wanted to support but because AWS also has a feature called as Lambda functions where the functions can respond to a particular event. ServerLess demands a change in developer thought process and focuses on one of the strongest and oldest principle called as Single Responsibility Principle-SRP.

ServerLess asks the developer to divide all the functionalities/features of the application into small self-contained functions. Each of these functions would do one thing and one thing only. The server-side functionalities would be divided into several self-contained functions and each function acting as one ServerLess module.

How does it all work?

Let’s just walk through a project on a very high-level.

Before we start a serverless-project/module we need to create a serverless project template, to do this we simply execute a serverless create project binary inside the project directory (more details on this in the next article) and this creates a blank skeleton with some JavaScript, JSON files and a serverless.yaml file. This YAML file works its magic during deployment.

Once the developer is done with development and testing of the said function, he would use the deploy binary from ServerLess package to deploy to AWS Cloud, now this is exactly where the serverless magic happens, the ServerLess binaries executes the serverless.yaml file and starts making a logical stack of resources needed (by the function being deployed), this stack is what we call a AWS-CloudFormation. If there are no errors in this step, then stack is made and kept ready inside AWS CloudFormation.

During deployment the code-files are zipped up and stored in a bucket in S3, and the API Gateways, Lambda functions, AWS CloudWatch LogGroups etc. are created. All these resources even though they are created in the cloud, the owner of the cloud account is billed only when the resources are actually used per call, and every call to the deployed serverless module uses a fraction of the said resources, thereby bringing down the cost in a big way.

The first deploy usually takes 3-4 minutes depending upon resources mentioned, once done the URLs to trigger the functions are mentioned and exposed at the end of deployment. The URL can then be consumed in an Ajax call from the front-end and that’s it, any call made to the URLs triggers the Cloud stack into action, and the function is executed per call, thereby achieving a handshake between the front-end and a server-side functionality deployed in the cloud.

Also, a quick thing to be noted here is that all the heavy-lifting of:

  1. Storing the code-files in S3
  2. Creating API Gateways
  3. Creating AWS CloudFormation Stack
  4. Creating LogGroups in AWS CloudWatch
  5. Creates a AWS-Lambda function where the created URL is mapped to a function whose code is stored in AWS-S3
  6. Making provisions to use any other AWS resource

Is all done by the deploy binary in the serverless package, this step can even be mentioned in a CI/CD script and thereby taking it to another level of automated serverless module deployment.

Coming soon….

In the next article, we’ll see how to create a small application using AngularJs, a database service running at some host, a front-end stored and hosted from a static file repository everyone coming together to make one application but without any dedicated server in the picture.

Scroll to Top