A Short Introduction to Serverless & FaaS
Hey folks 👋, it has been a while since my last post 👉 An Introduction to NoSQL. Recently, I had to revise some of the things that I have learned about in past few months. One of them is the Serverless Architecture. So I decided to write a post about it while I’m revising. 😁
Serverless?
Serverless is a hot 🔥 trend in cloud computing. The serverless architecture is not actually “serverless” though. .
Yes. It is just the name. 😉 Serverless does not mean that there are no servers involved. It simply means, the developers don’t have to think about server management and low-level infrastructure. The cloud provider will be responsible for managing resources, provisioning, patching and make servers available for the tasks. So that the developer can focus only in coding. 👨💻
In Serverless Architecture, applications significantly depend on third-party services known as Backend-as-a-Service (BaaS) or on custom code that’s run in ephemeral containers known as Function-as-a-Service (FaaS).
- BaaS :
Applications that depend on 3rd party applications/services to execute a certain amount of the application’s logic and state.
eg: Auth0, Firebase - FaaS :
Applications that run in stateless compute containers that can be triggered via events.
eg: AWS Lambda, Google Cloud Functions
Basically, FaaS is about running back-end code without managing your own server. Here instead of writing applications, we can write piece of applications with event rules which trigger our code when needed. So that you’ll be billed only for the fraction of a second, measuring resource usage. 💰
I have worked with PaaS solutions like, Heroku. As the PaaS providers promised they have offered us the freedom of managing servers but they don’t have great auto scaling, so we have to still think about it. 🤔 Also PaaS is designed for long-running applications. So that the application is running always to serve the incoming requests. In FaaS, our function begins to serve a request and terminated after it is processed. That means, when there are no requests, our functions should not consume the resources.
But there is a issue, ☝ not all workload can be converted to a event triggered model and neither can all code be separated by it’s dependencies and some of them may require intensive installation and configurations. So we should keep in mind that FaaS cannot be used in every situations.
Here are some use cases of FaaS; 👍
-Backends
-Web Apps
-Scheduled Tasks
-Chat Bots
-IoT Services
Let’s list down some benefits of Serverless approach 👇
- In serverless, you are only charged for the time it took the function to run. So we don’t have to pay for the idle time.
- Serverless gives auto scaling without involving us. Depending on the load cloud provider will scale up function instances.
- We can use different language runtime according to the use case
- Developers can focus on coding without worrying about the server management
There are drawbacks also. Below are some of them 👇
- Serverless can also add complexity rather than reducing it.
- Potentially hard to debug
- Hard to work with different services : using Firbase instead of DynamoDB
- Cold start : It takes some time for a scalable serverless platform to handle the first request by a function
Serverless architecture allows us to write piece of applications with event rules which trigger our code when needed and run quickly without using lot of server resources. But it doesn’t mean that FaaS is usable only in small scenarios. Although a function is a small unit, it can be invoked millions of times per second. The question is what functionalities we should move from our application to functions and how to do it without making our application complex. 💭
