What is Serverless Technology? A Deep Dive - Part 1
An introduction and fundamental comparisons of serverless apps with traditional apps
erverless technology has exploded in popularity the past couple of years and more and more people are opting for it instead of traditional architectures for their web and mobile applications.
A couple of most popular examples being AWS Lambda and Google Cloud Functions.
It’s important to take into account the important setup, maintenance, and scaling differences when using serverless tech and in this article, we’re going to cover all the fundamentals you should know beforehand.
Let’s get into it 👇
How Traditional Architecture Works
A traditional system architecture consists of three main components:
the client: the frontend made and hosted on a server for the users to interact with
the server: the backend service that incorporates almost entirety of the logic in the system — authentication, processing, searching, transactions, subscriptions, and so on
the database: the primary database that the server is in touch with at all times to manage all the user + application data within the system
Now imagine the scenario with a real life example.
We have a platform that helps users sell digital products.
This is what will the architecture look like in this system:
Now, let’s try to build the same application as a serverless system:
Comparing it with the traditional architecture, we can see the following differences:
Our authentication logic can be a separate third-party managed like with Supabase or Auth0.
We can use an API Gateway like Amazon API Gateway that’ll contain all your RestFul APIs and WebSocket APIs for all server logic
We can separate server logic such as user management, handling purchases and sending emails into serverless functions.
These serverless functions are in contact with databases and object storage like MySQL and AWS S3 to manage and store all data as needed.
Here is where some of the fundamental “function” based architecture comes into play.
When previously all our application logic was managed my our backend server which acted as a central manager of concerns, instead we now have functionalities distributed within functions that act more architecturally aware.
This can be thought of as Function as a Service(FaaS) architecture.
Now, you may ask, how do these functions operate?
Let’s take a look.
The Fundamentals of FaaS or Serverless
A serverless architecture helps you write functions that run without any server intervention from you.
They run the logic (your function code) in a “compute container” which processes the requests made to it purely on needs encountered in the runtime environment.
In traditional systems, you have a server that you manage to run logic as required by the client. In FaaS, you upload your code to the FaaS provider and the provider does everything else:
your function code can be in any language: Python, Golang, JavaScript, Java, .NET
the provider will provision necessary resources (horizontal scaling is handled automatically)
it instantiates and manages virtual machines and processes as needed
there is no need to worry about processing N number of parallel requests: if in our previous example of the digital platform, we have a thousand users simultaneously making stores, purchasing products and updating their profiles: the three functions we defined (in the diagram above) will be spawned, managed, and autoscaled by the provider and you don’t need to worry about parallelization at all.
You can also consider using a message queue and have it manage the requests in an order that doesn’t break your application logic.
For example, consider a payment workflow where you wanna do two things: 1) perform the payment and 2) send order/ purchase confirmation to the user:
Your API Gateway handles incoming requests and piles them a message queue asynchronously
The message queue then spawns multiple instances of your payment and email delivery function code (from the diagram above)
The best part is: the provider (like AWS Lambda) gives you both the FaaS environment to run your function code and the message queue and you don’t need to worry about managing them yourself.
In the next part…
In this article, we became familiar with the serverless architecture, also known as Function as a Service architecture, and how they operate based on a practical scenario.
In the next article, we’ll look at topics such as:
Advantages and drawbacks of this serverless technology
how they operate when compared container architecture patterns
State management, security, and cost management when using them
Become a Pro member to enjoy the next parts and get access to the entire archive: