Go Serverless!
By: Vinh Le
Tags: Serverless, Programming, Coding, AWS, Architecture

Part 1: Why Serverless?

If you are a software developer currently chasing for the-next-big-thing to learn, then buzzwords such as Serverless, Lambda most likely came across your searches. Over the past few weeks, I spent some times looking into serverless world, particularly in AWS ecosystem. I thus decided to start this Go Serverless series.

Apart from giving brief ideas on what serverless actually is, this series also aims at diving deeper in to AWS Serverless ecosystem. We will gradually go through its building blocks and see how they all play out in reality.

Let’s get started!

Does serverless mean…no server?

Interestingly…no

Serverless actually implies less management on the server rather than no server. Compared to traditional server architecture, serverless gives all trusts to cloud providers to handle the work of allocating and provisioning resources.

So — Serverless — Less work for you, more work for your application’s cloud provider.

A serverless application runs in stateless computer containers (also managed by cloud providers) during a very short amount of times, which could be just one invocation. Besides, it is event-triggered. This means your server always sleep until being waken up by a certain event trigger. After the event is handled, the server goes back to sleep.

Serverless providers

There are a number of tech giants who have been investing tons on serverless services and infrastructures. Their platforms offer a wide range of tools and services that help in building applications.

Now you might wonder: how are all of this different from normal, says AWS server, that you have been familiar for years?

The truth is, it is quite difficult to find out the reason solely based on serverless’s definition and its architecture briefing. However, as mentioned before:

Developers need to entirely rely on serverless providers to do the work of allocating and provisioning resources for the server

What exactly are allocating and provisioning the server? 🤔 Let’s pick AWS as an example and take a short tour across serveral services that it provides to get a hang out of this tricky question 💪

What do we do less?

Here is a quick look at AWS serverless architecture. We will glance through these blocks that are totally managed by AWS for backend developers.

Create and maintain APIs with API Gateway

Usually, one of the first task in creating a server side application is to initialise the app, most likely from a framework. Then you will develop more APIs by:

Adding more routes

Writing handlers for each route to carry out operations such as data validation and formatting

Connecting to and querying database, performing logic and handling error before returning requested data to client.

Except the 3rd part handled by Lambda, API Gateway will help you to do the rest. How?

All of this will be covered in more details in upcoming parts of this Series as we will work on creating a REST API from scratch 😎. Now, to give you a hang out of it, here are sweeties that you could get out of the box with API Gateway:

Resource and Method declaration

Request validator

Request data mapping and transformation before passing for Lambda to handle

Reshape data returned from Lambda before sending it back to client

Logging: in large application, you might need to create and maintain a separate service for logging. AWS gives you AWS CloudWatch for this.

Run application code with Lambda

AWS Lambda is a compute service that runs code without needing to manage the server. So you don’t need to handle the hassle of maintaining the server, its CPU, network and OS. When your application gets more traffics, Lambda automatically scale.

Another great benefits of Lambda and serverless in general is cost saving. We only need to pay for the time our code is actually running.

This is great thanks to its execution model. Lambda functions are run within containers managed by AWS. As a response to an event trigger, the container initialises an instance and execute Lambda handler function within it. If there are more requests coming in, new instances get created. If there is no more, the container is put back to sleep and not being used.

How do they connect to each other?

Back to the AWS serverless architecture. We already knew that API Gateway is the place to create and manage our APIs. It receives and reshape data came from client requests and send that meaningful data to a function handler. But how does an API Gateway resource talk to a Lambda function?

In a serverless application, we need to add configuration for this connection. It would look something like this:

Serverless configuration

This setup essentially tell the application to use todos.handler function in response to a HTTP event with method GET and route /todos . So, when a client makes GET request to that route of our API, todos.handler function will be called, get todos data and send it back to API Gateway (!Gotcha). API Gateway method will transform that data, if needed, before returning data to the client. We will dive deeper into this in the upcoming part of the series.

Fast updates and latency decrease

Apart from being free from server resources and scaling management and costs saving, there are essential benefits that serverless brings to the table.

Developers could be able to deliver new features and updates quickly to the end users thanks to serverless’s architectures. As a serverless application is actually a collection of functions rather than a single stack, we could update the application gradually function-by-function. This helps in releasing updates quickly without worrying to much about breaking other functionalities of the app.

Next, serverless applications could be globally distributed. This means our application codes are not run on a fixed origin server but rather closer to end users. The best part is cloud providers provide us amazing tools and help to manage all of the infrastructures behind the scene. Good examples are Lambda@Edge provided by AWS and Cloudflare Workers by Cloudflare. This unique kind of architecture significantly reduces request latency and thus improve performance for our applications.

Key Takeaways

Serverless applications run on actual servers.

Cloud providers help developers in critical resource allocation and provisioning tasks. Those works include creating APIs, maintaining and automatically scaling the server (operating system, CPU and networking) as well as database.

Serverless providers and external frameworks provide us with APIs and tools to connect building blocks of the architecture together.

One of the key benefits of Serverless architecture compared to traditional server is pay-as-you-go provided by service providers. Meaning we only need to pay for resources that are actually used.

Serverless architecture also brings great benefits such as faster updates and performance boost for applications.

Resources

What is Serverless Architecture? What are its Pros and Cons?

Lambda-AWS Docs

What is AWS Lambda? | Serverless Stack

Amazon API Gateway — Amazon Web Services

Edge Computing| CDN, Global Serverless Code, Distribution | AWS Lambda@Edge

This is the end of Part 1: Why Serverless in Go Serverless series!

In the next part, we will create a Serverless API from scratch with API Gateway, Lambda and Serverless framework. So stay tuned and happy coding! 💪👨🏻‍💻

I would love to hear your ideas and thoughts 🤗 Please jot them down bellow 👇👇👇