By Slobodan Stojanović and Aleksandar Simović

To understand serverless, consider for a moment washing machines. This might sound like a crazy place to start, but owning a server nowadays is similar to owning a washing machine. Everybody needs to clean their clothes, and the most logical solution seems to be buying a washing machine. But most of the time the washing machine is plugged in, it’s doing nothing. At best, it’s used five to fifteen hours per week. Same goes with servers. Most of the time, your average application server is waiting to receive a request, doing nothing.

Save 37% off Serverless Apps with Node and Claudia.js with code slstojanovic at

Servers and washing machines

Interestingly, servers and washing machines have many common issues. They both have a maximum weight they can process. Owning a small server is similar to owning a small washing machine; if you accumulate a big pile of laundry, the machine can’t process all of it at once or gets stuck. You can buy a bigger one that can take up to twenty pounds of clothes, but then you’ll find yourself in a situation where you want to clean only one shirt, and running a twenty-pound machine for a single shirt seems wasteful. Also, setting all applications to run safely together on one server is tricky and sometimes impossible. Similarly, in washing machines, you must take care of the clothes separation along with the program, detergent, and softener combinations. If setup isn’t handled properly, the color of one cloth can spoil another and ruin it, whereas on one server, a correct setup for one app can completely mess up another one with a different setting.

These issues, along with the problem that some don’t own a washing machine, led to laundromats or launderettes—coin laundry machines you rent for the time needed to wash your clothes. For servers, the same need led many companies to start providing server rental services, either locally or in the cloud. You can rent a server, and the server provider takes care of the storage, power, and basic setup. But both laundromats and rental servers are partial solutions.

For both rentals of servers and laundromats, you still need to know how to combine your clothes or applications and set up the machines, appropriate detergents, or environments. You also still have to balance the quantity of servers and their size limitations, along with planning how many you’ll need.

Faced with a world of dirty laundry, in the second half of the 20th century, a new trend of “fluff and fold” services started. These “fluff and fold” services provided their customers clothes washing, drying and folding. You can bring a single piece or a bag of clothes, and the service would clean, dry, and fold it for you. Some even deliver to your address. They usually charge by a single piece, and you don’t need to wait to gather a specific batch to clean or worry about washing machines, detergents, and cleaning programs at all.

Compared to the clothes cleaning industry, the software industry is still in the era of laundromats, as many of us still rent servers or use some PaaS (Platform as a Service) providers. We’re still calculating the sheer size of our potential requests (quantity of clothes) that we’re going to need and are reserving needed servers, wasting our money either on servers which are doing a fraction of what we need or, if the servers are overloaded, on backed up customer requests.

The core concepts

How does serverless change that? The name implies having no server at all, but that doesn’t seem to be a logical solution. Let’s go back to the definition:


Serverless is a method of deploying and running applications on cloud infrastructure, on a pay-per-use basis and without renting or buying servers.

Contrary to its name, serverless doesn’t exclude the existence of servers; software requires hardware to run. Serverless removes the need for companies, organizations, or developers to physically rent or buy a server.

You’re probably wondering why it’s named serverless. The answer lies in the serverless abstraction of the server concept. Rather than renting a server for your application, setting up the environment, and deploying it, you upload your application to your serverless provider, which takes care of assigned servers, storage, application handling, setup, and execution.


Some of you may be wondering whether serverless removes a company’s need for large DevOps teams. For most situations, the answer is yes.

More precisely, the provider stores your application inside a certain container. The container represents an isolated environment that contains everything your application needs to run. You can think of the container as a pot for houseplants. The plant pot contains earth filled with all the minerals your plant needs to live.

Like the plant pot, the container allows the serverless provider to safely move and store your application, execute it, and make copies of it depending on your needs. But the main benefit of serverless is that you don’t do any server configuration, balancing, scaling—any kind of server management. The serverless provider manages all of that for you, while also guaranteeing that if a large number of calls to your application occur at the same time, it will clone enough of your application containers to handle all the calls, and each clone will be an exact copy of the first container. If necessary, the provider will create even thousands of your application clones. The serverless provider decides to replicate a container only when the number of requests to your application becomes big enough that the current container can’t handle all incoming requests.

As a result, unless there’s a request (a call) to your application, not a single instance of your application is running, and it isn’t wasting space, server time, or energy. The serverless provider is responsible for all of the operational details, such as knowing where your application is stored, how and where to replicate it, when to load new containers, and when to reduce the number of replicated containers to unload the unused servers.

From the washing machine perspective, the process is like calling a fluff and fold cleaning service; its delivery guy appears at your door for your dirty laundry, and the service cleans and then returns the laundry to you. No matter how much clothing you have and no matter what kinds (wool, cotton, leather, and so on), the cleaning company is responsible for the processes of separation, detergent choice, and program selection.


Serverless and FaaS

Initially, the term serverless was interpreted differently from what it has come to mean. In the early days of serverless, it was defined as a Backend as a Service (BaaS), because it represented applications which are partly or completely dependent on third-party services for server-based logic. Later, it was almost exclusively described as Function as a Service (FaaS), because the serverless providers treated applications as functions, invoking them only when requested.

How does serverless work?

As previously described, serverless providers supply an isolated compute container for your application. The compute container is event-driven, and it’s activated only when a certain event triggers.

Container triggers are tied to events—specific external actions that behave exactly like physical triggers. Taking your home lights as an example, events that turn them on can differ. A classical light switch is invoked by pressure; a motion sensor is tied to motion detection; a daylight sensor turns your lights on when the sun goes down. But containers aren’t limited to listening to the specified events and invoking your contained functions; they also provide a way for your functions to create events themselves or, more precisely, to emit them. In a more technical manner, with serverless, your function containers are both event listeners and event emitters.

Finally, serverless providers offer various triggers that can run your functions. The list of triggers depends on the provider and implementation, but some of the most common triggers are HTTP requests, file uploads to file storage, database updates, and Internet of Things (IoT) events.


A serverless function runs only when triggered, and you pay only for its execution time. After execution, the serverless provider shuts the function down, while keeping its trigger active.

That’s all for now. If you want to learn more about the Serverless paradigm, read the first chapter of Serverless Apps with Node and Claudia.js here and see this slide deck.