An Introduction to Serverless Architecture

By Amitai B.

Feb 8, 2018

In the end, as a developer, I just want my code to run. I do not want to mess with servers, VMs, dockers, containers, memory, CPUs, networks, load balancing, disk space… you get the point.

Serverless architecture to take care of all these pains for me.

No more servers! Let’s start a world-wide chant.

So what is Serverless?

A decade or more ago, if we wanted to deploy our applications, we needed to build data centers, with server racks, freezing-cold air conditioning units to keep them running smoothly, and an IT department whose members were busy around the clock.

After the invention of AWS (Amazon Web Services), we had a much easier way to bootstrap and run our applications using Amazon’s extensive infrastructure. This became known as IaaS (infrastructure as a service).

We could adopt the company’s server and only pay when we actually used it. But we still needed to configure and install everything ourselves.

Then services like Heroku appeared, which gave us an abstraction of servers known as PaaS (platform as a service).

We didn’t have to do much, just deploy our code to Heroku and it worked. One problem, however, was that it worked very well for monolithic applications, but for complicated ones utilizing microservices it was not the best option.

Then Amazon invented FaaS (function as a service). For this, you do not need to deploy your applications, only your functions. Amazon will take care of everything else for you.

FaaS is a synonym for serverless. In the rest of this post, I will use both terms interchangeably. It is not that the code does not run on a server, it is just that you do not have to care about it.

It is worth mentioning another approach: BaaS (backend as a service) which >enables web or mobile applications to have a backend with some services such as authentication, database or storage, but does not allow them to run logic on the server (that was on the client).

The are three major serverless providers: AWS Lambda, Google Cloud functions, and Microsoft Azure functions. Each of them is very good and deciding which one to use is often a matter of personal preference.

Serverless pros

Serverless or FaaS has many advantages:

  • Stability – you do not need to monitor if your server is up. It is. And your provider is taking care of it.
  • Scaling – no need to worry about this as well. If your application needs more resources, your provider will offer it without any action from you.
  • Price – this is a tough one, but in the end, you do not need to spend money on server that is not active; you pay only when you use it. In addition, you save on the salaries of IT and devops people who would have to constantly oversee a complex operation.
  • Deployment – you deploy your functions. No need to mess with installations, docker, containers, SSL and load balancers. Firebase provides a very smooth deployment process through its Firebase CLI. AWS Lambda has also tools that facilitate the process such as Apex or [](

Serverless cons

  • Vendor lock-in – When using serverless you are pretty much locked in to the vendor. You also remained tied when you use the vendor’s special APIs, or services such as database or storage.
  • Bootstrap latency – it takes time for the function to start running. In contrast to a regular server that is up and running, it takes time for the function to load and run when using serverless.
  • Stateless – I am not sure if this is a disadvantage or not because I do not like to use state on my server, but in FaaS you have no choice.
  • Server optimization – because we have no control over the server, we cannot hack into it as we please, and we cannot make optimizations for our app.

Event-driven programming

FaaS’s approach differs from traditional server programming. Instead of a synchronous chain of procedures, FaaS is event-driven. A function is being called after an event is triggered. The event can be an http request, a file upload to storage, or a database change and more.

It takes time to get used to it, and design an app accordingly.

When writing an app with Firebase, simple CRUD operations are trivial, and there is the option of obtaining added functionality such as sending a push notification or updating a different record in the database.


As I see it, serverless is simply the future. You will need a very strong argument to persuade me otherwise. Opting for serverless means you save on money on what would go to the salaries of IT and devops people. Plus, it is stable, scalable and reliable. Currently, there are still some drawbacks: slow bootstrap and performance, but I think that over time when the technology matures these issues will be ironed out.



Leave a Reply

Your email address will not be published.