Serverless Architecture

Serverless: It's Not 'No Server'!
You’ve probably come across the term before—Serverless. But don’t let the name mislead you. While it sounds like there are no servers involved, that’s not exactly true.

Serverless doesn’t mean servers don’t exist—it means you, the developer, don’t need to manage them.

Servers are very much a part of the process. Your application code still needs to run somewhere, and that “somewhere” is a server. There’s no magic that makes code run out of thin air.

The real advantage of Serverless is that it takes the burden of server management off your shoulders.

You don’t have to set up, maintain, or deploy servers. Instead, you get to focus entirely on writing your application logic, while the infrastructure is handled for you in the background.

Difference between Serverless and Non-Serverless

Imagine you're working as a backend developer. A large part of your job is building APIs — whether it’s RESTful or GraphQL-based.

You’ll typically write code that handles backend logic. This code could be written using any language or framework: Node.js, Python, Java, Spring Boot, Golang — whatever suits the project.

But once you’re done writing your code, it has to run somewhere — and that somewhere is a backend server.

In a traditional (non-serverless) setup, you're responsible for setting up that server, deploying your code to it, and keeping it running. The server is something you have to manage directly.

Let’s take an example of Amazon and understand.

Let me tell you this beforehand so that you won’t get confused, Serverless isn’t related to Amazon AWS or anything. It can be in any cloud provider. Microsoft also provides, Azure! For this example, we are taking AWS.

Let’s take AWS and spin a server inside it. In terms of AWS, we call it EC2. EC2 might sound scary to you right now but it’s just a service which provide virtual machine. Now we have to configure this virtual machine.

So let’s say, I figured out that my website doesn’t have much traffic as of now so I’ll be taking 2GB RAM with 500GB Storage.

Now will spin up the machine with the desired configuration which will execute our code in this particular machine.

Do you see any problem in this process? NO right!

What’s happening here is, that there is a server in this case and I am responsible for managing the server.

By managing the server I mean, how much RAM and storage has to be fed to the server, all of this is managed by me.

One more thing to notice here is that the charges here are based on per hour.

Assume Amazon is charging 0.02$ per hour. Thus, this machine will run 24 hours a day and 24 x 30 x 0.02 is my monthly cost.

💡 In a nutshell, here we have a server that is constantly running, whose configurations are handled by me and there is a certain amount of charge that has to be paid.

But what about up-scaling and down-scaling?

Let’s say during some months, huge traffic comes to my website. What will do in the case of Amazon will make some Auto Scaling Group (ACG).

Let me tell you ACG in layman's terms: It means that I’ll tell Amazon to give my EC2 instance 6GB RAM and 100GB Storage. Thus, for the time traffic will be high, the rate will automatically increase.

But the catch here is, on a minimum level who is managing the server?

It’s me who is managing the server. From scaling to code deployment, and configuration I’m managing all of it. Since it’s an EC2 machine, firstly we have to install NodeJS in it and then will have to install Linux and all of it.

Since we can say that, in a non-serverless architecture we have to take up a server, configure it, install an Operating System inside it, install all the libraries inside it, and take care of all the deployments, scaling up and scaling down is also my responsibility and billing is done per hour.

**

What happens in Serverless?

**
All you have to do is write the code. You don’t have to worry about the underlying infrastructure that’s running your code.

In terms of AWS, there is something known as AWS lambda.

What you have to do is to give your code to Amazon. Now Amazon will decide, what OS has to be given, how much RAM, and how much Storage has to be given? Your only concern will be to write the code.

The rest of the things like deployment, up-scaling, down-scaling, managing the underlying infrastructure, etc. all this is done by Amazon.

This particular thing is called serverless because you don’t actually have a server here. All you have is code and you’ve deployed it. All the management of the server is done by Amazon.

Now you might wonder what’s the benefit?

It took all the control away from me. The control to configure my machine the way I want.

But the difference lies here!

Let’s say I have a website and my backend is running on EC2, on a non-serverless architecture, and at this time my website has zero traffic on it.

Even though I have zero traffic but my servers are still running (24×7) to be able to serve user as they come.

But when we come to serverless, here billing is done in terms of invocation.

Let’s say the rate here is $0.001 per invocation. What happens here is the code isn’t running 24x7.

Suppose we have some code, and an API is attached to it. Initially, our code will be in SLEEP state and it’s not running. What happens here is, when a user comes and makes a request i.e. calls the API then only the serverless service will start my code.

At this time, it’s in the START state and then it will execute the code line by line and return its output as a response and it will again go back to the SLEEP state.

Whenever the user requests, the code is invoked, and it is from that invocation the billing is done i.e. in a month how many times it has been invoked.

The benefit here is that, if my website has zero traffic then I don’t have to pay even a single penny because at that time my website, server isn’t running at all.

Another important difference is in up-scaling and down-scaling.

Serverless can up-scale and down-scale on its own based on the traffic.

Suppose your site automatically gets 1000 users.

Now your single code cannot handle those 1000 users, thus what serverless will do is it will scale your system horizontally i.e. it will make multiple copies of your code so that it can cater to 1000 users and when the user traffic goes down it will get back to normal.

The other benefit is CDN. Serverless platforms help us run the same code in different regions so the latency is as low as possible, since the region that is selected is near the user.

This benefit is predominant as you don’t need to scale your system on its own!

Now let’s talk about why you should be interested as a developer in Serverless?

The idea is basically to run the backend code without having to update, create, and maintain a server.

Pros
The major benefits from a developer’s side (being able to build a full stack site without having to worry about other stuff!)

• No server maintenance
• No Provisioning: Enhances developer productivity and reduces operational costs by managing server tasks, enabling greater focus on app development.
• No monitoring: Facilitates DevOps by eliminating the need for developers to specify infrastructure and streamline processes.
• Low cost: Operational costs are minimized as cloud resources are paid for based on usage.
• Low maintenance
• Easy to scale.

Cons

• Lack of control over server-side logic and infrastructure may limit flexibility and lead to vendor lock-in.
• Cloud provider constraints can affect customization.
• Switching providers may require system upgrades to adhere to new specifications.

By now, you must have had a clear idea of Serverless, from its meaning to working. In a nutshell, Serverless computing abstracts server management, allowing rapid, event-driven scalability and cost-efficient deployment, ideal for modern, dynamic applications.