Thinking serverless

A serverless solution is entirely event-driven. Every time that a user requests some information, a trigger will notify your cloud vendor to pick your code and execute it to retrieve the answer. In contrast, a traditional solution also works to answer requests, but the code is always up and running, consuming machine resources that were reserved specifically for you, even when no one is using your system.

In a serverless architecture, it's not necessary to load the entire codebase into a running machine to process a single request. For a faster loading step, only the code that is necessary to answer the request is selected to run. This small piece of the solution is referenced as a function. So we only run functions on demand.

Although we call it simply as a function, it's usually a zipped package that contains a piece of code that runs as an entry point along with its dependencies.

In the following diagram, the serverless model is illustrated in a sequence of steps. It's an example of how a cloud provider could implement the concept, though it doesn't have to implement it in this way:

Let's understand the following steps shown in the preceding diagram:

1. The user sends a request to an address handled by the cloud provider.
2. Based on the message, the cloud service tries to locate which package must be used to answer the request.
3. The package (or function) is selected and loaded into a Docker container.
4. The container is executed and outputs an answer.
5. The answer is sent to the original user.

What makes the serverless model so interesting is that you are only billed for the time that was needed to execute your function, usually measured in fractions of seconds, not hours of use. If no one is using your service, you pay nothing.

Also, if you have a sudden peak of users accessing your application, the cloud service will load different instances to handle all simultaneous requests. If one of those cloud machines fails, another one will be made available automatically, without needing to configure anything.